There’s so much excitement and exuberance that goes along with producing a new App or Website. This honeymoon phase of development can mask weaknesses that will threaten not only the development process, but the overall viability of your product. Directing your energy into planning up front will both mitigate downstream ambiguity and focus the products value. There are so many formalized, official styles of requirements that look good, provide cover for staff and produce tons of paper…none of which meets the goal of designing the product. This article illustrates an easy pattern to follow to produce concise product requirements.
All requirements boil down to 2 questions:
- What will people do?
- What will people see?
When people interact with your product, what will they do? That is to say, what input will they provide? Mouse clicks, keyboard keys, touches, swipes, it’s all input. Documenting what you want people to do will help you map out how your app will look and behave, without writing a line of code.
After people do something, they will usually see something. This is the output of the program. Screens, sounds, vibrations, and various views are some of the output types we’ve been groomed to expect as part of the App experience.Deciding what you want people to see after they do something will make a story that can be read by anyone, not just programmers.
An example of a real life implementation of the requirements might look like this:
|#||Feature/View||What do users see?||What do users do?|
|1.0||Sign In View||Users see a username text inputfield, a password text input field and a button.||Users will input a username, password and push the button.|
|1.1||Sign In View button push||Users see a “loading” message.||Users wait for authentication to succeed or fail.|
|1.2||Sign In Success||Users see navigation and app statistics views.||Users use navigation view choices to proceed with app functions.|