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.
In modern companies past early stage startup phase, those determining strategic direction and which problems to solve and those actually solving those problems are most often different people. It's important that each group has ownership and that both groups focus on the customer first.
Many companies struggle to retain their best employees because they're too focused on themselves and what they want out of the relationship. I take the time to understand the process, skills, and professional development goals of my team and then jointly coming up with a "Tour of Duty" that will transform the company in some desired way as well as provide an opportunity/support for the employee to progress in whatever way is important to them.
This establishes a foundation for mutual benefit and trust and results in true innovation, improved morale, increased retention, and continued value to both parties long after the employee has left the company.
As a product design leader, I am very dedicated to giving teams problems to solve rather than solutions to implement. If you tell a team to "redesign the toothbrush" they will iterate on a new toothbrush design. On the flip side, if you assign them the problem of "how might we improve the teeth cleaning process for children" you will likely get an innovative solution that might or might not have anything to do with a toothbrush.
Creating teams that are able to focus on solving the same problem at the same time is also hugely important. It eliminates waste, and allows the team to work together, focus, and utilize the strengths/weaknesses of each team member.
Creativity thrives when teams are allowed to experiment, test, and react to learning. There are times when leaders need to step in and mandate a specific direction but those should be the exception rather than the rule.
I strive to maintain a balance of 10/80/10.
Many companies measure a team's progress and success purely on if they complete 57 points or if they hit their dates. Naturally hitting dates and working quickly are important, but they shouldn't be the measure of progress and success. The ultimate goal is the outcome.
It is very possible to succeed in output but fail in delivering improved outcomes, and if we fail on delivering improved outcomes to our users, who cares that we completed 23% more points this sprint than last?
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.