Recognize All
2019
1
2
3
4
5
6
The team and The Business Problem
Discovery
Historic Research and Defining the User Journey
Design Process
Internal Interviews
Customer Interviews and Testing
The Team and The Business Problem
The product I work on is one of our core financial management products, Revenue Management. The main functionality of this product is based around a mandatory financial accounting task called revenue recognition. My role as UX designer in this team involves me working with the Product Manager, Engineering Team Lead and Architect to collaborate on the business goals for the product, teamed with user pain points and problems to solve. As a quad we carry out collaborative exercises to come up with solution ideas and to get to the bottom of what the actual problems are. I usually act as the facilitator of these sessions as well as contributing. We work alongside stakeholders to ensure we are meeting business needs and influencing priorities where it is needed.
Following the completion of my graduate program, I was placed in the Revenue Management feature crew. This was my first project, during which my product manager left and was replaced at the interview stage of this project.
One of the biggest pain points in the whole product is regarding the revenue recognition process. We regularly hear that the process takes too long and requires too much manual effort. The process was taking users up to 2 days to complete and had lots of points in the process where the user had to initiate the next step. One user described this as "having to babysit his computer".
Business Problem Statement
Our Revenue Recognition solution was designed to run on a single currency, single account and single revenue object basis.
We have observed that this service isn't meetings user's goals of being able to "click a button and it just run". This is causing customers to become frustrated and stop using our product.
How might we improve revenue recognition so that our customers are more successful by requiring less time to run the recognise revenue process.
Discovery
Our completed opportunity canvas
Opportunity Canvas Workshop
To begin the project, I organised for our quad to complete an opportunity canvas to explore the the business problem statement in greater detail and come up with some solution ideas.
Once we completed the canvas, we arranged the solution ideas into a complexity Vs impact quadrant. We decided to present our prioritisation of ideas to our stakeholder and get their input. Due to scope of the initial idea, we agreed to explore our second idea further. The second solution was to act as an interim step towards the initial idea in a future release. The chosen idea was to create a simple one-click process to run revenue recognition as we believed this would address a number of the user pain points.
User Journey
Having identified our goal of removing as many pain points in the user journey as possible and creating an easier process, we focused on mapping out exactly what the user journey was, what those pain points were and which step of the process they were associated with. This activity was carried out with the product manager, product architect and front-end developer.
We determined what we considered to be the starting point (where users navigate to the recognise revenue UI) and the end point (where they complete the task that takes place in revenue recognition within our product before navigating away). This user journey map was completed solely on team members experiences with customers. We then took this to be validated with our customer consulting team who work at implementing our solutions with customers.
Being a new member to both the team and product, I decided to do some research into previous interviews and any prior research that had been carried out by past designers. This proved fruitful as I found lots of previous research which helped validate the user journey and pain points. This also surfaced previous designs that had been created by the previous designer which was never implemented. In order to move quickly, I assembled the discovery team to present the previous research and pose the question of whether we could simply progress with the previous designs. We decided this would be a great way to progress at speed and so the previous designs were touched up slightly to match the current design guidelines and patterns before going to internal customer facing roles for feedback. The designs featured a full set up wizard for the running of revenue recognition as well as a scheduling feature.
We got the following feedback from the first three interviews, "This is great... but we don't need all this"
At this point we decided to stop and make changes.
User Journey Map of the Revenue Recognition Process with user pain points
Design Process
Setup wizard approach of creating a pre-defined recognition rule
The Mock-up shown on the Left is the design which the process was started with. As mentioned, this mock-up was based from designs created by a previous designer which I updated and tweaked to incorporate the latest design guidelines and patterns. This was done in Sketch. I did some internal collaboration with a fellow designer working on a different product but with a similar use case but unfortunately we couldn't find a common pattern that would work for both our use cases. Following this collaboration session and the feedback that the customers didn't need all of these options and full setup wizard, we decided to change course slightly. We re-reviewed historic feedback and several quotes became very glaring to us,
"Why can't we just hit a button and do everything at once?!"
"Customers wouldn't mind it taking an hour if it was doing everything in one go"
These quotes made us ask the question, "Can we just create a button that recognises everything available in one go?"
One Click Solution
Sketches of the simplified solution
A quick workshop was held with the product manager, product architect, front-end developer and a senior designer for support. This was to brainstorm how we could create a one-click solution which would be findable, complement our existing process and support a range of front-end technologies.
Since we were a small group and didn't have a large amount of allotted time, we stuck to the main focus areas to explore:
-
What was the start point?
-
Where would it live?
-
How much of the process would it carry out/How many pain points are we addressing?
-
What input will be required of the customer?
-
What is the output?
We came up with the following idea which I translated into the sketches shown on the left. The button was designed to be placed in the UI where they would normally begin this process (the recognise revenue screen). The main body of the page is a very busy full page app with lots of real estate taking up the full space of the page. To keep it separate from the existing process, but discoverable enough for customers to begin using it, we placed it in the header bar of this page.
On clicking this button, the user would be presented with a pop-up modal. This would inform them that the process would be run automatically for all their currencies, revenue streams and companies. These were all big pain points for users, stated in both historic and current research, as all of these items had to be run one at a time.
Another big pain point that was identified was the multiple steps needed to even start the process. Users had to select the company, currency, revenue stream and recognition date before then generating the available items (which could take a couple of hours) and then select the items they wished to recognise before then submitting these items to start the background process of creating transactions (which could take many hours, up to days in some cases). In order to cut down the number of steps and interactions needed by the user, we designed that users would only need to enter the recognition date. The system would then pick up all available items to recognise and automatically submit them.
Internal Interviews
In order to quickly test the concept, we organised internal sessions with customer facing colleagues to gain feedback and test the design. The above sketch was tidied up and each screen was drawn on separate pieces of paper to enable more accurate testing.
Each participant was asked to identify how to begin the new process. This meant pointing out the new button in the page header. Before showing each following screen, participants were asked what they expected the following screen to present. We carried out these sessions until there was a common theme in answers.
6/6 Participants all felt customers would love the solution
"If you introduce this all the customers who have refused rev rec in the past will be happy"
There were a few suggestions of improvements including adding an additional input field to allow users the option of the status to create the completed transactions in. Which we added to the design and created a high fidelity mockup to test with users.
UI Design
The placement of the Recognize All button (the blue button in the top right)
As the paper prototypes had been tested as a concept I skipped past creating digital wireframes to create high fidelity mockups.
In order to create these designs I followed our internal design guidelines and patterns. As we are based on the Salesforce platform, many of our guidelines are set in coordination with the capabilities provided by them. We have our own internal pattern and component library which was used for this. This used the new technology of Lightning Experience or LEX. As there would be a range of customers using LEX technology and customers still using our older technologies (Sencha - ExJS), we needed to ensure we could utilise the Lightning capabilities of presenting this feature to users of the older technology. Due to our product containing mostly full page rich apps we don't have the capability to design for mobile users being able to carry out this particular process.
The designs were created using Sketch, utilising our design library, and then exported to Invision. Once in Invision, a clickable prototype was created which were used in the customer testing sessions.
Customer Interviews and Testing
We spoke to 5 users of rev rec in this stage. We began each session by asking the users about their current rev rec process and what their ideal rev rec solution would be. Following this, users were then presented with the rev rec homepage and asked to identify the Recognize All button. We then asked them what they expected to see on each page to follow.
The following were the main points to take away regarding the mock-ups:
4/6 Users were happy with our idea of auto-naming transactions
2/6 Users mentioned that they would like to view a summary/preview before running the process. A further 2 users mentioned the preview as being a nice to have but wouldn't stop them from using this feature.
1 User mentioned the ability to have further control over what you run the process on (eg. for 2/3 variables rather than everything). Some internal interviewees made similar comments but in both cases it was mentioned as a nice to have.
6/6 Users loved the idea.
"This is fantastic, oh my gosh this is exciting!"
Following these sessions we made the following changes to the design:
-
Auto-selection of "In Progress" status type
-
An information banner that would warn users that clicking the "Run" action button would begin the process and could take some time.
-
Slight alteration of Auto-naming convention for transactions created through this process.
The Results!
As this was my first project following my transition from the graduate program, I was slightly nervous of running the workshops and such correctly. As the project ran very smoothly my confidence was built both in facilitating collaboration sessions and organising and running customer interviews. As a developing designer I found it really challenging to have a change in Product Manager (PM) during the development of the feature. In previous customer sessions, my previous PM would run them due to having lots of experience in doing them. With the timing of my new PM's arrival at the customer interview stage, I was forced to step up and run these sessions. This gave me a huge confidence boost and proved to myself that I could run these sessions successfully.
One of the measures of success, as stated in the business problem statement, was to decrease the amount of time needed to carry out Revenue Recognition. Due to the change in development structure and technology of this feature, we were able to reduce the processing time by a huge amount. With the combination of decreased processing time and a one-click solution without requiring any manual interactions disrupting the process, we can definitely say this project was a success.
13
Total team members involved over the length of the release
6
Screens
5
Number of steps in the user journey removed
4.10
Hours quicker in processing time