Design Decisions
4 mins
An inclusive, collaborative approach to managing design project knowledge.
Design projects generate lot of information
I have worked with many design teams who struggled through large-scale, systemic innovation projects. Things often start out just fine. The project team builds project knowledge through stakeholder conversations, design research, and brainstorming sessions. The accumulated knowledge comes into play at each decision-making juncture, guiding the project's direction. In the early phases, everyone can remember all the information generated during the project. It’s pretty easy to come to a shared point of view, make decisions, and move forward.
The more you learn, the harder it is to make decisions
Then it gets harder. The team is wading through knee-deep post-its or vast digital whiteboard environments. Not everyone on the team seems to be on the same page about what has been learned on the project. It’s often hard to share knowledge with others who weren’t there when it was captured or generated. Each team member develops a different mental model of what has been learned in the course of the project. Without a shared point of view, team decision-making becomes very difficult. Everyone comes to their own perfectly rational, but often conflicting point of view on what decision to take.
Decision making is when all the information generated through design thinking is put to use. Decisions on complex projects are difficult because it’s hard to use what you’ve learned to support decision making.
1) From day one of the project, the project team starts to develop project knowledge through conversations with stakeholders, design research and brainstorming.
2) At each decision making point, project knowledge is brought to bear to inform the direction of the project.
3) There is a point where it becomes very difficult for a team to leverage project knowledge to support decision making. The team is standing knee-deep in Post-it Notes and prototypes.
At this point it can be helpful to look for help from outside the team. It’s always great to have a fresh perspective, but it can be very hard to bring an outside guide up to speed quickly. Some team members might feel disenfranchised when it feels like an outsider is taking the decisions for the team. This method for navigating these tough project moments also lacks scalability – it would be better is all teams were more capable of taking on very large scale projects without the support of a relative few experienced mentors and guides.
After seeing this pattern play out many times in my career I became motivated to find a more effective way. I wanted to be able to apply design methods to increasingly complex projects involving multiple stakeholders, numerous customer touch points, and a wide array of issues. When I focused on facilitating design decision making rather than the information generating activities of design I felt I was on to something useful. The Decision Decisions framework is my synthesis of the structured and analytical approach to design I learned at The Institute of Design in Chicago and the more exploratory, and inventive approach I learned at IDEO.
The four types of design decisions:
Any design project consists of an essentially infinite number of decisions. I think it’s probably not possible to know all the decisions involved in even a simple project. What are all the goals? Constraints? Who should we talk to? What brainstorm topics should we use? Which of these ideas are any good? I see these as all decisions. While any design project will require myriad decisions, I have found that any decision can be categorized as one of four basic types. Here, I lean heavily on George Box’s aphorism “all models are wrong, some are useful”.
• Project Definition decisions set the goals and scope of a project.
• Research Planning decisions define where the team will look for the inspiration that leads to innovation.
• Design Analysis decisions make sense of what the project team has learned.
• Concept Development decisions help the team prioritize concepts for further development, from prototypes to implementation.
But, it's a non-linear process.
While each decision provides a platform for the next, project information is not generated in a linear manner. This makes it harder to keep track of what the team knows. At any given moment the team may learn something that could require re-framing the project. Similarly, from the very first moments of the project team members will have instincts about potential solutions. The non-linear nature of information generation and decision making means that the team must be open to revisiting decisions throughout the project as new information arises.
As a design leader I feel my primary role is to help a team navigate the design decision making process. What decisions need to be made? What information do we need to support those decisions? What have we learned that means we need to revisit previous decisions?
As the values, beliefs and behaviors of designers find traction in the boardrooms of the worlds largest corporations there is an opportunity to leverage design to tackle ever larger problems. Enabling better design decision making is key to taking on these larger problems and making larger impact on the world through design. I hope this framework is useful in your design decision making and helps you take on bigger problems with greater confidence as it has been for me.
Try the Pragmattic worksheets: four types of worksheets to support each type of design decision.
I designed the Pragmattic Worksheets to help project teams create a shared mental model of project knowledge. This framework provides a structure for organizing what design project teams learn and keeping the knowledge accessible for when it is needed to support decision-making. No single topic defines a whole project
You can download the worksheets below using this link.
Each type of decision that the worksheets help frame up can be very complex. The Worksheets are intended to be used in multiples for each decision to handle this complexity. For instance, a project definition will need several Worksheets (perhaps 10-20) to capture the richness of the conversation around the goals of the program, the activities and schedule of the program and the expected deliverables.
PS: This article originally appeared on Matthew Beebe's blog, Be Pragmattic
Let's chat.
Create an account
Apply to join
Join the network
Open positions
