Take-home Design Exercise
Yan w/ Hiretual
Design an experience that helps the sales and marketing team to track the duplicates and then merge the customer information.
After contextualizing the problem, I identified 3 scenarios when a sales rep may get to deal with duplicates. For each of them, I captured the user flow and acknowledged the technical assumption the scenario is based on. I moved forward with one scenario to sketch out the key screens on paper. I also brainstormed 3 different layouts to display duplicates and 2 ways to edit duplicates with a mid-fi screen to support the idea.
- Pen & Paper
- My brain 🧠
- My computer 💻
- Two cups of coffee ☕☕
- My boyfriend 🧑💻 (I asked him some questions on the tech end lol.)
Understand the task &
Emphasize with the users
To begin with, I needed to understand “What problem am I trying to solve here?”, “Why is it important?” and “Who am I solving this problem for?”. Guided by these questions, I read through the provided scenario and extracted some key information from the prompt to help myself put all the pieces together:
My notes and reflections will go here. 💡
I moved forward using the case of "a sales representative" in this design exercise.
Knowing my audience as the “sales & marketing teams”, I set out to gather more information about this specific user group and the CRM field. I did some desk research following questions such as “What does a sales representative’s day-to-day look like?”, “How does a sales rep use the CRM software at work?”, etc.
Define design principles targeting sales reps
Based on the characteristics of a sales rep’s work, I came up with the following design principles that could be used as guidance for the following steps when making decisions in flow and visual:
When I was working on these design principles, I also used Jakob Nielsen's 10 Usability Heuristics as a reference.
Explore the CRM landscape
Firstly, I noticed that although the features provided by different platforms vary slightly and claim different strengths, they all organize around the sales cycle that a sales rep will go through during the selling of a product or service. Below is the diagram of a 7-stage sales cycle, and a CRM tool usually has features targeting each stage of this cycle to help sales reps finish their tasks. For example, a Leads Board is where a sales rep imports prospect leads and tracks them through a pipeline.
This sales cycle played a significant role in helping me identify the 3 scenarios when a sales rep gets to deal with duplicates!
Keep reading to find more :)
While trying to figure out the basic structure of a CRM platform, I also assembled several interface snapshots to familiarize myself with the design patterns and some industry best practices. I noticed that most of these interfaces consist of a top/side menu serving as the first-level navigation and a dashboard with different types of widgets. I decided not to reinvent the wheel and go with this layout when creating wireframes in the later step.
Are.na is a great research tool for collecting ideas and recognize patterns! Highly recommend 👍
Break down the user flow
With the whole picture of the context and problem at hand, I moved forward to specify “When & Where will a sales rep get to deal with duplicates in a CRM tool?” and “What are the tasks needed to be completed?” I identified 3 scenarios when duplicates may occur throughout a sales cycle, as well as a series of steps a sales rep gets to take. For each scenario, I also clarified the technical assumptions the scenario is based on.
With the time limitation, I decided to scope down and chose Scenario C (as it has the fewest steps 🤫) as my direction to move forward. If this were a real product, I will consider and do further research into the following aspects to make decisions:
👥 I’d like to understand the problem further from users’ points of view. I would ask “Which use case is the most popular one?”, “Which steps do sales reps have the most problems with?”, etc. I would use methods such as user interviews, contextual inquiry, etc.
⚙️ I’d like to talk with the engineering team to know more about “How’s data structured on the backend?”, “What are the criteria the system uses to find duplicates?”, etc. Being aware of the technical capacities and constraints can help generate solutions that will work best.
Generate ideas on paper
I tried to quickly sketch out the key screens to support the flow in Scenario C. When working on the wireframes, my focus was not the content ❌ (e.g. duplicates’ types), but the layout & interaction ✅.
Wireframes demonstrating Scenario C's flow
Step 01 Exploration: different ways to display duplicates
Step 02 Exploration: different ways to edit duplicates
If I got more time, I’d like to gain more insights into sales reps’ behaviors and habits (maybe observe how they manage data using a CRM platform) and make more explorations around that.
I got to create one mid-fi screen to demonstrate the "drag-and-drop" idea.
The conflicting information will be highlighted in red. The consistent information will be highlighted in green and put into the "Merge" column automatically, but users can still edit them.
While it’s impossible to cover every aspect in solving a design problem with limited time and resources, I’d still like to address a few points:
“Why would duplicates occur?”
Although I didn’t dig deep into this question, understanding the root cause of duplicates can shed light on solutions that may be outside the realm of product design. For example, it may be impossible to avoid duplicates when many different team members are putting in new data at the same time. In this case, creating a process for the whole team to sync on updates may solve the problem!
“How to measure success?”
While analyzing the 3 different scenarios, I thought of 2 indicators—”time spent & success rate in completing a task”—that can be used to evaluate effectiveness during usability testing, and further be used to measure success after launching.
“How to decide which option to go with?”
After exploring a few different ideas, it’s time to prioritize and choose the optimal one. However, there’s no single perfect solution: there will always be upsides and downsides. In addition to evaluating them based on “Which one can achieve users’ goal most effectively?”, I’d also put them into an Impact/Effort Matrix map to consider things such as implementation cost.