Every step of the process should be documented in a design notebook for future reference. The process isn’t necessarily purely linear; it’s expected that you’ll sometimes need to jump back to a previous step to rework something and then work your way forwards again.
During each of the three phases we start by generating a huge amount of information and ideas (research, ideation), and for the end of the stage we consolidate everything down to what’s important (problem spec, concept description).
Other stuff
Participatory design
We can either design for, design with, or design by.
- Designing for is where you design something on behalf of a stakeholder, with the stakeholder being completely hands-off. It works well when requirements can be completely enumerated, and it saves stakeholder time. There’s a risk of delivering a solution which doesn’t adequately meet the stakeholder’s needs. This is comparable to waterfall design.
- Designing with is where you check in with the stakeholders constantly, allowing them to contribute ideas and feedback for every step. This requires a lot of time and effort from the stakeholder, and the stakeholders won’t necessarily have a high interest in the design process in the first place. It is useful in situations where stakeholders are genuinely interested and invested in the design process, or where stakeholders might feel sidelined if they aren’t given avenues for providing feedback.
- Designing by is where you help the stakeholders to complete the design process by themselves. This is an educational approach, and is useful when the stakeholders will need to maintain the project or start work on new projects in the future without someone to guide them along. Helping people to help themselves.
Problem design
The purpose of this section is to figure out the shape of the problem space.
- What need is being solved?
- Who has the need?
- Where is it needed? (this ties into the concept of place, where requirements are shaped by local context)
- When do they need it? (time is always a key constraint)
- What are our limits?
Problem statement
We begin with a high-level problem statement to set our direction throughout the process. The statement must not constrain us to any particular solution (it must be ‘solution neutral’), and it must not mention any details (to keep it high level). It will be useful for figuring out at every step of the process whether we’re on track.
The example given to us was “how can we help patients recover their arm function more quickly and easily after a stroke?”
Understand
To understand the problem space, we need to research (look for facts), observe (look for behaviours), and analyse stakeholders (look for priorities).
We can research:
- History
How has this problem been solved in the past? What products or technologies currently exist? What succeeded, what failed, and why? Have similar problems been solved in other industries? What are common issues, complaints, or failures with existing solutions? What is the timeline? Have there been any case studies performed? - Geography
Where will the product or system be used? Is it hot, humid, hilly, rural? Is there ample sunlight and clean water? What are the local resources and infrastructure? Is there a supply chain for replacement parts (what resources are needed during operation)? Are there people who can maintain or repair the product? - Science
What are the scientific principles underlying the product? Has any relevant research been conducted? What material properties are required? - Laws and regulations
Are there any legal requirements to fulfil (building codes, international standards, government regulations)? Are there any safety issues (such as choking hazards or toxic materials)? What relevant standards exist? Are these standards mandatory or voluntary? Are there any existing trademarks or patents related to the product? - Markets
Who needs this product (age, occupation, income, location, lifestyle, industry, experience level)? How many people need it (potential users, growth trends, industry reports)? How do they currently deal with the problem, what do they like or dislike, what features matter most (surveys, interviews, focus groups, observations, customer complaints, forum posts)? How much are they willing to pay (current market prices, premium and budget segments, customer expectations, cost-benefit tradeoffs)? Who are the competitors in this space, or previously in this space (features, capabilities, materials, price, strengths, weaknesses, reviews, target customers, availability, approach)? Is there an unmet need (underserved market segments, customer dissatisfaction, product positioning)?
Some of this research is very granular, some of it is higher-level. We can create a hypothesis from our research. The example given to us was “if the patient has controlled support for the affected limb, [some particular adverse muscular phenomenon] will be avoided.” Another example which emphasises market research is: “Most commuter cyclists prioritise waterproof storage and ease of carrying over maximum storage volume. Existing products often sacrifice waterproofing to reduce cost, suggesting an opportunity to design a moderately priced bag that offers both waterproof protection and convenient portability.”
When observing, we can look at people (how do our users behave?), organisations (how do different organisations interact with the product?), communities (how do communities talk about and think about the product?), and actions and stressors.
- People on the edges will have the most difficulty with our designs, so we need to focus on them more. Comparatively fewer people from the middle will need to be studied, because there’s less diversity there and they’ve easier to cater to. A focus group gets together a group of similar people; an ‘unfocus group’ gets together a diverse collection of different people.
- Observe body language and movement. Do people have only one free hand when performing a task?
- Consider paradoxical behaviours, all of the things that people will do with or to your product that you never considered. How can it better accommodate or withstand these behaviours? These will likely be mostly stress or damage related.
- Look at your users and see what they see from their perspective. Go to where they are, don’t have them come to you otherwise you lose important context.
- Observe what people say or do in order to figure out what they’re thinking or feeling. Keep in mind that people will describe things relative to their own experiences, not yours, so look at the bigger picture and don’t take their word for things. Find ways to double-check.
- Try to understand why people make errors during tasks. There’s always going to be a reason for why someone does something a certain way that made sense to them at the time, probably related to affordances.
Stakeholders can include employees, maintainers, operators, suppliers, local residents, educators, students, builders, manufacturers, peers, influencers. We need to figure out how each stakeholder changes the dimensions of the problem being solved. How does each stakeholder influence the project? How do you talk to / communicate with each of them? What questions should you ask each one?
Stakeholder analysis is done using a two by two matrix, with level of power and control going upwards and level of interest going rightwards. People with power need to be kept satisfied, people with interest need to be kept up to date, and people with neither can be disregarded. The key players are those with both. This matrix is less of a rigorous framework and more of a brainstorming tool.
Define
Next we define our problem in detail. We collect all of our understandings, figure out what’s important, and use this to create a problem specification that details our constraints while not yet offering a solution (we don’t want to prematurely restrict our concept space).
Problem specification
The product specification should be something like a full A4 page of bullet-point details. What’s important? What describes the problem? What are the constraints, either vital (needs) or preferential (wants)? What are the requirements from each stakeholder? We’ve been given categories of product identification, special features, key performance targets, service environment, key project deadlines, physical description, market identification, life cycle targets, and social/political/legal requirements.
We’ve also been given the following categories, with an example being the design of an e-scooter rental business:
- User requirements (ease of use, safety, function, accessibility, cost, ease of maintenance)
- Constraints and controls (laws, budget, schedule, speed limit, manufacturing limitations)
- System requirements (mobile OS compatibility, traffic rules??)
Conceptual design
Ideate
To brainstorm, a group of 6 to 12 people should aim to come up with around 100 ideas every hour. Build on each other’s ideas, defer judgement until later, aim for bulk and variety. Ideas with common features can be grouped and categorised later. Use a list instead of a mind map structure to make it easier to add ideas that don’t fit with what’s already been listed.
Functional decomposition is another approach to ideation where you list out all of the capabilities or functions required by a product and then brainstorm forms/solutions for each of these functions individually. If a device needs a screen, list all of the different forms of screen you might consider. Functions can sometimes be broken down further: for example, for a device requiring input you might list buttons or touch input, and then break down into different types of buttons (switches, micro switches) or touch input (finger, pen).
Morphological analysis is much the same as functional decomposition. Create a list of functions down the left side of a page, and write out potential solutions extending out to the right. Once you’ve listed out the solution space, you can pick one solution from each row to create the product.
Select
The select stage is where we objectively evaluate all of the concepts from our list and pick the best. Our decisions must be credible, traceable, and participatory, they need to be able to stand up against lawsuits and audits in the future and to refute accusations of negligence.
Start by combining similar ideas and discarding infeasible ideas. Next there are two different ‘objective’ methods for selecting a final concept, but MART analysis is the one we’re expected to use. The other technique is called plus/minus/interesting, where you list the benefits, drawbacks, and any interesting points of note for every option. I think the idea is that you pick the one with the most plusses, or at least that it informs your choice a little more.
MART analysis (Multi-Attribute Rating Technique) is a technique where you assign numeric values to different attributes and then you calculate a weighted total for each option based on this. Start by deciding on the criteria that will be used to evaluate the designs (for example, cost, adjustability, educator burden, durability). These should be selected from the problem specification.
Next, create a table with the criteria listed listed across the top and down the left-hand side. In each cell, write a value representing how important the row criterion is compared to the column criterion. 2 is more important, 1 is equally important, 0 is less important. Cells along the diagonal should be blank, and paired cells reflected across the diagonal should sum to 2 (that is, values should be consistent). For designs that are high-impact, heavily regulated, or have high costs, each number will have a few paragraphs of justification attached to it. Sum up the rows in a column to the right of the table to find the ‘weight’ of each criterion.
Next, create a new table with criteria listed down the left side and concepts listed across the top. Each criteria has a weight value from the previous step, and each concept has a score column and a weighted score column (equal to score times the criterion weight). For each concept, we fill in the score cell for each criterion based on how well that concept meets that criterion. 4 meets perfectly, 3 meets well, 2 meets satisfactorily, 1 meets poorly, and 0 does not meet. Calculate weighted scores, and sum each weighted score column to find the overall performance of each concept. The concept with the greatest performance value is the winner. We should either go with this concept, or if it performs unsatisfactorily under some criteria we should loop back to the ideation stage to develop a new concept that improves on this.
Concept description
A description of the chosen concept? This wasn’t explained.
Detailed design
Prototype
Prototypes are a way of quickly answering questions about our design by testing it out physically. How well will the idea work? Will our users accept it? Can we build it? We don’t want to build a finished product, we want to focus instead on specific pieces of uncertainty or risk. A prototype shouldn’t be too complicated or take too long to build.
There are many types of prototype:
- Scale model
Assess the appearance of something, or test if things are physically compatible with one another. - Works-like prototype
Has the same function, but isn’t made of the same materials or in the same shape. Good for testing isolated mechanisms. - Process prototype
Play around with the order of steps in a process, or visualise a workflow between different screen in a computer program using UI wireframes. - Looks-like prototype
A detailed appearance prototype with no functionality, made of a simpler material but dressed up or painted to look close to final. Useful for surveying users. - Role-playing prototype
A physical analogue to the process prototype. Place boxes around, pretend to perform tasks on machines. - Benchtop prototype
A more advanced works-like prototype. The guts of a machine with no container to hold it together, tubes and wires sprawling out on a bench. If the system is massive, this would be scaled down to fit in the workshop.
Analyse
Analysis is a way of address questions mathematically. Like with prototypes, we’re not looking to analyse every facet of the system, we’re just looking to find approximate answers to specific questions. How large will it be? How much power will it require? How secure is it? How many parts does it need? How fast will it be? We’re looking to do back-of-the-envelope equations.
Different types of analysis are structural, mechanical, electrical, thermodynamic, computational, chemical, cost, and business.
Test
Tests are what you do with the prototypes and analyses from above. Did we make the right choice? Was our final concept capable of meeting the requirements? Focus on the part tthat has the greatest risk to the success of the project.
Three types of testing:
- Technical testing (is this feasible?)
Does it meet the technical requirements set out in the specification? - User testing (is this desirable?)
- Financial testing (is this viable?)
Test the extremes, not just normal conditions. Test it with different types of people. Test what happens if someone tries to break it.
Implement
Finally, the design documents need to be written based on the fact that you are not the person who is going to make the thing you’ve designed.