by Chris Durand, CTO
I recently had a discussion with a friend who owns a small business and needs a web application to run day-to-day operations. She’s a pretty savvy person but has a limited technology background. She came to us looking mostly for help in laying out the requirements, and how to hire a contract developer. But software can be a complicated business with thousands of little questions and details lurking around every corner, so we wanted to give her some advice to help her avoid the pitfalls. Here were the key takeaways.
Define the Scope
First, be clear about the scope and what you are trying to accomplish. For many projects, a phased approach is best, especially for smaller companies with more limited resources. Trying to do everything in a single release costs too much and takes too long, which drives up the risk. If you have finite time and resources (and most of us do), every addition to scope is a potential subtraction to quality control and keeping to your delivery schedule. You are better off determining what you absolutely need to get out the door in phase 1, letting it generate revenue while you plan for your next release. Be ruthless about cutting features. Often what you leave out is just as important as what you put in.
Once you have an idea of what you are building, you should make screen mockups to clarify which screens you need in your application and what is on them. You can include brief notes with the mockups to point out key details or functionality that is not obvious. You should have at least one mockup per screen in your application. Screens that have different modes or layouts may need multiple mockups to fully illustrate what is going on.
I like to start out sketching on paper; then once I have a rough idea of the layouts and content, I use a mockup tool to do more comprehensive mockups. My favorite tool for this is Balsamiq (http://www.balsamiq.com/). It’s cheap, easy to use, and gives great results. The key here is to focus on layout, content, and function, not colors, graphics, and making things look pretty.
User Stories or Workflows
Now that you know what screens you need, it’s time to write up workflows (sometimes called user stories) to explain how key features will work in the application. You know that hand-waving you’ve been doing about how customers will find a product, add it to their cart, and check out? Now is the time to get down to specifics: which page are users on at each step? Which button is the user clicking on each page? Simple workflows can be done in a bulleted list, while more complex workflows may require a flowchart or other diagram. This helps you understand how your screens work together, and the application as a whole.
Mockups and workflows fall into the general category of requirements, but here I’m talking about other details that are not easily captured in these earlier efforts. If you want your application to do something specific, you need to write it down. The more detail you can provide, the better you understand your application and the more likely you will get what you expect from your development team. Here you can list out details for each screen like how to handle errors, how many characters each text field should hold, and anything else that you can think of that is important.
Software applications contain thousands of details. What color should something be? What happens when a user clicks this button? How long should a product name be? (30 characters long? 100 characters long?) Developers have to make dozens of decisions about these kinds of things every day. If you don’t make these decisions up front, your developer will make them for you, and they may not always do what you want. Good developers know what details matter and require additional input from you without bothering you with trivial issues, but they are not psychic. The more you clearly understand your application and can convey it to the development team, the more likely you will get what you expect and have a successful development project. Good luck!