Design concepts guide

Feedback is an integral part of the design process and should be sought out when designing anything, be it a product, service, or system. 

Your work will only get better

In design, feedback is a multi-step phase during which the design gradually reaches farther and farther outward from the core team to gather feedback from an increasingly large pool of feedback providers.

It’s preferable to gather feedback on several of the team’s design iterations. Through feedback, the team is able to understand which design ideas might hold up best in real-world conditions and which ones resonate most with participants. Feedback also allows the team to improve and refine the design iterations, using feedback reviews to gradually phase out design iterations that are less successful, while refining and focusing the more successful ones.

There is a cycle of feedback and revision for a single design solution. Two steps make up a feedback phase: 

1. Receiving the feedback from an individual or group and 
2. Making revisions to the product, service, or system based on that feedback.

In each feedback step, the circle of people the team reaches out to for feedback moves farther away from the core team and farther into the field of potential participants.

These feedback sessions can take the form of codesign workshops, prototype testing, or other formats depending on the product, service, or system being tested. For the second step, the team revises the design to integrate feedback received. Revision activities generally take the shape of tiny synthesis sessions.

Feedback & revision process map

This feedback and revision process is a basic framework for how to seek out and integrate feedback into a product or service you have designed. Before jumping into a feedback loop, the team needs to review the primary design phase principles, as well as the principles you developed during problem framing. After an intense iteration phase, in which the team gets deeply involved in details, refocus on the participants and the strategic goals of the project.

There are two parts to the feedback process: 

1. Finding out who to talk to
2. Making changes to your design based on their feedback

Strategies for feedback

Creating a feedback strategy allows the team to collect feedback logically and methodically. The team should test with people who are current or future participants in the thing that is being created, but those participants can and should be from different areas of the design object’s use. For example, if you test with a front-line participant at one stage of testing, you should balance that by testing with a leadership-level participant at another. Of course, it’s not always possible to perfectly construct feedback testing rounds; the purpose of this guidance is not to create an impossible goal of perfection for testing, but to offer guide rails on the best way the team can go about the testing process.

If testing narrows in on a single participant group for reasons of access or timeline, that’s okay, but it will result in a prototype that’s not as thoroughly tested, lowering the designed product, service, or system’s potential for success. While this is sometimes acceptable, it is not desirable. Work with your leadership to find a way to either extend your team’s timeline, or gain access to the participants you need.

Who to talk to: An expanding galaxy

In testing rounds, the design team needs to get feedback from people who have increasing amounts of distance from the project. This is for two reasons:

1. Starting with participants previously involved in or aware of the project allows the team to test low fidelity prototypes with people who have context on the project itself. This will provide actionable feedback to increase the refinement of that prototype quickly.
2. Moving outward to people who have no relationship to or awareness of the project includes the perspective of absolutely new participants. This allows the design team to learn about and correct for the issues new users will have without having to find out those issues during a pilot.

This group will also encounter a closer-to-launch-fidelity prototype, which prepares them for interacting with the new product, service, or system during the pilot phase.

All participants outlined below should be current or future users of the product, service, or system that the team is currently designing. The differences between these people are their closeness to the research and design process of the new product, system, or service.

Use feedback to make changes

Each time the team gathers feedback on the designed product, service, or system, they should document, meet, and discuss that feedback. Think of this process as a smaller, more concentrated version of the problem framing process the team underwent during the early parts of your discovery phase. In that process, as new information about the large problem frame was uncovered through desk research and the identification of constraints, the team narrowed in on the specific problem frame in which you were going to operate. Similarly, in this process, as the team tests with participants, you will make changes to your prototype to narrow in on a more useful and resonant product, service, or system for your participants.

You work with the resources you have, within the constraints of the product, service, or system you first designed based on your research, to better fit the needs of the ultimate participants in your work. This means tweaks, not systemic changes.

This image shows how the design changes as the team receives feedback on the proposed design. After each feedback round, the team makes changes to the design to reflect the needs expressed by the participants. Important to note: the changes should be to the details, not the core concept, of the design. If changes to the core concept of the design appear to be needed, the team should consult their discovery phase findings once again, and restart their design phase.

At this point, if you find the need for large scale, thematic or systemic changes, it means the design that you forwarded does not accurately reflect the opportunities identified in the discovery phase. The team will need to start again on the design process. This outcome is not failure; it simply means you know more about what your participants need. And, if you designed in quick iterations, you’ll easily be able to go back and change your direction without adding a great deal of cost or time to your project.

Below, find another visualization of making small changes based on feedback. As you can see, the tangram shape stays roughly the same shape through all the revisions. They all look vaguely like a person standing up in different poses. Those different poses are created by moving around some of the pieces that make up the puzzle. These changes are analogous to the changes the design team should be making in the feedback cycle: ones that change details to the overall design, but not the core idea of the design itself.

This image shows how, as the team makes changes to the design, the core thematic structure of the design should remain consistent and resonant with the participants’ core needs. At this stage, changes should be to details, not to overall design themes or needs.

Bringing it all together

Through the feedback cycle, the team will talk to a variety of people to gather feedback on the product, service, or system the team is designing. Those people will have different positions around, and awareness of, the project and its history. As you gather feedback from these people, the team will make changes to its design in response to that input.

If the feedback points the team to an entirely different design, that’s okay, but the team must throw out its design and start the design process again. In this case, the team might want to review the opportunities from their discovery phase and identify a new direction for their design.