Building a "LinkedIn" for Pharmaceutical Companies
Product Designer – Komodo Health (B2B SaaS product) – June to September 2018
• User research and competitive audits
• Paper/pencil sketching and low-fidelity wireframes
• Using Sketch for high-fidelity mockups
• Prototypes using Principle & InVision
• Hosting cross-functional design critiques and reviews
• User testing and surveys
• Engineering handoff (via Zeplin) & deployment
• Product Designers
• Product Managers
• Full-Stack Engineers and Engineering Managers
• Customer Success Managers
Problem and Context
Research from user interviews show that the current tools, procedures, and communication methods that most MSLs use don't yield enough successful engagements. Many users simply Google search a doctor's contact information and cold contacts them – a not very effective strategy.
• Successfully engage with target users
• Expand network of doctors
•Drive up product renewals
•Boost engagement on Lists product, measured via monthly active users
• Increase user satisfaction, measured via net promotor score
Understanding Users and Building Empathy
To kick start the research I needed to do to better understand these users, I used these guiding questions:
• How are users currently using this feature? To what extent do users use this feature effectively?
• Where do users become frustrated and why?
• What parts of the feature/interface are being used, and what's not?
I used a combination of four methods to gather qualitative context and quantitative data on our feature, build empathy, and build a stronger case for a redesign:
1. User Session Recordings through Fullstory
2. Usage Metrics/Click Data
3. User Interviews
4. Customer Success Manager 1:1s
Research findings helped me build out a user persona of a potential user to better summarize key user information
I conducted a design audit to identify usability issues, visual design hiccups, and heuristic violations
User Flows and Initial Brainstorming/Sketches
I created a user flow map to capture the experience of using this feature and to map out interactions, emotions, and edge cases. This user flow map also helped identify gaps in the user experience that would need to be accounted for. While the original user flow map was rather simple, multiple workshops with CX and PM allowed me to further iterate.
The original design had only one list – the engagement list. The new design included a second list of influential doctors whose networks could be leveraged, side-by-side with the original list. To explore ways of presenting a second list, I sketched 16 different initial layouts.
After evaluating designs with the design, product, and development teams, many of the original 16 designs did not make the cut because of usability or feasibility concerns.
After lengthy design meetings and critiques, I decided that the "Right-Panel Design" was the best layout option to explore. I proceeded to build out the "Right-Panel Design" in medium-fidelity. However, we found that the distribution of space was uneven and unbalanced.
To make space for a second list, I had to find a way to remove the List Panel originally on the left of the screen. To keep every part of this new user experience approachable and understandable, I iterated on a number of micro-interactions expand and collapse the List Panel. After testing and feedback, I found that the third option (below) was the most preferred option for this particular interaction because it was explicitly clear both in copy and layout where the different elements were moving in and out of on the screen. There was also persistent copy (not just copy on hover), which helped improve understanding.
Prototype of list panel expand/collapse interaction
Visual Design Iterations
An important aspect of the user experience is using visual design (i.e. colors, typography, themes, etc.) to inform content and hierarchy. One such consideration that arose surrounded distinguishing between two similar-looking lists. The solution was to use two different colors, one corresponding to the larger list on the right and one corresponding to the smaller list on the left.
In choosing colors, we needed to keep in mind a number of factors, including :
• contrast and readability
• display color profiles
• cultural meaning & significance
• existing color usage throughout the system
For instance, we steered clear of red hues because of their association with destructive actions and steered clear of blue hues because blue was already widely used throughout the system (so it had an already set meaning).
I ended up choosing Color Option D, or the orange option, because it provided the best accommodations for accessibility, contrast, and usage.
Evaluating and Testing Designs
Cross-Functional Design Workshops
To ensure cross-functional team visibility throughout the entire design process, I held weekly design workshops with my PM, CX lead, and key engineers. These half-hour sessions were focused on gaining open, broad ranges of feedback from scoping, usability, feasibility, and visual design.
Formal Team Design Reviews
I held formal, hour-long review sessions with the entire product, engineering, and customer teams to inform those teams of near-final designs. Each discussion revolved around the priorities of each team and how the designs were or were not addressing those priorities.
To collect asynchronous design feedback, I placed large poster boards in high-traffic office areas for 2 weeks to gather feedback. I included specific questions to help guide feedback and a pad of sticky notes to encourage team members to write down their thoughts.
Micro-interactions and UI components required further quantitative testing, because the initial design intuition was not sufficient enough to land on an optimal user experience and build consensus. to address these concerns, I designed and distributed a survey through our customer team to gather feedback on interactions and WIP designs.
Final Design and Retrospective
What I'd do differently
1. Gather insights from brand new users (as opposed to only those who already use the product)
2. Reducing the number of new changes all at once would make it faster to develop and evaluate from a metrics standpoint