Product Design Process

This page is dedicated to talking about the bread and butter design work that I did during my time at Mitchell specifically between May 2016 and August 2019 when I switched over to innovation work. Mitchell taught me some of my most valued skills about how to do design work in a business - how to be cognizant of business goals along with user goals, how to maintain alignment in cross-functional teams, and how to make good design decisions and communicate them clearly.

This page covers a high level overview of that process, as well as some artifacts that are typical of what I would produce when working on these types of projects.

General Process

STEP 1: Understand the problem space*

• Gather information - what do we know? what do we not know? what do we assume?

• Explore existing functionality - current product and past product, what are users used to?

• Document the goals - user goals, business goals, design goals

• Define success - get XD, PM, and Dev to agree on what the minimum viable experience entails

STEP 2: Visualize the workflow*

• Spell out the experience step by step

  • What is the user thinking?

  • What actions will they take take as a result?

  • What needs to be on the screen to support these actions?

STEP 3: Design and iterate*

• Sketch in meetings with PM to agree on basic approach

• If additional visualization is needed, come up with initial mockups

• Review mockups with PMs and devs to ensure everyone's still on the same page

• Get it reviewed by the XD team

STEP 4: Spec it out for developers

• Make it clear what the new thing is that they're building

  • Separate the phases, but give them the whole picture

• Make reference to style guides and existing classes

• Specify intended interactions

• Put all the resources in one place and make them as easy to understand as possible

STEP 5: Support ongoing development

• After design hand-off, be available on call to answer questions

• Check in and review progress

• Offer consultation on local instances of the code

*Research

• The need for research varies significantly from feature to feature

• Generally the need for research is determined when necessary information is unable to be derived from existing sources (previous research, SMEs, customer requests, logic)

• Where this breakdown in information happens determines what type of research is needed

  • Unsure what the users actually want? Unable to write clear requirements? Don't know what success looks like? – Discovery research

  • Have a couple possible directions and unsure which one to go with? Need to make sure someone will be willing to pay for it? – Concept validation

  • Want to make sure you’re still tracking with prior research? Need feedback on final fit and finish? Want to feel confident that it will be used as intended? – Usability testing

Case study: Breakeven Experience

Context

When an estimator goes to add a part to the estimate they are often faced with the choice about whether or not it's better to repair the existing part or replace it with a new part. There are a lot of factors that go into this decision, and the purpose of this feature is to alert the user when the alternative choice may be more advantageous.

One of our legacy products already had this feature but the way the information was presented could be improved upon. It also existed in a simplified form in the current product (Mitchell Cloud Estimating) but it needed to be updated in order to calculate based on all the factors.

The challenge as a designer was to present the right amount of information at the right time for the user so they could understand and trust the alert without being overloaded or distracted.

Results

LESSons LEarned

• The job is roughly 20% design work and 80% getting alignment

  • Listen, play well with others, understand why you’re doing what you’re doing

• Collaboration helps build and maintain that alignment

  • Valuing their input helps maintain buy-in throughout the process, and makes for smoother working relationships

• Research is not the time to act like you know things

  • You do research because you have open questions. If you have access to users, be humble and keep asking questions until you learn what you didn’t know before.

• Prototypes and mockups are just communication tools - they’re not the only communication tools

  • Invest as much into making design artifacts as is required to get your point across. Sometimes this is a high fidelity interactive prototype, sometimes this is a whiteboard sketch.

• PMs and Devs are the users of your prototypes

  • Be aware of their goals and requirements and make their lives easier just as you would make the lives of your product users easier.

• Never stop experimenting

  • Always keep reflecting back on yourself, your process, your experience. Find new ways to work better, and don’t forget to try to make your own life easier too.