Mike Mace provides us with some great insight about market research – helping us to avoid ‘the blender’ and ‘the gap’. The gap is a reflection of the inability of most customers to innovate. The blender is the loss of useful market information into a homogenized input that pushes only the lowest common denominator – again stifling innovation. We have to avoid the blender and the gap to get useful data from our research.
Use Case Driven Documentation
Yesterday we wrote about focusing our documentation on what our users are trying to accomplish. With a structured requirements approach, or with an interaction-design driven approach, we’ve already solved half the problem – determining what to document.
Writing Valuable Requirements
One of the ten big rules of writing a good MRD is writing valuable requirements. How do we determine what requirements are valuable? To whom are they valuable? When a requirement represents a continuum how much is enough? What is too fast, what is too scalable? To whom must the requirement be valuable?
Requirements Gathering – Interviewing the Right People
How do we find out what someone wants when they don’t know what they want or what they can have? One of the best techniques for gathering requirements is to interview users. But which users?
Imagine aliens came to the planet and offered to solve our gasoline problem. How could we tell them what we wanted? We might say we wanted cars that run on clean renewable energy. The aliens might leave thinking “Oh well, I guess they didn’t want faster-than-light travel.”
Gartner research on Agile Requirements Definition and Management (RDM)
Gartner has a research report available for $95, titled Agile Requirements Definition and Management Will Benefit Application Development (report #G00126310 Apr 2005). The report is 7 pages long and makes an interesting read. Gartner makes a set of predictions for 2009 about requirements definition and management (RDM) systems, and the software created with RDM tools. Gartner misattributes several benefits of good process to RDM tools. We give them a 3.5/7 for their analysis – check out the details here.
Persona Grata
Different people approach the same goal very differently. When we don’t truly identify our users, we end up with software that dehumanizes, waters-down, and otherwise fails to succeed at anything more than grudgingly tolerated functionality. Even worse, we may ignore the needs of our key demographic, resulting in software failure. When we use personas instead of generic use cases, we can avoid both the misery of a failed product and mediocrity of marginal success.
Office 2007 UX Victory
Microsoft Office 2007 has a completely new user interaction paradigm.
The old interfaces for Microsoft Office 2003 (and earlier) organized the menu structures around features or capabilities. Each grouping represented tasks that appeared to be related in functionality. This, unfortunately, doesn’t help the user very much. The new interface is very task based, and organizes capabilities based upon the task the user is currently performing. What the Office team has done is innovate. And the innovations differentiate them from every other business application I’ve ever seen.
Competent Users and Software Requirements
We were all student drivers at one point. But no one stays a beginner indefinitely. Almost no one becomes an expert driver either. Most of us are competent drivers. Driving skill probably even follows a bell curve distribution, with most drivers being OK, some “bad”, some “good”, and very few experts or beginners. We’ll show in this post how to apply this pattern to software requirements and design.
The same is true of our users
Interaction Design and Structured Requirements
subtitle: Wiegers and Cooper assimilated
Wiegers promotes structured requirements. Cooper touts Interaction Design. Both have great ideas. Both “wave their hands” at parts of the process. In this post, we’ll talk about how to combine the two philosophies to get the best of both worlds.