How to Make Sense of Any Mess by Abby Covert

Chapter 4: Choose a Direction | Page 100

Watch out for options and opinions.

When we talk about what something has to do, we sometimes answer with options of what it could do or opinions of what it should do.

A strong requirement describes the results you want without outlining how to get there.

A weak requirement might be written as: “A user is able to easily publish an article with one click of a button.” This simple sentence implies the interaction (one click), the interface (a button), and introduces an ambiguous measurement of quality (easily).

When we introduce implications and ambiguity into the process, we can unknowingly lock ourselves into decisions we don’t mean to make.

As an example, I once had a client ask for a “homepage made of buttons, not just text.” He had no idea that, to a web designer, a button is the way a user submits a form online. To my client, the word button meant he could change the content over time as his business changes.

Chapter 4: Choose a Direction | Page 104

Control your vocabulary.

Are you facing a mess like Rasheed’s? Do your stakeholders speak the same language? Do you collectively speak the same language as your users? What language might be troublesome in the context of what you are doing? What concepts need to be better understood or defined?

To control your vocabulary:

• Create a list of terms to explore.
• Define each term as simply as you can.
• Underline words within your definitions that need to be further defined, and define them.
• Document the history, alternatives, and myths associated with each term.
• Review your list of defined terms with some of your users. Refine the list based on their feedback.
• Create a list of requirements that join your nouns and verbs together.

Chapter 4: Choose a Direction | Page 99

Think about relationships between nouns and verbs.

When you combine nouns with appropriate verbs, the resulting sentences can be referred to as requirements for what you’re making.

From the previous example:

• An author can write a post.
• An author can delete a post.
• Any user can share a post.
• Any user can read a post.

This list of requirements defines the ideal solution. Each requirement tells us who should be able to do what in the eventual state.

When you take the time to make requirements concrete and prioritize them, you can better understand what you’re actually making.

If you’re designing an interface that prioritizes reading, it will be fundamentally different than an interface that prioritizes writing, even with the exact same list of requirements.