Using the U.S.E.R. Methodology to Move to the UX
_86853.jpg "UXGA_1_Boards (1).jpg")
Anaplan’s UX is a great feature that can be used to condense multiple dashboards into meaningful apps and pages. I see this as a huge improvement to users' overall experience of the product. By taking an example of a simple case study, I'll explain how to use the new U.S.E.R. methodology to move from Classic to UX.
Case Study:
A company named XYZ Corporation sells laptops across different industries in several countries. The sales operation ecosystem of this company consists of two main teams:
- Sales Operations Managers
- Territory Managers
Sales Operations Managers have the following responsibilities:
- Create territory coverages for the sales representatives based on the product they would be selling for their geographies.
- Maintain staffing information of sales representatives.
The Territory Manager Team validates and approves/rejects territory submissions made by the Sales Operations Managers, which flow to a downstream system.
In the Classic application, information for territory coverages is stored in a separate model while the information for staffing is maintained in yet another model. When we are making a decision to move from the Classic version to the UX, the new U.S.E.R. methodology can be extremely helpful. Let’s try to understand the U.S.E.R. methodology in detail by using the above-mentioned case study as an example.
Understand the value proposition and the needs of your users.
- Identify the personas and the problem you're trying to solve for them by moving from Classic to UX.
- Try to understand their frustrations and how you can address them by moving to the UX.
- Identify logistic details such as the complexity of use, frequency of use, type of use (read/write) and how familiar they are with Anaplan.
- Identify from where you should start your migration journey.
In our case study, we have two roles: Sales Operations Managers and Territory Managers. They share similar goals and frustrations, so they have the same persona: decision maker/manager. It might be really frustrating for users to navigate across various dashboards in two models: Territory Model and Staffing Model. If we could club the dashboards in an app for each role, it would save a lot of hassle of moving across different models. Each app would contain the relevant pages used by each role depending on the type of use and frequency of use.
In this case, the app for Sales Operations Managers would contain pages with write access to manage territory and staffing pages. The app for Territory Managers would contain pages with write access to the Territory Approval dashboard and read access to the Staffing and Territory Coverages page.
More About the UX:
Sketch out your plans and move from mind to paper.
- Before you move from Classic to UX, it is strongly recommended you map out a step-by-step journey of personas.
- Move from mind to pen and paper and sketch the process flow that you would need to migrate.
- Identify the most-used classic dashboards and start by choosing a simple process to migrate with relevant personas. For instance, in our case study, the simple process to migrate with relevant personas would look something like this:
Execute your plan and share your results.
We have identified the personas and processes in the first two steps. Next comes the execution part of the UX.
To start, envision what apps, pages or types of dashboards you want to use. As per best practices, use worksheets whenever you need to reviewing large, detailed data sets, or filter or run actions on large data sets. Use boards whenever you have small volumes of data and you want to use it for graphical visual reporting/KPI review or as a landing dashboard.
For our case study, we would create two apps; one for each role:
Inside the Sales Operation Manager app, we have created two pages: one for managing territory information and other for managing staffing information.
For the territory page, we have chosen the worksheet layout, as this involves running actions and working (pivot, sort, filter) large volumes of data. The page contains a main grid where all territory information can be referred to or edited. On the insights panel, we have the actions and the grid to create coverages. We can expand the creation grid to the main screen whenever coverages are to be created.
For the staffing page, since it involves dealing with a small volume of data and does not involve running any processes on data, we are using the board view. We are using hierarchy as a filter if users want to view employees by geography.
Now we come to the next persona of Territory Manager. Inside the territory manager app, we have created two pages: Approve/Reject Territory and Staffing and Coverage Overview (which is just for reference and read-only).
For the Approve/Reject Territory page, we have chosen the worksheet layout, as this involves running actions and working with large volumes of data. The page contains a main grid where all territory approvals or rejection can be made. On the insights panel, we have the ability to process approvals/rejections and the grid to review changes for each sales representative. Users can expand the grid to review changes for each sales representative to the main area whenever they need to view the information from that angle.
Additionally, we can add a notification process (a great feature for Territory Managers) if they want to send out bulk notifications to Sales Operation Managers for their geography.
For the staffing and coverages review page, since it is read-only and has a small volume of data, we are using the board view. We have used hierarchy as a filter so users can view employees or coverages by geography.
Similar to the Approve/Reject Territory page, we can have a notification action that Territory Managers can use to send out bulk notifications related to staffing information to Sales Operation Managers for their region.
Repeat the process to incorporate user feedback and new features.
- This phase is all about continuous iterations.
- Set up regular touch points with users and look for areas of improvements. Understand what they liked about the UX and what they see as pain points.
- As per their feedback, try to migrate more processes to the UX and address the pain areas.
- Keep up-to-date with releases and see how you can use new features for your process.
_86853.jpg "Sonal_PassportSizePic (002).jpg")
Sonal Tripathi is a Senior Anaplan Analyst at Adobe and has been working with Adobe since 2017. She has done B.Tech in Information Technology and has 9+ years of experience with tools like Anaplan and Hyperion. She is a Certified Master Anaplanner and is responsible for maintaining the end-to-end Anaplan implementations at Adobe.