Process: Discovery

Discovery can be a lot like cramming for a test—the goal is to ask questions, find answers, and absorb as much information in as little time as possible.

There are many different discovery techniques, from simply thinking critically about the problem for a few hours to conducting elaborate user and field research. No matter how in-depth the discovery process I create multiple user scenarios to help filter and put discovery results into context. I’m especially interested in user scenarios of people who will never use the finished product. If a feature appeals solely to a non-user it shouldn’t go into the design.

Making sense of the information uncovered during discovery is often difficult. I frequently use IA techniques and matrices to identify patterns and opportunities in complex data. For example, during the development of Palm’s first handheld with a thumb keyboard I identified all possible keyboard combinations and plotted them against every software command in Palm’s core application set. This resulted in a matrix of over 3,000 possible keyboard/software interactions. During design this matrix made it easy to find unassigned combinations and make recommendations for new, more intuitive combinations.

I once wanted to identify opportunities for cross-application information exchange between Palm applications. For example, it would be useful if To: and From: fields in an email application could directly exchange information with the Email: field in the Contacts application.

I used matrices to conduct the analysis. One page of the resulting 24 page document is shown above and in detail below. The x-axis of each matrix shows all Palm applications and their fields. The y-axis is the user's current application and its fields. Dots indicate useful opportunities for data exchange. Numbers refer to a key with more information. In the end I was able to identify 12 distinct types of data exchange out of 4,300 possible combinations.