Making the Tally Ho App
A Tale of Charting New Waters
I was in danger of drowning in 2011.
I had pushed off from shore, quitting my job to work on my first startup, GardenZip. I had recently moved from NYC to Mountain View, CA and now had a patio on which I wanted to put some plants. I was frustrated by how difficult it was to find suggestions for what plants would be most likely to thrive, so I set out to solve that problem. I interviewed users, researched the home gardening space, recruited a developer and gardening expert to join me, and made some static mockups of what I wanted to build.
And then, I ran out of time: my boat had taken on too much water as my personal savings dwindled and I made a sad retreat back to shore. I later realized that I hadn’t brought the right tools and process, as if I had set out on my adventure without a compass, sextant, and spyglass. My boat was zigzagging around in the dark, making forward motion but no real progress.
So I spent the next few years learning how to be a better captain and explorer. I’ve found that thoughtful preparation, dependable tools, and solid navigation principles will greatly increase your chance of success. This post captures some of what I’ve learned, to help other entrepreneurs, product designers, and product managers turn their ideas into reality. The below outline is exactly how I’ve made my latest project, the iphone app Tally Ho.
Think Like an Entrepreneur: Get Inspired
As with everything in life, proper preparation will save you loads of headache down the road. Give yourself the best chance of success by first thinking through what you want to make, before you start making it.
The D.School at Stanford University has a suggested design thinking process that generates compelling and creative ideas. The lean startup methodology also has a lot of great strategies. I liked the book Running Lean as an action-oriented walkthrough of the lean process.
All of these methods start with talking to people. Interview potential users to identify pain points. It helps to start with a hypothesis, drawn from a pain in your own life or something you’ve observed, and talk to people about the ideas that stemmed from that .
In addition to identifying pain points, also interview your users about how they currently solve their problems.
- Do they just live with them?
- Have they come up with a hack?
- Do they use competitive products or services?
Ideally you want a lot of people to have the same problem that really bothers them. You also want to develop a sense of who might benefit from your product. I.e. who is your target audience?
For Tally Ho, I was originally inspired by how difficult it is to see my friends. I mapped out my process of having people over for dinner or organizing a hike, and realized there were a lot of steps and time involved. My interviews revealed that my urban young professional cohort is also bothered by how getting together often feels like herding cats. Some solutions exist, such as Evite and Facebook Events, but they aren’t used often. Instead, everyone relies on group emails, text messaging, and/or messaging apps to organize the weekly casual get togethers with friends.
At this point you’ve probably got some ideas of potential solutions to this problem. Define each of your ideas in a single sentence, to clarify what you’re proposing. Rank your ideas based on acuteness of need and likelihood that your proposed solution could meet that need.
A slightly more formal way to think through and rank your solution ideas is to use the Business Model Canvas, developed by Steve Blank at Stanford. It helps you determine whether you could build a viable business around your idea.
Decide What to Build
Entrepreneurs are faced with difficult decisions all the time. First and foremost is what to build and how to build it. Your top solution idea is your hypothesis for what to build first.
Instead of immediately coding the big vision, which would probably take months if not years, think about how you can quickly get feedback via experiments. You want to build the smallest thing possible, launch it, measure how it performs, then take those learnings to figure out what to build next. It’s an iterative loop of product development.
You want to both test market demand for your product as well as prove your ability to actually build said product. I like Lean Stack’s stricter definition of MVP (Minimum Viable Product) as “the smallest thing you can build that delivers customer value.” This doesn’t necessarily mean committing code — here are some examples of running small experiments to test demand.
Since I intended Tally Ho to be a mobile app that delivered a brand new experience for the user, I decided to test demand with a prototype. Instead of describing my concept in words, I could show them.
The point of prototyping is to quickly evaluate an idea. Prototyping software used to be known as “wireframing,” although today’s prototyping tools are more sophisticated and blur the line between wireframing and visual design. Today’s prototypes let you more effectively communicate content, meaning, and usefulness, while also understanding design usability. And anyone can quickly learn how to create a prototype, without any coding required.
Lastly, now that you’ve decided what you’re generally trying to build, set a goal and timeline. It’s important to stay focused. And also know when to quit, if you’re not hitting your goal within your timeline.
Prepare to prototype
Now we flesh out the top solution idea into fully-baked product idea. Keep your app simple and focused. Brainstorm all your potential features then focus on just the top five most meaningful ones. If you’re working in a group, Google has some good suggestions for managing this process.
Decide what device your users will be on. Is this a task they’ll do sitting at a laptop? Lounging at home with an iPad? Sitting on the toilet with an Android phone? Besides understanding what screensize you have to work with, you also want to think about the context in which people will be using your app.
Next pick a prototyping tool. I value speed to iterate and ability to replicate actual app feel (visual design, animations, variables, show prototype on actual target devices).
This article was written a year ago, but holds true for what tool options are out there. I used Balsamiq for many years, but I switched in 2016 to Proto.io because it does a better job at replicating actual app feel. This article is what convinced me to switch.
You can hire a product designer to build beautiful prototypes for you, but I recommend doing them yourself. You’ll learn a lot more about what your users want and how to deliver it to them. And figuring out what product to build is the core of any company, so I wanted to stay hands-on. I decided to handle all the prototyping myself and then hire a visual designer later, to help me polish the prototype UI into something very professional looking.
Tip: If you are design-oriented and want high-fidelity design on a budget, try browsing Dribbble or Freebiesbug to find top-notch mobile UI kits as a starting point. That way the color palette, typography, and button styles are already defined for you and give you quick visual cohesion.
Prototype the Solution in a Day
In the morning, start with a pencil and hand sketches, so you can quickly work out your ideas. You’ll probably find that as soon as you start sketching, you’ll think of a few different ways to design the interface. You may also notice problems with your design, which is fine.
Plan the user flow–what’s the main path you want users to take, from start to end? Optimize your design around quickly delivering value to your users.
Chart out every scenario your user may encounter and whether to address each scenario or not worry about it. It’s tempting to add in additional options and features, but keep the design simple. Don’t try to be everything to all users; your job is to find the simplest solution to the problem you set out to solve. It’s fine to say “we won’t handle that at first” when talking about certain use cases and feature requests.
Look for inspiration from competitors and products you admire. The best artists build on what’s come before and other apps have probably solved the similar usability challenges, such as how much information to show about a given item for sale. Borrowing UX design patterns from others also improves your app’s usability, since your UX is rooted in paradigms your users already understand. For example, a clickable button should look obviously clickable.
You can Google to find libraries of UX inspiration. Also check prototyping tools because they often publish example templates you can import and use in your project, such as Proto.io’s Spaces .
Now that you have your sketches and inspiration, build the prototype with the tool you chose. You may need to watch a few training videos to get the hang of it.
Start with the basics of the app you envision, to get the main screens and flow down. You can go back and fill in screen details later. You’ll probably notice problems with your design, research solutions, and modify the prototype as you go. That’s all normal!
Start with just black, white, and grey in the screen size of the device you’re designing for. That lets you stay focused on the content and interactions of each screen, without getting distracted by colors and icons. You can polish the visual design later, after the app bones are right.
But DO put actual content, not lorem ipsum or placeholder images, because you need to see what fits on the screen and how the prototype would function with real usage. You may discover that a full mailing address doesn’t fit into the space you left for it, in which case you’ll need to modify the layout or decide to not show the full address.
The prototype I built for Tally Ho that first day was pretty basic. It had a main New Event screen, four input screens to easily let you enter Who, What, When and Where, a My Events screen, and an Event Details screen. I focused first on optimizing the experience for simplicity and speed, since I didn’t think the existing event apps provided a very good mobile experience. I wanted something so simple you can do it with one thumb while walking down the street or riding the subway.
Show the Prototype to People
Socialize your prototype with at least a few people and get valuable feedback. You can start with a significant other or roommate. This is an important sanity check: the prototype makes sense to you because it’s your baby, getting fresh eyes will help you discover the flaws that are part of the whole lean build, test, learn cycle.
Now show your prototype to some people in your target audience. They’re the ones you’re building this solution for. Talk to them about how they currently solve the problem, then show them your proposed solution and get feedback.
Ask your interviewees questions that help you determine their level of desire:
- How do they currently solve their problem?
- Are they spending time / money / resources to solve it?
- How often could they see themselves using your proposed solution?
- What feature do they like best?
- How would they describe the app in a single sentence?
- Would they commit to telling 10 friends about it?
- Would they commit to spending more time with you in the future, to help you test?
- Would they pay you $3 / $10 / $100 right now for this product?
As you gain experience interviewing, try to differentiate between people’s true beliefs vs telling you what they think you want to hear. That’s why the commitment questions are helpful; if people aren’t willing to give you social status, time, and/or money then that’s a bad sign. They’re probably just not that into your prototype.
Start small, with people you know in the target audience, then at the end of the interview ask for intros to other people they know who are also in your target audience. Some entrepreneurs like to use a 3rd party service like Validately or User Testing, to make sure feedback is objective. But using your own network is free and I prefer to do this user testing and feedback in live, 1–1 interactions because we can dive into why something is or is not working. We can discuss potential improvements that would increase how much value they’d get from the product.
With Tally Ho, I validated that everyone cares about being social and 2/3 of my interviewees initiate plans at least once a month and spend significant time and energy pulling people together. I then asked how we could make Tally Ho even more useful. After hearing their answer, I proposed three additional features and asked them to rank those features. From that, I confirmed that scheduling time with friends is a major pain point in setting up a get together. The app would become much more compelling–and be used more often–if I could help navigate messy schedules.
After you talk with three to five people, you’ll probably hear some consistency in what they understand, like, and want. Iterate on your prototype, focusing first on the big questions of whether the prototype meets a need and is understandable. Go back to one or two of the people you already talked to and confirm the design is an improvement, then go talk to three to five new people. Then when those big questions are covered go into smaller choices like calendar pickers, font size and color, design consistency, and how to onboard brand new users.
After 30 or so of these 1–1 prototype interviews, you should feel pretty confident in your prototype. If you don’t, keep experimenting and learning. By iterating in the prototype phase, you’ll have a much more refined idea of what you should build with code and you’ll be able to code it faster. It’s easier to iterate a prototype than a coded app.
Building the Actual App
By building for iOS or Android, you’ll be able to take advantage of all the support the systems provide for native apps, which will yield a much more pleasurable user experience. I chose iOS.
There are many approaches for how to actually code your app:
(A) Learn to code yourself, using online resources
(B) Use an app-building service that doesn’t require coding
(C) Partner with a technical cofounder
- Work your personal network
- Go to pitch events
- Try a hackathon
(D) Hire developer help
Your polished prototype is invaluable for effectively communicating what you want to build. It helps you recruit a partner, because you have market feedback already and can clearly define what you want to build. It helps you hire, too, because the developer can give you a detailed estimate of how much time and money is involved.
For my other projects I had partnered. This time around, I decided to hire help because I wanted to move as fast as possible and none of my friends were available to work with me full-time. I posted on a few sites, and ended up choosing a developer in Poland who was on Upwork.
Make sure you agree with your developer on how to communicate. This is especially important if your developer is remote. For Tally Ho I used a number of free tools.We chat daily in Slack, discuss thornier issues with Skype video chat, and manage the development lifecycle with Trello. The prototype remains the source of truth for how the app should function, and Trello helps me explain in more detail exactly what I want. We work on the app one week at a time, with my developer delivering the latest builds to me via BuddyBuild.
Prototype Questions That Come Up
Throughout the development process questions will come up. Maybe an idea or problem comes up from user testing. Or you realize you didn’t fully think through all the edge cases of the user flow. It’s important to prototype and test those design details as they come up before you lay down code. It’s easier for you to prototype than it is to code.
With Tally Ho, my developer often suggested ideas for the app design. And once we started building, I also hired a visual designer to help make the app’s look and feel really sing. He also had a number of interaction suggestions.
Example 1: Picking an Activity
One screen in Tally Ho lets the user pick what activity they want to propose to their friends. We give a number of pre-filled options, so the user can simply tap an option instead of take the time to type it out. I originally had this in a vertically-oriented list, but my designer suggested using larger icons in a matrix layout. I thought it was a very valid idea, so we tested it.
The seven people I talked to were split about which layout they preferred. The time taken to select “coffee” in each list was about equal. But everyone agreed the large icons were more fun than the text-heavy list. Since the usability of both layouts were pretty equal, I opted to go for the more delightful design.
Example 2: Onboarding
When a user fires up the app for the very first time, you need to help them get set up to use the app. This is called onboarding. When researching the app store, I noticed that social apps tended to put the user immediately into account creation, whereas business apps usually let you poke around before asking you to sign up. I wanted to test those two paradigms.
For half my interviewees, I showed them account creation first, then the main app screens. For the other half, I dropped them right into the main app screens and only asked for account creation when they went to send their first invite. No-one had a problem with account creation up front because (a) it’s normal and (b) in deciding to install the app, they already had a good sense of what it did. What was interesting was putting account creation later in the experience DID have a drawback: just when the user was excited about sending out their invite, we held them up by asking them to create account.
So I went with account creation first. I then wanted to test a variation: should I ask for one piece of personal info per screen or put them all on one screen? I found that since we were only asking for name and phone number, it was better to ask for it all on one screen.
Example 3: Choosing Date & Time
My original prototype used the native iOS date and time picker, to let the user set the event time. It’s the same picker used in the Apple calendar app and other places, that users are already familiar with. But when my interviewees really liked the idea of letting them propose multiple times, I needed to modify the prototype. Should I cram all the times into a single screen or spread them out? And now that I think of it, is the scrollwheel really the best way to pick the date? I prototyped three options and again tested them in two rounds: A vs B, then the winner vs C.
The winner was using a calendar layout for the date. As I discovered in my tests, when making plans with friends, you’re usually thinking of “next Friday” not “Friday the 13th.” The visual week by week layout of a calendar is both familiar as well as speedier to hone in on the day you have in mind.
DESIGN A — Using Apple’s Default Scrollwheels
DESIGN B — Using Calendar Layout for Date & Scrollwheel for Time
DESIGN C— Dividing Date & Time Into 2 Screens
Tip: sometimes you can take shortcuts with the prototyping, by pre-determining the scenario for your testers. For creating the calendar picker prototype, it would’ve been very time intensive to make every day selectable. Instead, I set the scenario for my testers: I told them “let’s make the event this Friday at 9pm”. Since I did this testing on the 13th and 14th of June, I knew they would be tapping Friday June 17th. I also made the squares around the 17th tappable, to make sure the target area wasn’t too small. If fat fingers meant this layout was too difficult to use, then that would be a key learning!
In all three of these examples, conducting usability tests with variations on the prototype helped me quickly make an informed design decision. With a small development team, I could use our time more wisely.
Test the App Thoroughly
I chose to prototype to test the market demand and to build the actual app to prove execution ability. While the prototype has gotten you pretty far on that journey, you of course need to thoroughly test the actual app to make sure it works and meets a need.
Build it in stages, focusing first on core screens and features. Start with testing the app yourself. Instead of testing features in isolation, test them in the context in which they’ll be used. Those use cases you thought about back during the sketching design phase will come in handy. Go through the main path and all possible variations. This will probably surface some bugs to squash and helps you have a robust product before you ask for people’s time to help test.
When that basic app is ready, put it in the hands of some testers. Like with the prototype tests, it’s best if you can do this with live 1–1 moderated tests to learn more about why something is or is not working. It’s ok if some parts of the app aren’t yet smooth and if it’s not aesthetically pleasing. Check in and make sure you’re on the right track before continuing to invest in building out features and polishing the product.
Here is a great primer on how to conduct usability testing that will give you accurate and insightful results. As you continue to learn, you may want to do more prototyping and testing.
Example 4: Collecting RSVPs
We realized that the RSVP collection system I had designed for Tally Ho was harder to build than originally thought. In the usability tests, it just wasn’t working and would take a while to fix. Testers suggested some options, one of which I particularly liked: instead of showing a matrix of responses, why not just have the user tap to cycle through them? A suggestion worth testing!
I prototyped that RSVP method and showed it to five people. One of the five preferred the matrix, because it was obvious what all the options were, but figured out pretty quickly how to cycle the responses. The other four surprised me in preferring the tap to cycle, because it looked cleaner and was still easy to use. That option was also a lot easier to build and maintain, so we went with cycling.
After you’ve worked out the kinks in moderated testing and think you have something usable built, it’s time to do a “beta” test in the real world. A few tools, such as Testflight or BuddyBuild can help you get the app on tester’s phones and channel feedback back to you. The idea is to have your beta testers put the app through its paces in the real-world. This is another checkpoint to make sure the app solves a real problem, is easy to use, and is bug-free.
Since you’re not able to watch over the beta testers’ shoulders, you’ll want to make sure to include an app data tracking tool such as Crashlytics. This will help you track down what goes wrong with certain bugs, and understand how your beta testers are using the product.
Launch Your App
As I described earlier, our goal is to launch the smallest thing you can build that delivers value to your users. Your process of researching, prototyping, testing, building, and testing again should result in you having a solid version 1 of your app. Now it’s time to set your baby free!
The lean startup philosophy gets things into user’s hands asap, so you can learn and spend your time on the right things. Your app should solve a real problem with a unique solution. It probably won’t have all the features you want and may not even be remotely close to what you originally set out to build, but that’s ok. It’s time to launch it in the Google Play and/or Apple App stores and see how your target audience reacts.
Marketing an app is a whole other skillset and is incredibly important to having app success. Google around to find advice about activities you can start on before you launch, such as
- Build a beta list (everyone you interview will hopefully want to try the real thing!)
- Work your personal network
- Set up PR outreach
- Reach out to influencers in your target audience
- Get active on social media
As with everything in this process, it’s important to identify a few key metrics and work on improving those. For Tally Ho we’re focusing first on app engagement and organic growth. I want confidence that sparks are catching before we layer on bigger wood and fan the flames. To improve engagement and growth, the process of build-test-measure will continue, with prototyping new ideas front and center.
THANKS FOR READING THIS FAR!
We’re always looking for feedback about Tally Ho. Try it and let us know what you think!
