Product & Design Methodology
“The problem is always derived from the subject; the solution is always hidden somewhere in the problem...”
-Paul Rand, Conversations with Students
What is UCD?
User Centric Design or User-centered Design, is not just solving problems for your users, but incorporating users in your problem solving methodology. In other words, if the user is not involved in your decision making you are not following a user centric approach. When following a UCD approach to problem solving, every decision you make should be informed by User Research.
Sources:
What is User Research?
Qualitative vs. Quantitative
The goal of user research is to reduce uncertainty. User research, including Usability Testing, is divided by two methods, quantitative and qualitative. Quantitative methods are measurable and good for understanding user metrics like the time to complete a task. Qualitative methods on the other hand are good for empathizing with our users and understanding their emotional needs like fear of change.
Qualitative Methods
User Interview
Observation
Best Practices
Focus groups
Card sorting
Prototyping
Task analysis
Quantitative Methods
Heuristic Review
Surveys
First click testing
Eye tracking
Web analytics
A/B testing
Customer Segmentation
Primary vs Secondary
Primary research is research you conducted yourself and is applicable when you need to understand specific user needs. Conversely, secondary research is conducted by someone else and may be utilized for general user needs. Secondary research is useful when the research you need is more difficult than you can feasibly conduct yourself.
For example, you should utilize first hand user observation to understand how users interact with your product specifically.
An example of second hand research that would be too difficult for one person to conduct themself, is usability case studies by the Nielson Norman Group on the impact of load times on website abandonment.
User Research Documentation
Project Plan
The project plan is an excellent place to start defining objectives, formulate hypotheses, and plan user research methods. The high level nature of this document is designed to communicate value to stakeholders and define success.
Research Plan
This one pager defines the user research goals, questions, methodology, participants and schedule. This is important to keep participants aligned, and provides more granularity than the Project Plan.
UX Docs
Over the years, I’ve created my own comprehensive set of UX Templates. These are intended to be a starting point for documentation and each contain links to further reading. Confluence is my preferred place to keep documentation, so that product and development have quick access in a common ecosystem.
Who is a User?
Users typically breakdown into a few distinct categories. Deciding which design approach to take may come down to knowing which users will be affected.
Front-End Users: Customers over the web or through a mobile app
On-Site Users: Customers in-person
Internal Users: Operations, Customer Service, Finance, Marketing, Fulfillment, Admins. Anyone who works for the same company as the product
Clients: Clients who have been granted permission to use a given product directly
Developers: The software developers and engineers who build the products
When should I use a User Centric Design approach?
The most common approaches to problem solving are UCD, Genius Design, and Unintentional Design. Each approach has merit. Knowing which approach to use for a given problem will reduce confusion and problem paralysis.
User Centric Design
Applying user research, iterative design, and user testing to decision making. UCD is typically the gold standard in problem solving as it uncovers insights that you may never discover on your own. The time you may spend applying a UCD approach up front saves massive amounts of time later by not designing the wrong solution.
Use UCD if:
The project is attempting to change user behavior
Improve the UX (user experience) of our products
You are solving a problem for a user with a different role than yourself
Genius Design
Put simply, Genius Design is an approach that does not utilize user research. In this approach no research steps are taken and decisions are made by the Product Manager and Designer’s best judgement.
Use Genius Design if:
The solution is obvious
The technological constraints are such that no other solution is possible
The impact is so minimal it doesn’t warrant the time needed to conduct the necessary user research
Unintentional Design
This approach is when no Product or Design methodology has been utilized. A.K.A. ‘Developer Designed’, Unintentional Design may be necessary as a way of moving a project along without bogging down the front-end.
Use Unintentional Design if:
The front-end user will never see it
The problem is temporary and a fix is needed asap
As an iterative step to a larger solution
Sources:
What is Lean UX?
Traditionally User Experience can be a very heavy undertaking with a lot of time spent creating documentation. These more rigorous approaches are best utilized at companies with a dedicated team of UX Designers, who don’t work in an iterative fashion. Imagine if you were designing a new 9-1-1 interface. Your decisions have real consequences for the end users, and must be rigorously validated before you go to market.
Most agile development teams utilize a concept known as Lean UX, which can be described as an iterative process that utilizes the minimum amount of research needed to understand your users and validate assumptions.
Lean UX can be boiled down to three steps: Think, Make, Check. The process of Lean UX is iterative; build early, build often. These steps may look familiar, as these steps mimic the Scientific Method: Question, Hypothesis, Prediction, Testing, and Analysis.
Lean UX in Practice
Lean UX is built for speed, and plays nicely with agile development. In this instance we broke down a large project, deprecating a legacy product, into one week design sprints. In the above screenshots, you can see how aggressive a Lean UX approach can be. By scheduling User Interviews on the same day as the Kickoff, you can walk out of your Kickoff Meeting with a list of questions and get answers right away. You can then spend a good amount of time on comps and prototyping, before a stakeholder review.
Sources:
What is the Double Diamond?
Definition
The double diamond concept is visual way of representing problem solving. The double diamond was created by the Design Council in the early 90’s and has become more popular in the context of software development.
On the left side you start with a problem, represented as a dot. As you attempt to understand that problem you utilize divergent methods of thinking represented by expanding lines. You then take that understanding from the discovery phase and coalesce those findings into a definition, represented by the narrowing lines and subsequent dot. Once you have a clear understanding and definition of the problem you utilize divergent thinking again to develop solutions and finally convergent thinking to deliver the penultimate solution, represented by the diamond on the right side.
As represented the double diamond fits nicely with a Lean UX approach and is a good way to reference where you are in the problem solving process. As a project moves across the double diamond, a greater understanding of the user’s needs are obtained and regular check points with the stakeholders and engineering teams prevent developing the wrong solution.
Working Across Multiple Teams
This approach also works for projects that span multiple teams. In this example Team A may be assigned a project, but due to the complexity of the project, Teams B, and C will also be needed to complete the project.
Problem Phase
The project is kicked off with a Kickoff Meeting, so that all teams are informed and may provide input on the Project Plan. The kickoff is also an opportunity to define success metrics and decide what analytics may be used to asses the health of the project.
Discovery Phase
In the Discovery phase, the teams will diverge. Team A may conduct the majority of the user research, but Team C may be needed to complete a Dev Spike to gather more information about our systems. Team B may need to gather their own research as defined by the Project Plan.
Define Phase
In the Define phase, Teams A, B, and C will synthesize their research and gather all the insights from the discovery phase.
Project Check-in
At the Project Check-in, findings are presented from the Discover and Define phases, and the Project Plan is revised. At this stage the problems should be clearly understood and defined. If the teams are not aligned, more research and definition may be necessary. It is important that all teams are aware of the revised Project Plan, and have access to all of the research and insights from the previous phases.
Develop Phase
The teams then go their separate ways again in the Develop phase. Potential solutions are explored and tested. At this point the Product Managers and Designers should have a good idea of how to break the project down into stories and prepare assets for handoff.
Deliver Phase
In the Deliver phase, each team picks up the stories from their backlog and the Agile cycle of development proceeds.
The Solution
Finally, after each Team has completed their respective sprints, a retrospective ensures that all teams are once again aligned and the success of the project is assessed.
These regular convergent intervals, as defined by the Double Diamond, ensure that each team is fully aware of the project, even though one team may be doing the lion’s share of research and development. There’s no need to keep the other two teams in the dark. Even if the teams are not working on the same project concurrently, keeping the other teams in sync saves time and confusion later when the other teams have the resources allocated to work on their piece of the puzzle. Allowing other teams to provide feedback early and frequently prevents one team from developing a solution that negatively impacts the others.