Last week I discussed my plan for producing my Coffee App and gave a brief overview of the idea. This week, it’s time for the next step in my master plan – the design document.
What’s the point of the design document?
Documentation, like project management, is not sexy – at least not to any developers I know (past making sarcastic comments in the code itself). It does however have a valuable role to play.
The design document should aim to clear up potential design issues before development begins. It presents the features that will exist in the App and explains there significance to the experience. For my Coffee App, I want the document to be comprehensive without dictating the technical details of the implementation. I may well deviate from it and add new ideas, during both the graphic design and development, but it gives me an anchor point. Something that I can refer back to during development when I feel that the App is deviating from the original idea.
The other thing the design document forces you to do is think through the details. When I was writing this document I hit a number of stumbling blocks that forced me to rethink certain aspects. I’ve narrowed the focus of the App to concentrate on what is important – the inputting of tasting notes.
What goes into the document?
I say, go with what your heart tells you. I’m sure there are loads of examples out there on the internet but, as a solo developer, what you’re trying to create is something that you will find useful. I don’t think there’s a need to add content just because you feel you should. I’ve split my document into sections, here’s a little bit about them.
In a few words
Literally a single sentence that captures what the App does. The elevator pitch, if you were only going up a single floor. This is the sentence that I want to be going through my head throughout the various stages of the creation of this application.
Audience
Its all about the users! You need to know who is going to use your App. Hopefully the profile of this person can pretty much come from yourself if you’re building an App you’d use (and I hope you are). This is just a few paragraphs to act as a useful reminder as to who your App is for. In this instance I actually have two subtly different audiences in mind. I think this is fine since they still center around a common theme (but there is some potential for design conflict that I’ll have to keep an eye out for). The wireframes should help me resolve some of this.
The Experience
A few paragraphs on what its like to use the App. This is essentially a slightly more detailed overview of the App to highlight the “feeling” of the core features. I’ve used it as a chance to express the compelling aspects of the App and to remind myself of the overall experience I’m trying to achieve.
How it will be used
It seems vitally important to consider when and where a user will be interacting with your App. I’ve created this section of the document to detail a few scenarios when I think the App will be used. They’re all slightly different and focus on individual features of the App. This is going to be useful to refer to and literally act out the usage of the App.
The App needs to be tailored in such a way that it complements these experiences and makes allowances for the environment in which they take place. For example, for areas of the App where the user will be using features at home, I can afford to present a more visual, absorbing experience. However, for features that are used when the user is out and about, the experience needs to be quick and easy.
Features
For this section of the document I’ve listed all of the core features of the App. I’ve detailed their functionality and added some suggestions as to how they might work. Many of the uncertainties here will be ironed out in the wireframes and workflow. Anything remaining after that will ultimately be decided during development and user feedback. I’ll be referring to this section regularly during development to complement the wireframes that I’ll be building from.
The real thing
Its not fair to have you read all of that and not show you the real thing. So, with the theory out of the way, here’s the actual design document ive created for my Coffee App.
Coffee App
Design Document
Author: Christopher Waite
Date: 12th February 2011
In a few words
An App for recording your Coffee tasting experiences and sharing them with others.
Audience
The intended audience for this App is someone who loves Coffee and wants to record their tasting experiences for the Coffees they try.
A secondary potential audience is the casual Coffee drinker looking to learn more about appreciating Coffee. Where possible the App should guide the user in adding appropriate tasting notes.
The Experience
The primary experience is around easily recording your tasting experiences. This needs to be visually appealing and extremely intuitive (almost addictive). You’re adding buzzwords that represent your experience whilst you’re tasting the Coffee, therefore interaction needs to be a breeze. Any barrier here will ruin the App experience and prevent uses from returning.
The Coffee Cupboard is the users point of entry and needs to be visually strong. It has to feel personal to the user and provide an experience unique to this App.
The “cellar” of Coffees you’ve tasted and the search feature are where a lot of the power lies. This part of the App is nearly needs to be responsive first and foremost.
How it will be used
Example 1: A user walks into the kitchen and makes a Coffee. When they come back to their seat, they take out their iPhone and tap on the App. They tap the Coffee they are tasting (if its already in their cupboard) or add a new Coffee if they’re tasting for the first time. As they sip their Coffee they enter words that are relevant to how the Coffee tastes.
Example 2: A user wants to tell a friend about a Coffee they are tasting. The user opens the App, navigates to the Coffee and “shares” it with the friend. The friend receives an email (other sharing options may be available) with details of the Coffee and tasting notes along with a link to import it into their own “cupboard”.
Example 3: A user is in the shops, or surfing online, and wants to buy some Coffee. They take out their iPhone, open the App, and search “My Coffees” for coffees that they liked, rated highly, and had specific flavours. Upon finding a Coffee they can continue their purchasing knowing they’re getting something they will enjoy.
Features
1) Coffee Cupboard
A hub that collects the Coffees you are currently drinking. These may be Coffees in your cupboard (Beans or Grounds), Coffees in a Cafe, or one-off tastes.
The Coffee Cupboard is like a live stream of you Coffee tasting activity. It may also be the collection point for your shared Coffees.
This hub should be customisable to allow the user to make it their own.
2) My Coffees
This is the guts of the Coffee App. All of the Coffees the user has ever tasted are stored here. Coffees that the user has finished with (Archived) will be moved from the Coffee Cupboard to this section.
This needs to be presented in a manor that is easy to navigate. Flipping through past Coffees should be an easy and pleasant experience.
Search
The search lets the user easily find previous Coffees that they have tasted. Important search criteria will be Coffee name, rating, and important words from the tasting notes.
4) Sharing
Sharing coffees is part of the core experience. This should be easy and provide various sharing options such as twitter, email, facebook, etc.
Viewing shared coffees should not rely upon the App but owners of the App should be able to fully import the coffee.
5) Viewing Coffees
Viewing coffees should be pleasant and visual. Tasting notes should be easy to see and understand at a glance. The user should also have the ability to mark a Coffee as a “Favourite”.
6) Adding Coffees
Adding a coffee should be fast with minimal required fields. However, there should also be the ability to add comprehensive information if the user wants to.
Coffee name, country, region, farm, place purchased, rating, tasting notes, preparation notes, an icon to represent the coffee on the cupboard page. Maybe the ability to add a photo.
7) Recording tasting notes
Recording tasting notes should be incredibly easy and lots of fun. Primarily text based, simple entry of single words (big, bold, fruity etc). Perhaps a grid of commonly used descriptive words will aid in speedy and enjoyable entry. Maybe I could allow voice notes too and even pictures.
This experience should also potentially be guided to help the user in appreciating flavours and recoding appropriate words.
To complement the tasting notes is the ability to rate a coffee – a simple 5 star scale.
9) Preparation Notes
The ability to add preparation notes would be a really nice addition. This could just be a simple text notes field – with the ability to add multiple sets of prep notes along with rating them. This will help the user to identify preparations that worked to get the best from the particular coffee.
Next Week
Next week, wireframes and workflow. These will complement the design document and will act as the blueprint for the creation of the graphics and development of the App. Next weeks post will also be much more visual. See you then.
This post is part of a series that will follow the design, development, and release of my Coffee App. You can view the other posts here…
Part 1 – Doing it properly
Part 2 – The Design Document (You are here)
Part 3 – The Wireframes
Part 4 – The Artwork
Part 5a -The Code (Xcode, GIT, and Core Data)
Part 5b – The Code (Coffee sharing and Camera functionality)
Part 5c – The Code (A change in workflow)
Part 6 – The testing
Part 7 – The Final Artwork
Part 8 – The Marketing
Part 9 – The Launch
Part 10 – The Numbers
Part 11 – The Postmortem
(Bonus) Part 12 – A review of the process
(thumbnail image courtesy of kjfnjy)