Human Centered Design is a problem solving framework used for management and product design that centers on the building empathy and relating to the human perspective as primary, and the technological tools as supportive vehicles as supportive of and for accomplishing human goals. Technology and software is a tool that is built for people. Remember, products that solve the right problems for the right people with iterative frameworks ameanble to adaptation and constant learning provide value and succeed. I have incorporated HCD or Human Centered Design approaches in my product development using what we used to call "Design Thinking Excercises", workshops and the like for many years. I have lead many teams delivering user centered design from C level Corporate Leaders and teams, led and Trained Corporate Buisness and Product Owner Teams in Product Discovery excersizes, trainied both Product Mangagers, Designers, and Corporate Product Teams who want to adopt more user and human centered practices into thier process. It works. Design that takes a Human or User Centered approach leverages best practices in mixing divergent and convergent thinking and collaborative practice wherein we empathize, define, ideate, prototype, test, implement, and retest. This aligns implicitly with AGILE software development in that Products taht succeed are focused to align with Business Objectives and User needs ensuring alignement with solving the right problems for the right people and thereby deliverying value.
The following are a few standard excersizes that teams will perform during Product Discovery that use Human Centered Design principles. These can be scaled as needed per project and product developemtn context. At minimum I suggest you ensure you define the problem you are solving, the context in which its being solved techincally and socially (Product exsist by nature in a sociotenchical context), and the users you are designing for.
- Problem Statment Definition
- User Personas
- User Flows
- Customer Journey
- User Interviews
- Affinity Mapping
- Lo-Fidelity Wireframing
- Hi-Fidelity Wireframing
Goal: To clearly define the problem the Product will set out to solve. This information and creates a baseline of what is known about the problem space to generate initial questions and hypothesis development for how we might creat a solution. Identifying and enumerating WHO, WHAT, WHY and WHERE the problem takes place the solution.
How-to:
- Create a collaborative workspace using tools like Mural or Miro or by using a room full of people and a whiteboard.
- Break down your board into 4 sections: Who, What, Where/When, Why
- Brainstorm Personas - Time box (5 minutes) a brainstorm where everyone individually writes down on 'sticky notes' the people who A.) impacted by the issue at hand B.) will benefit from the solution.
- Group these persona's or future users into logical groupings. You now have your main personas.
- Vote on the order of importance of these users to identify primary and secondary personas
- Brainstorm Personas Concerns - Time box (5 minutes) a brainstorm where everyone individually writes down on 'sticky notes' what we know about these personas or future users. This ranges from who they are and what they do to what they are responsible for, and what they care about.
- Group them based on logical groupings.
- Theme the groupings based on the theme that emerged.
You now know more about the users, the Personas you will design around, and the WHO we are building our product for.
Goal: To define the problem with a user focused lense. Think about "What is the problem from our Personas Perspective?" Is it easy to explain? Is it a real problem? Have we got any evidence? e.g. TBD
For each Persona:
- Brainstorm Problem - Time box (5 minutes) a brainstorm where everyone individually wites on 'sticky notes' the facts of the problem.
- Group the facts if there are overlap
- Vote on the most important facts. 3 votes per person.
You now have your hypothesis for the top Problems for your Personas/Users identified. This can later be validated by further user research, surveys, and user interviews.
What is the context in which the persona is experiencing the problem?
Can we easily explain the context?
Have we proof of the problem happending in certain contexts or spaces?
Goal: Give context to the environment that the problem occurs in.
For each Persona:
- Brainstorm Context - Time box (5 minutes) a brainstorm where everyone individually writes on 'sticky notes' thier understanding and ideas of where these problem happen considering the above questions.
- Group the contexts logically
- Theme the groupings
- Vote on the most important contexts
- Document these
You now have your hypothesis of where the problem occurs. This can later be validated by user research and user interviews.
Why do we care? What is the most important value for the Persona/user?
What is the most important value for the organization?
Why is it worth our investment?
How does solving this impact or relate to our business goals? KPI's?
For each Persona:
- Brainstorm Why's - Time box (5 minutes) a brainstorm where everyone individually writes on 'sticky notes' answers to the above questions
- Group these answers logically
- Theme the groupings and identify the main theme
- Document the main theme groupings by each persona
For the Business or Organization:
- Brainstorm Why's - Time box (5 minutes) a brainstorm where everyone individually writes on 'sticky notes' answers to the above questions
- Group these answers logically
- Theme the groupings and identify the main theme
- Document the main theme groupings
You now have your hyothesis on why this issue matters and why we should invest in solving it for users and the organiation. This can and should be validated with your Product Owner and the Business or organization the project is being sponsored by. Add any additional learnings to your documentation when this becomes validated.
Now that we have a hypotheseis derived from our understandign of the users issues, we can synthesise our problem statement.
For each section (and for each persona), WHO, WHAT, WHEN/WHERE, WHY:
- Summarize and clearly articulate in a few sentances the main learnings and hypothesis.
- A clear picture should emerge. If not, go back to the sections previously and consider why or why not.
You now have an articulation of your problem definition that the product aims to solve.
To promote developing a product that is designed for users we must first identify our users and understand their needs and perspectives. We create User Personas to do this, imagining users' needs and demographic information supported by secondary research and product goals. We already brainstormed who is impacted by the issue, and therefore who our product users will be in the Problem Statement Definition exercise. Lets go a little deeper into what thier conerns might be and who they represent. The idea with Personas is to create a notional biography for who they might be, what their role in the organization might be and therefore allow us to emapthize with them as we design the product solution with them in mind (read, for them). This is another way we ensure that we are designing technology solutions for the users- who are human people, with human problems.
For each Persona identified:
- Create a niotional Biography for who they might be. Include information such as:
- Name
- Role
- Age
- About Me description
- Location: Where I might live
- Workplace: Where I work and what type of environment it is.
- Age
- Activities: What are the relevant things I do in my role that are related to the problem we are solving
- Pain points: What would I say are issues and pain caused by this problem. You can pull these from the Problem Solving Definition most likely. You can also validate these and add to them based on user interviews and or surveys.
- Delights: What are the good things that make my day easier or that I enjoy about my work.
You now have your notional user Persona. This will help the Product Developkment team empathize and track decisions back to human users. These ideas should be validated by your Product Onwer/Client and validated through user interviews and or surveys.
We must understand the current user flow to then map out the journey and find user pain points so we can identify areas to design solutions around. Once we've done this, we can produce a Target State or Aspirational User Flow which describes the flow that users go through in the process that they are undertaking when using the product or service.
- Interview your stakeholders and users who are working in the problem space and have them walk you through the steps they take currently to accomplish the goal the product will solve.
- Often times a product is designed to automate a previously manual process. As we document the manual steps we also document the user pain points and can see opportunities for design and product touchpoints for where the production you are designing could provide value.
Mapping the user journey starts with the existing user journey and moves to an optimal journey map informed by discussions with potential users matching our main user personas. Here we empathize with the user and can identify solution opportunities and touchpoints that our product or service can do to enhance the user experience and solve for the problem our Product or service is targeting.
Here a links to a few solid example templates: <>
User interviews are a poiwerful way to create and validate your current and target User Flows and Customer Journey Maps.
Individual user interviews should be time boxed, and conducted with a prepared set of questions. Best Practices include questions that are non-leading, and are both yes no, qualitative and quantitative. Users should be made to feel comfortable and appreciated for thier time, as it is often given for free on a volunteer basis. It can also be a great opportunity to generate support for your project. Users who feel listened to and are having thier pain points heard are often excited to see the results of that input generated as a helpful and concrete solution. Ask your interviewees if you can follow up with them to gain validation when th designs or product pilot is ready for validation.
This is another effective way to cast a wide net and gather lots of valuable intformation for your product discovery and evleopment. Survyes can be used to assess interest in a product, gather information on the value of certain features by asking rank and priority type of quesitons, and for understanding user pain points and gather examples of real life use cases for which you hope to solve and aid with the product/solution you are developing. Best practices are to set a clear goal for what you are trying to understand, designing good questions that get to the heart of the information you are desiring to learn, and recruiting the right participants for the survey so you are getting useful and relevant answers. See Affinity mapping for a usefull approach to synthesising lots of qualitative information.
Here are some links to more information on user interivews. There are many great resources out there: Shopify Blog on How to Conduct a User Interview UX Collective's How to conduct user interviews Sarah Doody's Starter Questions for User Research Mind the Product's Articles on User interviews Mind the Product's Training Course on User Interviews
Affinity mapping is a process that allows teams to sythesise lots of qualitative research quickly. It informs our user stories and product development approach and helps us prioritize features. It is an approach to synthesizing large quantities of qualitative data into logical themes. This approach supports the synthesis of brainstorming, and user interview surveys, and other pieces of qualitative data. We can do designthinking exercises throughout the discovery process, such as a Problem Solving Workshop with multiple stakeholders providing input to a question around 'what problem are we solving for, or 'who are all the user impacted by this', where everyone writes things down, then we use Affnitify mapping to group them into logical buckets, categories or themes. The themes become representative information resultant from multiple inputs. It is very efficient. Another example is User Survey Results. We can solicit, say 10 questions from many users, and using affinity mapping sythesize the results of each question and distil themes from the answers. These themes can be used as information for the Product Manager/Owners and Designers either by directly becomming Epics (broader themes to build features around) or as input used to inform prioritizatoin of Epics and User Stories.
The Design Team creates low fidelity wireframe mockups for concept testing. They create many sketched versions which are then paired down and refined through an iterative process of review by the Product Manager and Product Owner, team voting (based on which most successfully accomplish the product goals for the users), and through concept testing with potential users to gain insights and feedback. This feedback is then integrated into digitized mockups with higher fidelity. User Stories are then extracted by the Designers and Product Manager from the capabilties and functions that are enabled by the designs for the users, and added to and refined through the insights gained during this process and placed on the GitHub project board. The Designers own the delivery of the wireframes, and the Product Manager ownd the User stoires and the requirements and needs that the design must fulfill for the users/product.
Typically for efficiency we will start with low fidelity wireframes. This allows the designer to start build a scaffolding of the application/solution, and will allow front end engineers to work in parrallel as the design iterations move to a higher fidelity.
These should include an app structure, page flow and pages, major features and capabilties on each page, and . Where possible leverage thinking and design approach in terms of components, defining common app/solution design patterns, and resuable UX affordances. This will both create continuity for the user, and allow your Product Manger and Enginereing team to work in parralel as the desnger iterates to higher fidelity. For the most part all feaures within should be able to be built and delivereed during the scope of your MVP engagement and delivery.
These should include color choices, affordances (drop downs vs multiselect), refinements of feature functionality and more detailed capabilities. These can incldue nice to have featuresm taht may not make it into the MVP build, but represent what the full solution int hefuture would, should, could do, and look like. The feauters and user stories that are represented and extracted from these mockups can be used for user validation, and by the Product Owners, your Produt Manger, and Sales or Business Development folks to generate excitement around the vision and promise of the product and generate momentum and product launch preparpation and a viable product roadmap to be executed after the MVP delivery.