Principle One: Getting to simple is hard

Budget Time, People, and Patience.

“How long will this take?” has to be one of the most terrifying questions any designer will be asked when embarking on the design phase. The simple answer: one can’t know — but rational time constraints can be useful. What we do know, from years of experience and many, many design case studies, is that getting to a simple, easy-to-understand, and useful solution to any design problem is the result of many rounds of iteration, problem-solving, and testing. Leadership and clients should not expect a design solution to be completely finished in a month, especially if the team is working on multiple projects either together or apart, but defining the term of the design phase rationally can help the phase move along.

Making Decisions

A successful design phase requires the team to make a lot of decisions. Some of these include: what to design, how to make a model or prototype of it, who to test with, how to test it, how to get on those peoples' calendars, how long to wait before finding other people to test with, how to integrate their feedback, and how to move through iterations on that feedback.

This process can be anxiety-inducing, as it means the design won’t meet all the needs of all the participants. This decision-making is, however, necessary. What a design team is trying to do is to make a precisely useful solution for a precise problem, not to make a large, unwieldly solution that tries (and fails) to solve all the problems encountered by the participants.

Case In Point

The Semester Model as a Rational Time Constraint

We will go further into the details of scheduling a design phase in the Design Phase Operations Guide, but for now, one useful rule of thumb is based on a very familiar time unit, the academic semester. The Semester Model can also be compared to "Epics" in the Agile process*. These timelines generally consists of twelve to fifteen weeks of continuous work. Graduate thesis-level design projects typically an entire semester with students primarily working on their own or with a tight team and focusing on nothing else. If your team meets the criteria of tightly working together and narrowly focusing on the immediate task of product, service, or system development, then a semester (12 - 15 weeks) might be a good timeline for producing design work that has been developed through an iterative process and tested with either one or two rounds of participants, depending on how easy it is to schedule time with them. At 12 weeks, you can reasonably be able to offer your leadership and stakeholders a (hopefully brief) report on your design phase, including iterations and testing, and plan to move into secondary testing and piloting. More on this process in the Feedback section.

*A quick review of Agile and Epic: Agile is a process for digital product development and is appropriate for developing not-quite-as-blue-sky products as this Guide series encompasses. Agile and similar methodologies are often used in the creation and evolution of digital products with a development/engineering team. Find out more about the Agile process from Agile: The Way to Develop Great Software. For a slightly more in-depth look on how HCD and Agile can complement each other (much like HCD and Lean), please see Why human-centered design is a natural companion to Agile development.