Design Principles

Requirements

Requirements and design are essentially a learning activity. Users or subject matter experts have to learn how to describe tacit knowledge in their work, and their goals when using the software in a way that technical people can understand. Analysts learn about the problem space, the end users, what they need the software for, and how to express those concepts concretely. Programmers also learn about the problem space, the domain, and how to implement these ideas into design and code. Therefore, requirements are best expressed in different modes to appeal to different learning styles. Only expressing requirements in documents, use cases, story cards, etc. etc. is incredibly limiting. Instead, try to appeal to different learning styles so that the concepts will be expressed more richly, and to increase the chances of comprehension, and to reduce vagueness in requirements.

Learning Styles

Different people learn differently, and express ideas differently. Since requirements elicitation and expression is so important to software development projects, I have never understood why we try to narrow this down and oversimplify it. We try to look at the human first, and then use the tools to augment their learning and communication styles. Usually in software, we force people to express their ideas in requirement templates, or in some software tool, or using some sort of acceptance test framework. This ignores aspects of how people learn, synthesize and express knowledge.

When expressing requirements, we try to use tools to appeal to these different learning styles. While most people are dominant in one mode, we all have a mix. Retaining knowledge and expressing it is best when each of these modes are used.

Visual Learning

Some visual learners like to read and retain a lot of information by reading a book or document.

Some visual  learners prefer to look at pictures and diagrams than read.

Visual learners can vary, but most people tend to have a mix of words and diagrams. Therefore, written documentation should be brief, with good visual organization and visual aids.

Auditory Learning

Auditory learners learn by hearing. They can listen to a lecture and pick up more than they might by reading a book. Musicians tend to be very strong auditory learners because they try to mimic sounds or pieces of music they hear, also known as "playing by ear."

Even people who aren't auditory dominant benefit from listening to something being expressed, particularly if they can ask questions to clarify anything that is vague or doesn't make sense. Reading requirements documents aloud is a good exercise to spot vague language, or awkward designs. If you can't express your ideas smoothly in written or verbal form, how can they be expressed clearly in code?

Tactile Learning

Tactile learners learn by interacting and touching something. They need to try things out, and get their sense of touch involved. On software projects, this means that they react well to prototypes and working software. They like to interact with paper prototypes, and physically walk through software workflows. They would much rather interact with the real software than read a document, look at a picture, or listen to someone talk.

Combining Learning Styles

You don't know what your team's learning styles are, and many of your team members may not have thought of it. That doesn't matter though, because no matter what their learning styles, people respond the best to a combination of techniques that appeal to their modes of learning.

Therefore, use them all when expressing requirements:

• written prose in a document
• diagrams, pictures
• have verbal explanations of requirements and ideas
• conduct walkthroughs with prototypes or early releases of new software
• prototype new features or redesign in the application using patches
• conduct usability studies with real users
• release frequently to the user community and incorporate their feedback from forums, bug reports

Retention figures (unsubstantiated)

We retain:

• 20% of what we read
• 30% of what we hear
• 40% of what we see
• 50% of what we say
• 60% of what we do
• 90% of what we read, hear, see, say do

Learning by Teaching

To gauge whether others on the team understand the requirements and design, have them teach others on the team. Trying to explain or teach others a topic is a wonderful way to master the topic. Any holes in your thinking, or assumptions, vague understanding will quickly come to the fore.

 Prototypes

Prototyping is a nice rich expression of requirements. It doesn't replace some of the work we need to do with regards to writing down the product vision, charter and some of the requirements, such as user goals, etc. It doesn't replace diagrams that also express those ideals, and it doesn't replace the auditory aspect of learning and expression either. However, all of the above can be incorporated into prototyping.

For session tester, we favor prototypes. Early in the design phase, these are paper prototypes that can be interacted with and refined. From there, we prototype in the UI builder. The next step is to wire up the code to the prototype. Once we have working software, we create prototypes by creating patches to the actual software, check it in, build it and demo to the product manager and the development team. Once we are happy, we start releasing to the community to get their feedback.

Release Early, Release Often

There is a reason open source projects favor this model. We can work on requirements and try to nail everything down up front, but nothing tells us whether we are on track or not quite like user feedback.

User Experience

We value software that is easy-to-use over theory and definitions. As a result, we want to get the software in front of users, within their own working environments, doing real tasks trying to reach their goals in their own work, and get feedback from them on the strengths and weaknesses of the tool.