Today we live in a world where software distribution is continuous, software consumption is diverse, and user experience is paramount. The concept of the 'model year' no longer is a viable solution in todays world and we have fierce competition. Innovation is no longer wishful thinking achievable only by the intellectually superior and well-financed.
We need to validate assumptions, iterate, and get products that improve lives into customers' hands in weeks not months or years. If we don't, our competition will.
The specific steps I use when designing a product is always customized to the company, personas, business goals, and team I'm working with, but the overarching process remains the same: understand the user/problem, validate assumptions, create potential solutions, test, and repeat until we've achieved the desired job to be done based KPIs.
It's vital to understand the problem we're solving before jumping to solutions. Some ways I accomplish this are through stakeholder interviews, market research, reviewing existing analytics and customer usage data. I do my best to understand the why not just the what.
It's also important to list all the knowledge we currently have about the problem into a list of assumptions ordered by risk. That serves as a baseline for future discovery & research.
Next step is to conduct generative research to validate our assumptions and get a more complete understanding of the problems users are facing that if solved could help us achieve our objective. I involve as many team members as possible with planning and conducting this research. If the whole team is able to participate in the research sessions, I will encourage us to divide and conquer so we can get more insights in a shorter amount of time.
Contextual inquiry is a great way of doing this, but there are other kinds of generative research I can use as well including:
Next is debriefing and determining design requirements that can help us achieve the business goals. This includes meeting as a team to share notes and come to a shared understanding of what was learned.
The goal at the end of this stage is to have an accurate understanding of our users, details around the jobs to be done, and validation of our previous assumptions. Some useful tools in this stage include:
Product needs go beyond just features. Plus we don't want to paint ourselves into a corner by committing to features before we've done any design/validation of potential solutions. Product needs include:
Before we jump into wireframes it's important to define the functional framework and data elements that will be needed. Taking the time to solve big problems at a high level first saves TONS of time later on. Some things I identify / iterate through in this step are:
There are various tools that can be used in this step depending on project needs and how complex the problem is. Not all are used every time but some that I've used in the past include:
After the functional & data framework has been designed, the next step is to design the interaction framework. I start at a high level first usually on a white board or on my iPad. I usually involve the entire team in this process.
Why? Because then the developers have enough to start building the data schemas and app framework. Product Management then has enough to start building out epics and creating high level roadmaps.
If I have time, I'll also often craft Key Path Scenarios so we all have an idea of the happy path. Nothing can derail progress like focusing on edge cases too early in the process. I get the key path worked out first, then consider other cases that need to be supported.
This is where I go into interaction design mode. I start out with low-fidelity wireframes and move into full-fidelity as I get feedback from users and the rest of the team. My goal is to explore many ideas and & validate them as quickly as possible, bringing in more fidelity as ideas get validated.
One important note here is that I show in-progress work to the team and thrive in environments where this is the culture. It's vital to get feedback before spending too much time on any design so that there is still time to pivot based on that feedback.
Tools here include:
This isn't so much the next step as something I do in tandem with concept refinement. It's a constant cycle through concept refinement and validation. Some methods include:
I also have ample experience with visual / ui design (both as a product designer and for 10 years before that as a graphic designer). Though in recent years I have grown to really prefer working within the context of living design systems. I love how it streamlines the design process and focuses both designers and developers on solving problems rather than spending days or weeks on visual styling.
I spent some time as a front end developer early in my career which has helped me be a great collaborator with developers as a designer. I can suggest libraries, help troubleshoot, and especially help ensure designs are getting implemented correctly. I take the approach of helping instead of just telling whenever I can. In situations where developers are offsite, I also have experience overcoming the jump to code for them and delivering clickable, functional prototypes so that can click around and see what the experience supposed to be.
© Copyright 2018 Jeremy Bird Design - All rights reserved.