Stop me if this sounds like you
You’re at the start of a new project, it feels great. You have a blank slate upon which to build, what could be, a truly great product. You start by writing a document detailing the features, maybe you sketch out some of the screens, but pretty soon you get bored and dive straight into the code. What started out as a well thought out project becomes heaps of discarded and re-written code as you bash the product into shape. Maybe it turns out great. Maybe it doesn’t. But did you feel in control?
Project Management 101
The situation I outlined above is one I’ve been in before and find myself on the verge of entering again. I’m at the start of my Coffee App project and this time I’m determined to do things “right”. I’m going to resist the urge to jump into the code and instead invest some time in planning.
Just to catch you up; So far I’ve produced the beginnings of some wireframes and workflow, and I’ve been playing around with some placeholder art this week. None of this is complete, its all just partially started and kind of going nowhere.
Lets metaphorically scrap all of that and start again, properly.
So what is the right way to do this? For me, I’d like to define an appropriate process for this project. I don’t need someone else’s idea of how it should be managed, I need something effective for me to drive a quality product. It seems to me, the simplest way to do this is to break it down into a series of steps. I should point out that I’m not trying to dictate how you should go about this, I’m just sharing the process I’m going to use for this particular App. You can follow along and see whether or not it’s successful.
- The Idea
- The Document
- Wireframes & Workflow
- Design the screens
- Code
- Final Art
- Public Testing
- Marketing and Launch
- Go to the Winchester and have a nice cold pint
We’re going nowhere without this. This may take all sorts of forms – A paragraph of text, some scribbles on a napkin, a thought in your head, etc. For my Coffee App its a sketch. A sketch that I made whilst in an actual Coffee shop waiting for some friends (I always carry a plain Moleskine with me).
We need some kind of document. Something to explain the purpose of the application. I guess it should also contain some detailed information about the actions you can perform from within the App. Its a spec to develop to. Something we shouldn’t be afraid to deviate from but that represents the core of the experience.
It seems to be a good idea to wireframe the screens that I’m going to build. The wireframe does not dictate the look and feel of the screen, purely its structure and functionality. This is a great complement to the documentation and I envisage using the wireframes to build from with the documentation as backup. I’ve stuffed workflow in here too since its kind of related. I need to know how the screens interact with one another so that I know when to present the user with a new screen. The workflow will also give me a chance to iron out any potential high level issues with using the App.
I think its useful to design at least some of the screens. I find that this helps to get things straight in my mind and gives a rough idea of the visual style I’m trying to achieve. With this App particularly, the visual style is part of its attraction and USP. This also gives me some placeholder art for when I start development.
The really fun part. The actual code. I envisage this being an iterative process during which time I’ll be dipping back into the wireframes and design document to make modifications. Whilst I’ll be sticking to my design as much as possible, I’d like the freedom to investigate a bit.
Again, this will be an iterative process. I’ll need to spend significant time polishing the artwork and implementing screens that weren’t covered in the first pass. At this point the functionality should all be there and this is ensuring that the art is up to scratch to match the user experience.
I’m going to do some proper testing this time. This will also be iterative since feedback from this stage will require revisiting both the code and Art. Obviously I’ll be testing the App throughout the whole process but this is specifically for testing with a wider audience.
I’ll need to build some buzz and get some marketing support in place – screens, press releases, website branding etc.
With the App released and the feedback phenomenal, I can sit back and take it easy.
The Idea
I have my Idea already.
An App for recording your Coffee tasting experiences and sharing them with others.
Its a Coffee App for Coffee lovers. The sketch below is representative of my Idea and is the seed from which the project will grow.
I think that is all that’s required for this first step. The idea will be fleshed out in the documentation phase when I start to think about all of the features that I want in the App.
Next Week
Next week I’ll share the second step with you, the document. The aim is for the document to contain enough information to build the wireframes and workflow as well as acting as a reference point for the project. Until 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 (You are here)
Part 2 – The Design Document
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
(blackboard image courtesy of rainerebert)