Sales Resource App
Providing Sales People Access to Everything They Need to Make a Sale While On-The-Go
BUSINESS OVERVIEW
One of the company's main goals is to sell devices that increase microcirculation, which helps buyers with a variety of health issues. My team was tasked with creating an app that assists 200+ independent sales representatives (IBDs) to increase their sales.
THE PROBLEM
It's difficult for these salesmen to sell a multi-thousand dollar device to people who often have a hard time understanding what the product is or why it might benefit them. Most of them have had little to no sales training and the sales team needed support.
HIGH LEVEL TIMELINE
1 month - Designed to be programmed and completed in 50 hours by one software engineer intern.
MAKE OF THE TEAM
-
Founder of the Company
-
UX Design Strategist (me)
-
Software Engineer Intern
KEY GOAL
Create a product that improves the experience of selling on-the-go
MY ROLE
Bridging the gap between the needs of the business and the needs of the software engineers.
One of my most essential skills was being able to speak the language of both the stakeholder and the software engineer. I was able to communicate their values and find compromises in the design so they were both satisfied with the product and the process.
Efficient UX/UI design and rapid prototyping
Given the constraints of this project, having a realistic yet ambitious timeline was crucial for getting deliverables to the software engineer before they needed them to continue work. I was able to stay one step ahead by designing quickly and involving the stakeholder in all major decisions.
MAIN CONSTRAINTS
Overcoming learning curves with a time pressure
-
Limited knowledge - None of us had created an app like this and this was our first time working together as a team
-
Time - We needed to complete it before the software developer's internship ended — he had committed to 50 hours total.
LEARNING CURVES
We hard a hard time...
-
Determining the scope and sticking to it
-
Prioritizing getting things right when they're hard for the software developer to change
-
Designing feasible features
-
Sticking to the waterfall methodology as we learned more
Communication and collaboration were crucial
We depended on each other for guidance at each step.
We needed to know where everyone was at with their role, what they needed, and who could help them.
ORGANIZING
CONTENT
Finding and organizing the most relevant information in a way users would understand
The information architecture was interesting for this product because more senior users had a shared understanding of where things would be located since they've been through a series of training events together, but the system wasn't intuitive for new users.
I spoke to users one-on-one and in group settings to hear their concerns and find out what they valued. I also looked at the results of a survey conducted previously to extrapolate relevant information from a larger pool of users.
After gaining some insight, I used card sorts to structure the information. I would have liked to have had users participate more, but it ended up just being me and the founder of the company. We did several rounds and got feedback from a group of users until we had a version that everyone agreed upon.
TITLE OF THE CALLOUT BLOCK
THE DESIGN
I started by sketching
I sketched each unique screen and designed a layout that could be used for numerous screens that had a similar function.
After talking to our software engineer, I tried to keep things as simple and straightforward as possible so it would be feasible.
Wireframing/Prototyping done using Figma
Using a consistent design for the majority of the screens allowed me to generate digital screens quickly. Keeping them simple and consistent was also important because the software engineer would have to recreate them for the product.
Designing and articulating the user flow
I used Figma to arrange a digital version and then I printed out large versions of the wireframes and put them onto a tri-fold poster so the team had a physical product to work with and use as a reference. This allowed less tech-savvy users to provide feedback as well.
TITLE OF THE CALLOUT BLOCK
PRIORITIZATION AND PROBLEM SOLVING
It can be harder to develop features than it is to design them
Once the design was in place, I worked closely with the software engineer to brainstorm options for features that would be challenging to bring to life.
We went through and prioritized based on if it was easy for him to create, important to the stakeholder, and valuable for the users.
Our options were:
-
Scrap the idea and remove it from the design if it wasn't worth the hassle.
-
Redesign to accommodate a similar feature that would be easier to develop.
-
Encourage him to move forward despite it being difficult for him.
-
Nudge the stakeholder to reconsider how important a feature really is in the grand scheme of things.
We repeated this process for as many features as we could until we reached the end of his internship.
TITLE OF THE CALLOUT BLOCK
LESSONS LEARNED
A good design considers what's good for all parties
It's important to take a pragmatic and holistic approach when there are constraints and limitations. As a problem solver, you sometimes have to solve for more problems than you anticipate. Working in a collaborative, transparent, and supportive environment makes it easier to create a product efficiently.
NEXT STEPS
Evaluating the design and iterating
-
Usability tests - I want to learn how useable this product is
-
User interviews - I'm interested in exploring the needs of the users more and seeing if the current design solves them well
-
Redesign based on insights