I recently acquired a design tool – a set of IDEO method cards, where each card presents a design approach or a method of gaining inspiration. IDEO's design philosophy is to keep people at the center of the design process, and the four categories they divide the cards into reflect this:
- Ask people to help.
- Look at what people do.
- Learn from the facts you gather.
- Try it yourself.
IDEO designs an incredibly wide variety of products – corporate websites, hand-held electronics, clothing, business services, furniture, and more. With such diversity, it is no surprise that not all of the cards appear applicable to software development. I found that going through the cards and thinking about how they relate to I.T. to be interesting. I ended up classifying the relevant cards into three groups:
- Requirements: These cards provide ideas on how to gather or analyze requirements. This was the largest group by far – over one third of the total number of cards, and they spanned the four categories above. If you work in I.T., it may seem that calling tips for requirements design approaches is inappropriate. In software development there is often a divide between requirements and design. You do need to understand the client's needs and determine a solution that meets those needs, but an explicit separation in role between these activities can often hurt the final product. IDEO takes a holistic approach: determining requirements and understand the user is part of the design process and not a precursor to it.
- User Interface Design: About one-sixth of the cards presented ideas related to user interface design. These mostly fell into the Try category, with a few in Learn and Ask. Prototyping and testing of various sorts were reoccurring themes in over half of these cards.
- Software Design: Only a few cards seemed relevant to application architecture and software design. I initially found this surprising since I was expecting more. After further reflection, I realized that the commonly held understanding of design in the context of software development is very technical and narrowly focused. This 'technical' design activity (for lack of a better term) is necessary but not sufficient for creating a great piece of software. Other activities within the course of a development project that we in I.T. do not call design – activities such as requirements gathering, analysis, and usability testing – are all part of IDEO's holistic view of design.
In order to provide a concrete example of what the cards are like, I list in the table below a few of the cards I found particularly interesting. Each card explains not only a design method (the how), but also the reason for using it (the why). (Each card also briefly describes an IDEO project that used this method, but I do not list that below.)
| Title | How | Why |
|---|---|---|
| Five Whys? | Ask "Why?" questions in response to five consecutive answers. | This exercise forces people to examine and express the underlying reasons for their behaviors and attitudes. |
| Rapid Ethnography | Spend as much time as you can with people relevant to the design topic. Establish their trust in order to visit and/or participate in their natural habitat and witness specific activities. | This is a good way to achieve a deep firsthand understanding of habits, rituals, natural language, and meanings around relevant activities and artifacts. |
| Error Analysis | List all the things that can go wrong when using a product and determine the various possible causes. | This is a good way to understand how design features mitigate or contribute to inevitable human errors and other failures. |
Looking at these design methods and the many others listed in the set of IDEO cards makes me appreciate all that goes into a well-designed product, and inspires me to think more carefully about how I think about and approach design.
If you find this article helpful, please make a donation.
