The Process of Designing an App
(Originally written on June 8, 2013)
Having been a mobile developer for six years (or over twelve if you count the Palm Pilot VII), I’ve been around the block a few times when it comes to development.
Oftentimes, projects don’t allow the time or the budget to do all of the following steps, but some of the more ambitious ones that I’ve been involved in have had these as deliverables. (I will detail examples of some of these in future posts)
The Concept
This is the initial concept — be it an elevator pitch, a sketch on a napkin, or a mish-mashed sentence of unrelated sites (“it’s like Twitter…crossed with Angry Birds…but for dogs!”)
The 3 C’s
I think everyone has a different definition of 3 c’s, but when it comes to apps (or originally for web sites), we’ve referred to it as “content, community, and call-to-action”. (For web sites, it used to be commerce instead of call-to-action, but I’ve modified that to suit the times — i.e. freemium models, ad-sponsorships, etc.)
This is usually a blank piece of paper with three columns: the first being content (the thing that makes someone initially download an app), the second being community (the thing that makes them come back a second time or more), and the third is the call-to-action (or, the way the app makes money).
Strategy/SWOT Analysis
I have only worked on a handful of projects that have had a full strategy written before the kick-off, but the best ones that I have seen have had a good competitive analysis (competitive companies as well as competitive products) and a SWOT (or Strength-Weaknesses-Opportunities-Threats analysis).
The SWOT Analysis would divide up a piece of paper into four quadrants. In the strengths quadrant, we’d list all of the reasons why our app was stronger or more stable than the competition. In the weaknesses, we’d write reasons where our app’s features were lacking. In opportunities, we’d try to identify any areas that were left unaddressed by all of the apps, and in threats, we’d list any barriers such as technology shifts, a new competitor (with more money), internet rumors related to the category, etc.
User Profiles
A user profile is a story of a particular imaginary user. We would try to get as detailed as possible into the user’s character to really have a good idea fleshed out in our mind of how the person would interact with our app. More details were always better. Instead of saying “caucasian male, 18–29 years old”, we would say something like “Peter Czejuk, third generation with Polish ancestry, 27 years old, slightly overweight, single with a steady girlfriend, likes to watch the Sci Fi Channel and has a boxer-mix named Sophie”. That simple description can give us a number of insights into the life and preferences of that person.
Usage Scenarios
This is where we’d take the user profile and really flesh out how this app would be used. Something like “Mary, single mother of two (Charlie, age 9, and Frank, age 12), isn’t able to pick up her kids from work — so she logs onto the Springfield Mall app, and reserves two tickets in their names for the 4:30pm showing of The Avengers. Then, she clicks on the “share” button to text Frank with the details, along with a message telling him to take care of his brother, and that she will pick them up at 6:30pm outside.”
Process Flow
And now we get into the meat of the application. This is a flowchart listing the different screens/functions that are needed, and how users will navigate to them.
Wireframe
After the process is mapped out (and tested), we would start to work on wireframes for each of the major screens. This way, we’d make sure that we don’t forget any required functionality for different screens, as well as let us perform basic usability tests to make sure tasks are intuitive for our target users.
Comps
The graphic designers will take the wireframes and then do their magic. A lot of the time, designers will design sample screens which (after a few tweaks) will be immediately executed. However, I did like one design process that we used that started with sketches (hand drawn, usually), then was executed in grayscale, and then finally in color. The reasoning for this process was to make sure the layout was accepted by the client (with sketches), then the artwork/typography was finalized, and then finally the color styles. The goal of this was to keep the number of revisions down and make sure that the design process didn’t drag on with tweaks to color, then layout, then color again, etc.
And now, into development…
After those phases (many of which would be concurrent, and some of which would be skipped) we would have most of the information needed for development.
If there was a back-end that was required, I would usually create one more document: a web services technical spec. This would detail all of the different web services that were required, and the inputs and outputs that would happen when these were called.
Then the graphics would be spliced (cut up as needed, although I would usually go back through and optimize them) and we would being programming the interfaces and hooking up the web services.
