Full Stack Product Design – Part 1

“Should we worry about what happens if the system gets flooded with too many return requests?”

My partner paused before replying. “Right now we’re here,” he said, hand about waist level. Pointing at the sky, “You’re all the way up there. We need to worry about getting to here first.”

His hand was barely higher than his waist. “The hardest part isn’t going from 1 to 100, it’s going from 0 to 1.” While we were talking about customer acquisition, I think the idea can be applied to all aspects of starting a business.

Here you’ll learn how to get to zero. Specifically, a complete tech stack behind developing, designing, and deploying your first mobile app for iOS and Android. Though every bit helps, no prior experience is necessary. You’d have to learn it all eventually.

You will learn

  • HTML5
  • CSS3 and SASS
  • Javascript
  • Angular JS
  • Phonegap/Cordova
  • Ionic


  • Node.js
  • Heroku


  • Deploying to Apple Store
  • Deploying to Android Play Store
  • Debugging


  • Knowledge of git is helpful, but can be acquired as needed. Do this Code School tutorial if you haven’t worked with git recently
  • Willingness to work with the command line
  • A Mac computer (one running OS X) is required to develop iOS apps. Android apps can be built on anything

We will go from soup to nuts, equipping you with everything you need to know to learn how to build a mobile app that interfaces with a remote server from scratch. Learning Javascript will be based off the excellent How to Learn Javascript Properly, though we will ditch JQuery in favor of Angular and make some modifications to the syllabus.

The only thing you need to bring is an idea for a mobile app you want to build.

Why you need this guide

The most expensive part of learning isn’t sitting down and learning the material, it’s trying out resources and getting partway only to find out they’re missing some crucial element you need to solidify your understanding. This doesn’t just waste time, it demoralizes you. Humans thrive on visible feedback about progress. If you don’t see yourself progressing, why continue?

This guide is the product of my attempts to teach myself. It’s what I would have wanted when I was starting out. It’s also a work in progress. As I learn I write more parts.

Do you have what it takes? (An idea)

It will be tough going to learn all this stuff. That same partner (and friend) who blessed me with the wisdom in the opening paragraph once tried to teach web development to me. He gave up after two sessions (as it turns out, being able to do something and being able to teach something are two radically different skills). Ultimately though my success or failure is dependent upon two things: my resolve to continue and my ability to find good tools to maximize the time I have available.

Having a concrete idea for an app you are passionate about building will provide you with the resolve, and give you the necessary filter to select what information is relevant to you. No matter how many people write amazing tutorials, there is no one-size-fits-all. Acquire specificity and crush.

What is an idea?

An idea is not a “what if” statement, or a string of that-would-be-cool’s. For us, an idea includes a mocked up wireframe of each screen (or “view”) your app can present to the user, with a description of what each button or graphic element does (“open help screen”) and how the user selects it (does she touch or touch-and-hold?).

For example, a vague idea might be “a social network for pet owners.” A real idea would include wireframes for each user view. What does the user see when the app starts up? Which buttons are where, and what action does each button perform? How does the user know what to press next?

What else is an idea?

In addition to the wireframes, your idea must be able to answer the following. Who is the customer, and what is their problem? For my app “Mamoru” the answer looks like this.

Everyone should get home safe. Use Mamoru to set a timer. If you don’t check back in before the time is up, Mamoru lets your contacts know something might be wrong.

The customer is “people who feel afraid getting home.” The problem is they don’t feel safe. The product solves this problem by giving them a lifeline to their emergency contacts.

An example

phone running

This first wireframe for my mobile safety app Mamoru shows the app in its running state. The navbar at the top lets the user know the app is Running. The button in the middle toggles the app state from on to off. The timer at the bottom counts down. When it reaches zero, an alert is sent out to your emergency contacts.

phone image

Here’s what the app looks like when the timer is not running. Notice the nav bar now says “Mamoru.” The background and action button’s colors have inverted, and the timer is reset.

settings view

Finally, here is the wireframe for the Settings view. A button in the navbar takes the user back to the main screen. A required field asks for the user’s first name, so that the alert messages can identify the user to his or her emergency contacts. An in-line plus button allows the user to add a contact, as the greyed out “Add Contact” helper text suggests. Finally, a Timeout Warning allows the user to toggle whether or not Mamoru issues a warning as the timer gets close to zero (in case the user has forgotten they turned Mamoru on!)

While this screen seems complete, a couple areas need improvement. First, the Timeout Warning function is not readily apparent from the title alone. Helper text, like a small text bubble underneath that displays for five seconds when the user navigates to this screen, could be useful.

Additionally, there is no UI element shown for the user to delete a contact. While it might seem obvious (change the plus sign to a minus), there are actually more questions. What does the minus sign look like? Is its color the same? If the user just taps to delete do we run the risk of accidental deletions? Should we require the user to slide the contact horizontally ‘out’ of the frame to delete instead? How do we communicate that expected behavior to the user without cluttering the interface?

Your assignment

Create the wireframes (user views) for your app. Each screen should be simple and uncluttered, with available actions obvious to the user. Try to think of how the views fit together (the “userflow”) as your user navigates the application. Is it a pleasing, unencumbered experience? Can the user quickly figure out what they want to do and how to do it? Be as specific as possible – these views will form the basis for your app’s architecture!

Next time

Next time I’ll layout the syllabus, and specify the texts and resources we’ll be using. If you want to grab books, JavaScript the Definitive Guide 6th Ed. (O’Reilly), and Professional JavaScript for Web Developers, 3rd Ed. (Wrox) are the ones we’ll use for this course.


I know it might seem tough, and that’s okay! Each post I’ll try to include some perspective on how others felt along the way. There’s no need to feel embarrassed about feeling overwhelmed. This stuff is tough, but we can do it!