diana
bloom
ZENPURCHACE CASE STUDY
Redesign: Onboarding and Deal Setup Flow
ZenPurchase is an e-procurement platform serving Fortune 500 companies (now owned by Coupa).
The Problem
Usability issues during the onboarding and deal setup process were leading to abandonment.
The Solution
A new deal setup flow that helped users understand the process, a fully rearchitected deal page, and requirements templates.
My Role
2-week design sprint partnering with one other UX designer in all phases of the design process.
DESIGN PROCESS
Mapping out the task flow using card sorting
The procurement process involves initiating a "deal", preparing an RFQ, broadcasting the deal to stakeholders and vendors, tracking responses, selecting a vendor, and finalizing the deal. To understand how users think about executing these steps, we used a card-sorting exercise to see how users organized the activities. This helped inform the deal setup workflow.
The three card sorting exercises helped to inform the "ideal" flow which allows a degree of flexibility and freedom throughout the process.
The three card sorting exercises helped to inform the "ideal" flow which allows a degree of flexibility and freedom throughout the process.
Heuristic analysis & usability testing of the current flow
Once we understood the steps and requirements in the workflow, we wanted to evaluate where the application was falling short. To figure out the most obvious areas of weakness we did a heuristic analysis and conducted two live user testing sessions.
What we found:
-
The deal setup process lacked feedback and direction, and didn't inspire confidence in the application
-
The interface lacked consistency and cohesion
-
There was no contextual help
-
Users had no indication of how many steps there were during setup, so they felt trapped in the process
Susan owns a business and has used RFQs to request quotes for services and supplies. She shared a lot of great feedback during this session. By observing her work we were able to see where the system fell short in helping users understand why they were taking certain actions. She provided many insights about weaknesses and opportunities for improvement in the process.
Matt gave some insight that reinforced the need for clarity on the deal page once the setup flow was completed. He wanted to go back through the setup flow to make changes but couldn't get there, and it wasn't obvious that you could edit fields on the page.
The heuristic analysis revealed distinct areas of strengths and weaknesses. The weakest areas were help and documentation, error recognition and prevention, visibility of system status, user control and freedom, and match to the real world.
Susan owns a business and has used RFQs to request quotes for services and supplies. She shared a lot of great feedback during this session. By observing her work we were able to see where the system fell short in helping users understand why they were taking certain actions. She provided many insights about weaknesses and opportunities for improvement in the process.
Developing proto-personas
Once the primary issues were identified, we wanted to make sure we understood the users. We didn't have access to actual users, so we interviewed the business owner and created three proto-personas with different backgrounds, viewpoints and experience levels.
The common thread across persona types was the need to keep interactions quick and simple.
Key goals are highlighted, and from this we identified the flow and interface requirements to meet these goals. Proto-personas will be developed and fleshed out as the product gains traction and more users.
Key goals are highlighted, and from this we identified the flow and interface requirements to meet these goals. Proto-personas will be developed and fleshed out as the product gains traction and more users.
Sketching solutions
Now that we felt we understood the process, the problem, and user needs, we started sketching out some ideas. To keep the project in scope we limited our design focus to:
-
Deal setup flow
-
Deal page
-
Dashboard page
The client provided us with mockups from an in-progress UI redesign. We used these to underpin our solution, which evolved over multiple iterations through user testing and client meetings.
Our original idea was to use a "funnel" model similar to what exists, but to add functionality and more in-app guidance. Progressive disclosure was used to reduce the impact of multiple form fields.
To address the need for efficiency, we introduced the idea of providing pre-formatted, editable templates based on the deal type. We also added non-question requirement fields and colleague input capability.
Action cards are also included on the dashboard page where the user can respond in-line. "Create a Deal" and "Add a Vendor" buttons were also added to the dashboard as these are high-level functions that require visibility and easy access.
Our original idea was to use a "funnel" model similar to what exists, but to add functionality and more in-app guidance. Progressive disclosure was used to reduce the impact of multiple form fields.
User flow models and iterations
Our first design iteration consisted of a "funnel" - a series of steps that were required before the user sees the deal page. We shifted strategy after meeting with the client, who felt the deal page was still too hidden and wanted to see a different approach.
The user flows illustrate the original and final redesigned flow through the setup process.
The original flow took users into a non-optional setup "funnel" that had no exit points.
The new user flow only has one mandatory step in deal creation. Once the deal is named, the user enters a setup flow that's an overlay on the deal page.
The original flow took users into a non-optional setup "funnel" that had no exit points.
Final design and prototype
The final design concept consists of an overlay on the deal page that highlights the steps users take to set up a deal, while allowing them to see page details and exit at any point.
We also rearchitected and optimized the deal page by:
-
Placing the requirements tab first since this is the most important information for team members
-
Combining public and private discussions under one tab to eliminate confusion and free up screen real estate
-
Displaying the activity monitor separate from the tabbed area
-
Adding action "cards" to the dashboard and activity monitor to allow users to take actions in-line
When the design was finalized, we delivered an interactive prototype using Axure.
The original deal page provides guidance to users in the form of a set of tooltips. There were five tabs, with deal activity displayed in the first tab and separate public and private discussion tabs. Buyer and vendor team information was displayed in a panel on the right.
Users are walked through the setup process, familiarizing them with the layout of the deal page. Save and Exit can be used at any point in the setup process. The only required field is the deal name. The activity feed appears at the right and is always visible. Action cards enable users to act without interrupting what they're doing.
Action cards allow users to take actions independently. Cards on each deal page are exclusive to the deal, whereas cards on the dashboard are global.
The original deal page provides guidance to users in the form of a set of tooltips. There were five tabs, with deal activity displayed in the first tab and separate public and private discussion tabs. Buyer and vendor team information was displayed in a panel on the right.