 |
|
Home > Product Management > Building a Quick App
Here are some things I observed, many of which are useful not just for quick apps, but for any new product development:
Get a user experience designer from the beginning. Especially with Facebook apps, UI = product = functionality = branding = marketing. You need to have really deep conversations about the user experience all the time.
Assign a project manager to coordinate tasks, set up meetings, send out notes, etc. This can be anyone on the team who is detail-oriented; you probably don't need a full-time dedicated person for your quick app.
It's disruptive for someone who is not on the team actively designing the app to "dive bomb" in unexpectedly with ideas or strong suggestions that must be implemented. That derails the process and demotivates the team designing the app. It's fair for everyone to share ideas, but if you want that kind of veto power you have to be committed to the launch team every day.
Find other apps or models that are even vaguely similar to yours - e.g. Craigslist, Groupons, Foursquare, whatever it is. Take some time to study how they do basic things like account sign-up, form validation, email, incentives, etc. Don't copy them, but note what you like (or don't like) about what they do, try to infuse this thinking into your app.
Don't worry too much about sexy features; focus on user needs and user experience.
After vetting the idea yourself, spend time with potential users. Once the concept is solid, make some mockups on paper, shop them around to real people, starting with friends and family, then extend to everyone you meet who can spare 5 minutes. You can do these kinds of tests on anyone. If you're feeling bold, maybe go to a coffee shop and grab some random people. You probably won't have more than a day or two to spend on this, but it's worth vetting before you build.
Although it's relatively cheap to build a quick app, it's always cheaper to edit mockups than edit code.
Get the language and terminology right. Write the basic app description and iterate on it for a few days. This will guide everything else you write, from instructional copy to help copy.
Build the user flows before you get tied up too much in the design. Think about which flows you're going to launch with on Day 1. Enumerate the flows so you know what's in Day 1 and what's later. Prioritize the flows in case you have to discard one or more for Day 1. With our quick app, for example, we had 6 well-understood flows.
Understanding what are the key flows helps you test your product - in fact, the flows are basically the test cases. Enumerated flows also helps keep the team focused.
As soon as something minimal is ready to test, file bugs in your bugbase. If you don't have a dedicated QA person, at least assign someone to triage the bugs every day and come to the daily meetings with a list of the top 5-10 bugs.
Set up a "war room" where you have the tasks for each team member listed out every day on a white board.
Create a "Day 1" app - what you go live with. For anything you didn't finish on Day 1, you may wish to build out a mini roadmap for the first 30-60 days. You can call each release by the day or week it goes live so you get on a regular release schedule.
Set up regular meetings at least twice per day - check in once in the morning and once at night. Go through that day's tasks. If something didn't get completed that day, do it ASAP or move it to the next day.
Building a Quick App
I was recently involved in a project to launch a Facebook app quickly, in under 2 weeks from concept to bug-free (or as bug-free as any launch product ever is!). I call these types of apps quick apps. Quick apps can be used to prototype something or just get something out there as a beachhead product that you'll add onto later.Here are some things I observed, many of which are useful not just for quick apps, but for any new product development:
Managing the Ideation Team
Everyone designing the app should get on the same page right from the beginning. This is where it helps to be working with someone you know well and/or who has the same assumptions as you. On the first day of your project, write down your assumptions or the basic premise of the app so everyone is clear.Get a user experience designer from the beginning. Especially with Facebook apps, UI = product = functionality = branding = marketing. You need to have really deep conversations about the user experience all the time.
Assign a project manager to coordinate tasks, set up meetings, send out notes, etc. This can be anyone on the team who is detail-oriented; you probably don't need a full-time dedicated person for your quick app.
It's disruptive for someone who is not on the team actively designing the app to "dive bomb" in unexpectedly with ideas or strong suggestions that must be implemented. That derails the process and demotivates the team designing the app. It's fair for everyone to share ideas, but if you want that kind of veto power you have to be committed to the launch team every day.
Find other apps or models that are even vaguely similar to yours - e.g. Craigslist, Groupons, Foursquare, whatever it is. Take some time to study how they do basic things like account sign-up, form validation, email, incentives, etc. Don't copy them, but note what you like (or don't like) about what they do, try to infuse this thinking into your app.
Turning an Idea into Something Real
Spend as much time thinking how you personally would use the app. Build really good use cases involving yourself or someone you know well. Personas help here.Don't worry too much about sexy features; focus on user needs and user experience.
After vetting the idea yourself, spend time with potential users. Once the concept is solid, make some mockups on paper, shop them around to real people, starting with friends and family, then extend to everyone you meet who can spare 5 minutes. You can do these kinds of tests on anyone. If you're feeling bold, maybe go to a coffee shop and grab some random people. You probably won't have more than a day or two to spend on this, but it's worth vetting before you build.
Although it's relatively cheap to build a quick app, it's always cheaper to edit mockups than edit code.
Get the language and terminology right. Write the basic app description and iterate on it for a few days. This will guide everything else you write, from instructional copy to help copy.
Working Through Flows
Break the app into specific flows - focus on the Day 1 flows you will launch with, and keep a list of future flows elsewhere. Be really diligent about launching with the Minimum Viable Product (MVP). Don't be afraid to discard flows if they're not core to the MVP.Build the user flows before you get tied up too much in the design. Think about which flows you're going to launch with on Day 1. Enumerate the flows so you know what's in Day 1 and what's later. Prioritize the flows in case you have to discard one or more for Day 1. With our quick app, for example, we had 6 well-understood flows.
Understanding what are the key flows helps you test your product - in fact, the flows are basically the test cases. Enumerated flows also helps keep the team focused.
As soon as something minimal is ready to test, file bugs in your bugbase. If you don't have a dedicated QA person, at least assign someone to triage the bugs every day and come to the daily meetings with a list of the top 5-10 bugs.
Moving Towards Production
Set milestones for launching. Set a target date and work backwards from there. Make a list of what you need to get done every day between now and launch.Set up a "war room" where you have the tasks for each team member listed out every day on a white board.
Create a "Day 1" app - what you go live with. For anything you didn't finish on Day 1, you may wish to build out a mini roadmap for the first 30-60 days. You can call each release by the day or week it goes live so you get on a regular release schedule.
Set up regular meetings at least twice per day - check in once in the morning and once at night. Go through that day's tasks. If something didn't get completed that day, do it ASAP or move it to the next day.
