Streamlining complex business operations, by design

Deckers Brands

Role

Experience Design

Team

Product Lead

Visual Designer

Product Owner

IT Team

Sales Operations Team

Tech Team

Timeline

24 weeks

A global leader in innovative footwear, apparel, and accessories, Deckers Brands was looking to build a suite of products they could use to better service their family of brands, which includes UGG, HOKA and Teva.

Deckers’ business challenges included overly manual processes and a lack of real-time data that was contributing to operational inefficiency. The most recent tool, Apollo, was designed to streamline multiple sales operation processes and make cross-brand management more cost effective, while also improving the employee experience.

Deckers' sales operations are fundamental in building the information that the business depends on to make critical decisions. Sales ops leads analyse data from sales teams to uncover insights that guide sales and demand strategy.

I led UX Design on the project with oversight from our UX Director.

Tool enables consistent processes that support strategic working

Replaced manual tasks and reduced errors

Decreased onboarding time for new joiners

Improved efficiency and the employee experience

Challenge

The primary challenge was to create efficiencies in the sales operation journey:

  • Onboarding
    Improving the onboarding process for new sales reps

  • Assignment

    Optimising the assignment of sales reps to customer accounts

  • Sales forecasting
    Facilitating efficient sales forecasting for data-driven planning and analysis

Discovery

Audience collaboration

From the start, our approach was highly collaborative, involving Deckers in the design process and working directly with the people who were regularly experiencing issues the tool could solve. Each audience sat across multiple Deckers brands (UGG, HOKA, Koolaburra, Sanuk and Teva) each with their own process nuances:

  • Sales Ops
    Responsible for ensuring Sales Rep assignments are properly set up and that the sales and forecast data is correct.
  • Sales Reps
    Responsible for submitting their customer sales forecast orders into the system.
  • Sales Planners
    Responsible for analysing aggregate forecast data.

Reframing the challenge

Without a clear view of the many processes involved and how they fit together, we worked closely with Sales Operations and Planning teams to map out each of the focus areas in Miro. We identified the the actors involved at each step, the actions that take place and the systems they rely on.

It quickly became clear that although onboarding new sales reps was a cumbersome process that needed to utilise many systems, it wouldn't drive the greatest business impact for our initial release. We decided to focus our efforts on sales forecasting and customer assignment, with the view that centralising data collection and removing complicated handover points would provide a long-term foundation for evolving the product.

Unpacking the core user problems

To drive our definition and design phases we focused on the core user problems of the sales forecasting process:

  • Highly manual process

    Sales Planners manually compile product and sales data into Excel sheets and send them to Sales Reps. Reps enter their forecasts and return the sheets at scheduled intervals. Sales Planners then review the aggregated data to make buying and demand decisions.

  • Difficult to build historical data
    Historical data is aggregated from other systems and manually fed in to forecast sheets. It's difficult to create contextual relationships in the data to help understand business performance.

  • Rigid processes

    The tools and ways of working are rigid, whereas the forecasting process is fluid. Data can change for Sales Reps throughout process and different reps will report to different timelines.

In-depth data point analysis

With a shared understanding of the process and key challenges we began to dive deeper in to data. Our goal was to understand the data points required to create a forecast sheet, why they're needed and where the data comes from. This gave us a solid understanding of how data currently exists and how we could begin to structure the future experience. Given the reliance on a number of systems (and teams within the business), the mapping gave the Deckers IT team a starting point to begin internal conversations about data integrations we'd need for the new tool.

Visualising the end‐to‐end

With inputs from our collaborative sessions I created a high-level user journey to visualise the end‐to‐end experience across various handover points. This allowed us to further define the future state process we were aiming to design. It helped set expectations about a new way of working and drive conversations about how processes could be optimised. Keeping the journey at a high‐level allowed us to work fluidly and explore steps in the process that still had ambiguity around them.

Definition

Structuring the experience

During the discovery process I began to develop an information architecture that would lay a foundation for some of the key screens we wanted to develop with the caveat it would likely evolve as we got closer to the design phase. This early structure was beneficial in providing our team with guardrails for the system.

Prioritising features over visuals

As we edged closer to the design phase it was important to zoom in on the detailed information we'd need. I created Page Description Diagrams (PDDs) to reframe our conversations about content and feature priority. The goal was to highlight page features without getting stuck in discussions about visual design as has happened on previous Deckers projects.

Although PDDs helped provide clarity around the purpose of the screens and features within them, the client team found it difficult to provide useful feedback because they felt too abstract. With this in mind I concluded that user flows would be a more helpful artefact to create a shared understanding of the micro-level view of the experience.

Visualising with user flows

As our Product Lead and Product Owner were crafting our epics I began to explore different approaches to detail the key user flows in a visual way to help extract requirements from the client team. After the epics had been created and tasks identified, I defined the primary flows our audiences would explore through the tool. Crafting these user flows was the most effective way to conceptualise and structure the proposed content and functionality, while their visual nature provided clarity to the team.

Extracting requirements through concepts

To help facilitate production of user stories I created and annotated early wireframes for key screens. Alongside feedback from the client team, this provided a way to visualise the proposed functionality, tasks that needed supporting and what could be discarded from the initial release.

Design

Communicating design

For each sprint, we went through cycles of requirements gathering, detailed wireflows, design, approvals, annotations and handoff.

My process involved hi‐fidelity wireflows in Figma, then my creative partner translating these into finalised designs. Previous Deckers projects meant we had an existing foundational design system to draw from so it was relatively easy to move straight into hi‐fidelity wireframes.

Breaking down the journey with user story mapping

Although we were designing against user stories created by the PO we quickly discovered we needed more detail. Our collaboration and creative review sessions descended into requirements gathering sessions with back and forths over expected functionality. The user stories lacked the detail needed to define the wireframes.

In order to evolve the user stories with the desired level of detail I introduced user story mapping. I used Jeff Patton's User Story Mapping to outline all the expected interactions in each epic to complete a task. This detailed mapping helped enable user-centered conversations, collaboration, and feature prioritisation.

“This user story mapping is brilliant. For me, this is hugely helpful. Thank you! I’ll be using these for every one of our capability areas as we flow through them.”

Deckers Product Owner

Features

Roll-up dashboard

Analysis of aggregate sales forecasts across an entire season is an in-depth task that requires a snapshot of key metrics and ability to explore data at different levels of granularity.

We extracted the most meaningful metrics for high visibility and allow for comparator seasons giving users the ability to understand the story being told by data.

Given the large dataset, Planners needed a means to discover data and infer insights. We used good default states and gave users the tools to control what they viewed. Grouping provides flexibility to explore data relevant to the user's current focus and insights needed.

Users regularly perform a series of filtering and modify columns to surface relevant results. To create efficiencies for personal preferences we designed a custom views feature. This included functionality that allows admins to dictate global views and individuals control of their private views.

Sales forecast

In contrast to Sales Planner's who compare lines and analyse patterns in forecast data, Sales Rep's main focus is to input forecast sales orders for each of their assignments.

Home

The home screen was designed to provide an overview as well as serve as navigation. Users can quickly gain context before diving into details elsewhere in the experience.

Making an impact

Our work with Deckers has been instrumental in driving consistent processes that support strategic working. The tool has replaced manual processes and increased accuracy. It’s also had a meaningful impact on the employee experience, improving efficiency and decreasing onboarding time for new joiners.

Feedback from Deckers team members and managers has been overwhelmingly positive, with excitement about the new tools and their potential to improve their day-to-day work.