Credit Assignment is a module included for customers of Xactly’s flagship product, Incent, and is used to distribute credits and commissions across sales teams as orders are processed. With Flash reaching the end of its lifespan at the end of 2020, the Xactly Product and Design teams turned their attention to the tool early in the year as it was ripe foe a redesign. For customers who take advantage of CA being bundled with Incent, CA has become a critical piece of their workstreams, but we frequently received feedback around the number of clicks required to accomplish a task, the dated UI, and the need for a more robust tool overall. As the team looked into who did this well and what comparable tools are out there, we found that there was a potential business opportunity for us to not just upgrade our current tool, but expand its functionality in a way that would allow it to address a gap in the market.
Our goals for the project were:
Use Flash removal as an opportunity to update the Credit Assignment interface to look like a modern application. Use PRISM components to bring the look and feel in line with the Xactly suite.
Find options for simplifying the user experience whenever possible. Allow users to complete a task with the fewest number of clicks possible.
The third idea is related to simplifying the UX but is also bigger in scope. Whereas my goal to simplify the UX encompassed the number of clicks and how to tighten some of the flows in Credit Assignment, there were some great options for the team to totally overhaul some of the associated processes. This section required really close collaboration across Product, Design, and Engineering as we were proposing changes that would affect the back end of Credit Assignment. One area where we really pushed for change was to reimagine the rule builder and associated workflows to simplify the task, make it more intuitive, and better meet users’ needs. We also reimagined the download process. Whereas the original Credit Assignment app required users to go to a download page where they could view the files they’d downloaded from the UI, with this new version we simplified that process for downloads to follow today’s typical browser download process and automatically put the files in the downloads folder of a user’s computer. So while the UI was updated and the UX was simplified across the board, there were also some pretty big changes that required significant change on both the front end and the existing back end of the application.
Research
Our team used a variety of exercises and artifacts to produce our final product, and we employed Design Thinking to guide our efforts. The problem space of credit assignment was a great opportunity for a 3 stage design research program. This research approach is ideal for developing and iterating on a new design solution. When we look at the stages of design thinking, we see critical points where research can be leveraged. We start the process by empathizing with the user by conducting exploratory research to understand the problem space. This helps us define the problem from the perspective of the user.
We believed a solution could be best designed when the problem was well understood. When a solution is prototyped, research has another point of intervention with user testing. By understanding user feedback on early solutions, research can help develop and test new ideas. The testing phase can also help us redefine the problem and understand our users better.
This research program was conducted with the same participant pool over three sessions that align and enable design thinking. The first research activity was creating a mind map to understand how our users define credit assignment. Participants (groups 1 and 2) were asked to build a workflow for how their company approaches credit assignment
Instructions given to participants:
The blue boxes up here can be defined as a high-level process in your workflow (such as territory management).
Each yellow box represents a step in that process (such as uploading orders and defining crediting rules).
I know credit assignment looks different for everyone, so the grey boxes represent your stories. Feel free to fill these in with any details you feel are relevant, such as how the task looks for your company, what software you use, and specific ways you approach this task.
The sticky-notes are marked by color based on what you want to add as notes to the workflow.
After the sessions were complete, the workflows were aligned based on the similarities and differences between each company. Based on this information, 4 general stages were created to try to encapsulate the workflow across companies.
When it came to the information architecture of the product, I wanted to reorganize the application’s tabs and pages in a way that was more intuitive. I felt that the previous menus were convoluted with more sections than were necessary and with critical pages grouped with less important ones. So I essentially did a card sort whereby each page and page heading went onto a post-it note and I then spent a few days mulling over a potential reorganization. Once I had a header that I thought made sense, I put that on a different color post-it and moved the underlying stickies underneath it. So I used physical markers to organize my system before committing it to an actual system. Once I had a network of pages and subpages that seemed to make sense, I presented that to the steering committee for validation.
Design
Once I got their feedback and with the reactions from the users on our research panel, I had a rough idea of what the product should be and how it should work. It was time to begin putting together a rough prototype to show our research panel, so I began building screens in Figma. These were the low-fidelity screens that didn’t show much beyond how the app would function and what features users could expect. The initial wireframes that I built were an attempt more at capturing potential functionality than in reflecting an actual UI mockup. They only used black, white, and gray, and for features such as manual credit assignment, there would just be a button that said “manually assign credits” without any detail or actual flows built out. I wanted to ensure that I’d accounted for every feature request or potential workflow in Credit Assignment.
The facilitator walked through the prototype with participants, asking for feedback on screens and processes. Feedback for each of the prototype screens was documented and translated into design recommendations.
The final prototype was built using PRISM components, and it was a more fleshed-out version of the application. Because of the time constraints we were all working under, I still didn’t have the entire prototype built, and there were some dead ends in it, but it was a starting point that allowed us to discuss project feasibility with engineering. I would design in parallel to the early development of the app, and as I finished each section, I’d review it with my PM. Once I had her signoff. we’d add a link to the designs in Figma to the Jira story, and the Engg team would have the opportunity to take a look at it before we all reviewed it as a group during our biweekly planning sessions.
The same participants were asked to attend a third 60 minute research session through Zoom during which NPS and SUS surveys were used for both the current tool and prototype.
Takeaways and Lessons Learned
Whenever possible, start with both data and empathy, Do we have analytics? Have we spoken to users? Are we assuming where their pain points are, or do we know for certain? Are we replicating functionality just to reach feature parity, or do we know that users are looking for and expect a 1:1 match with an existing product?
When possible it’s best to make decisions holistically and not ad-hoc. One of the great things about redesigning an entire product in one fell swoops is that doing so allows for sweeping changes that can be considered in the context of the entire product and product suite rather than doing what’s best for smaller pieces of an application in certain spots only.
PRISM will streamline the process for Design and for Product, but that doesn’t mean that it simplifies for everyone across the board. For engineering, the design system may add a layer of complexity in the immediate term as a component can’t just be built locally but has to be contributed back to the library and any changes to something that already exists will require approval by other parties to get that component accepted into the library.
Share designs and plans with team members and stakeholders - seek dissent, and build quick prototypes so your designs can fail fast!