Idea to Product: Part 1
So you’ve thought of an amazing idea now what? In this post we will cover everything you need to consider before spending any money on a designer and developer. We’ll discuss whether your idea is best suited for a native app or web app, the importance of identifying users and their needs, and methods for sketching user flows to figure out how your users will interact with your app.
App or Website?
From now on I’ll refer to an iOS app (written in Objective C) or an Android app (written in Java) as native apps. Anything that’s created with web technologies and meant for display in a browser will be referred to as a web app. There’s also the in-between gray area of hybrid apps, so if you’re really interested, contact me and I’d love to geek out about them. If you’re deciding between a web app or a native app, you need to know the pros and cons of each.
Web App Pros
- One code base that can run on the computer, mobile browser, tablet and anything in between
- Programmers are cheaper for it (lots and lots of PHP/Ruby/.net programmers out in the wild)
- You can upgrade and put out new features faster (don’t have to wait for users to upgrade your app or wait for Apple/Google to approve your changes)
- Ads are easier to do
Web App Cons
- Animations(slide/fade/games) aren’t as smooth as native code on mobile browsers
- You have to build for multiple screen sizes and test for each (or at least the major ones)
- Users prefer apps over websites when on their phones. While you can pin web apps to your home screen in both Android and iOS, a lot of users are not aware of this feature
Native App Pros
- Distribution and payment processing is handled by Apple/Google
- Feels much more responsive when it comes to animations
- Games are much easier to do in native than in web (currently)
- Limited amount of screen sizes to test for (iOS)
- Customers prefer it to mobile-size web apps
- Less strain on your servers (if you have an app that needs a data back end)
- Get access to multitouch/GPS/compass/camera/etc
Native App Cons
- Programmers are more expensive to hire (local programmers are in the $60-200/hour range, overseas are in the $7-40/hour range)
- Apps take longer to develop and iOS apps can be harder to develop in teams if using a lot of interface files.
- Updates can take time (depending on the Apple and Google gods)
- Harder to beta test
- Require testing devices (more $$$)
- Can be difficult to update if you frequently change programmers
Who are Your Users?
Users are the people who using your app. For example, let’s say you want to build Craigslist. There are three primary types of users for a site like that.
- Users who are looking at posted ads.
- Users who are posting ads.
- Admins who are approving/deleting ads.
Depending on the type of app, you will almost always have an admin-type user who needs total control (without having to look at code or a database). You need to very clearly think about who your users are and what their goals are before moving forward to the next step.
User Stories: a Brief Overview
After focusing in on who your users are, it’s very tempting to start designing and creating prototypes for your app right away. However we recommend you slow down and think strategically about what your users need to be able to do. User stories are a great way to do that. Essentially, they’re sentences that describe behavior within the app. In order to create your MVP (minimal viable product) you need to have complete user stories for each type of user you want to support and for each feature you want.
Lets backtrack to the Craigslist example. I’m going to write out some of the user stories you would need to come up with. This can be very tiring work if you’re new to it because it forces you to think from the user’s point-of-view, and you’ll have to write out all your ideas that were in your head in a simple, organized manner. User stories are essential to conveying what you want and what the app should do. Your developers and designers will love that you’ve thought out all of this before approaching them, because it gives them a very clear picture of what needs to be built. Personally, I won’t continue with a client who does not want to do this step. I’ll either sit with them and brainstorm, or have them do it themselves. For a simple app, this should only take about an hour or two. For a complex one, a group can spend a week doing it. Realize that it will never be final but you need to limit yourself on features so you don’t have too many at the start. But the ones you do have need to be very thorough and well-documented.
Example User Stories: Craigslist
There are three types of users: Lookers, Posters, and Admins
- As a Looker, I want to browse ads from my city.
- As a Looker, I want to see more details for an ad.
- As a Looker, I want to be able to contact the poster from an ad.
- As a Poster, I want to be able to login to see my ads.
- As a Poster, I want to post new ads in my city.
- As a Poster, I want to be able to update/delete my existing ads.
- As an Admin, I want to be able to login to see my dashboard.
- As an Admin, I want to be able to see all ads by city.
- As an Admin, I want to be able to delete/flag an ad.
- As an Admin, I want to be able to stop a Poster from posting new ads.
Example of Complete User Story #7
- User stories 1,5,6 need to be complete first.
What needs to be done
- Page for list of existing ads by the Poster with delete/update buttons.
- Page for details of a specific existing ad with editable text fields and an update button.
What could go wrong?
- Edits are not being saved.
- Deleted ads are not being deleted.
- Ad is either edited or deleted depending on which action the user selected.
So now that you have all your user stories written out, it’s time to create a flow for your app. First look through all your user stories and see if you have common pieces. Examples of this would be login pages, new data creation pages, and data display pages. Then you need to create some basic sketches of what is on each page and a very basic layout. Do you have an app with a top menu? What’s in the menu? What is being shown on each page (ie profile page, posts page, single post, etc)? For iOS apps, I usually use note cards and make one for each page, then lay them out on a table/floor and try to see how the users would flow from page to page. Sometimes you can combine multiple pages into one (and make it a longer page that scrolls). If it’s too long, then you can break it up into multiple pages.
In our next post, Idea to Product: Part 2, we’ll discuss the services and tools we recommend to power your app, how to familiarize yourself with design and programming, and where to find designers and developers if you decide not to do it yourself.