7 Day Mobile App: Define & Design

In our overview of How to Build a Mobile App in 7 Days we explained our high-level process:

1) Define & Design

2) Architect

3) Build v0.8 and get client feedback

4) Finish v0.9 and test

5) Deliver the final app and Celebrate!

This article discusses Step 1: Define & Design in detail.


 

The purpose of the Define & Design Step is to translate the client’s vision for their app into a precise design that we can then build using the rest of our proven process. Some teams come to MetaNeer with nothing but an idea and some come with pixel-perfect designs. But most come with some paper sketches and a lot of ideas. We always start with what our clients have and go from there.

Each step helps us move from the vague and ambiguous into the concrete and actionable.

(Source: MetaNeer Labs, Inc.)

To better understand the client’s vision we begin delving into the company itself. Only after we understand the company’s purpose, do we move to the app. We help the client brainstorm around both their vision and the app. After everyone is clear on what the company does and how the app will serve it’s users, we start making decisions and iterating. It’s really essential that we understand the vision of the company at this early stage so that we can make difficult decisions at later stages.

Expand

We spend a substantial part of our design process in the conceptual stage. The overarching purpose of the first two steps – Braindump and Brainstorm – is to get as many ideas out of our heads and onto the table as possible. The client is in charge here but we facilitate these steps and throw out our own ideas as well.

Braindump

This step is all about getting pre-existing ideas out of our heads onto paper. There’s no creativity here – which can actually be the tricky part. We’ve found that it’s really important to hear all of the ideas that have been bouncing around in our client’s heads – sometimes for years – so that we’re not surprised by them later when we’re developing the app. Then we get creative. Once all these existing ideas are out on the table, we can start to generate new ideas and brainstorm.

Brainstorm

Brainstorming is an expansion step. We take existing ideas and build on them, twist them, and/or combine them with other ideas in order to build new ideas. We want everyone’s brain to reach as far as possible in order to push as far as we can get in such a short amount of time. Capturing as ideas as possible also serves to reduce the risk of changes in the future. We want to have most of the brilliant ideas on Day 1. Having them on Day 4 usually means that cool features don’t get implemented – leaving both the client and our team disappointed. So we spend the extra time here to get a lot of ideas on the table and hear from everyone.

In both the Braindump and Brainstorm steps, it’s really key to memorialize everything. Write things down and save them for later. Often we assign one person to make sure that all the ideas are captured – a facilitator. We have to constantly resist the urge to judge ideas at this stage. It’s an expansion step and even the wackiest, dumb, impossible ideas are welcome to the party. We’ve found that if we judge ideas prematurely or don’t write them down, that some folks inevitable feel unheard (which leads to dissatisfaction).

Most people love to brainstorm – it gets our clients really excited! But if we brainstorm forever, we’ll never actually build their app. We have to expand and contract. Expand & contract. The diagram below from Stanford’s Design School (where I spent 2 glorious years studying design) shows this concept well and it’s something we do again and again throughout our process. Expand & contract… expand & contract…

(Source: Terry Winograd at the Stanford d.School)

Contract

After generating a lot of ideas for the client’s app, we start to decide what we’re actually going to build. We take all of the wild ideas from the previous steps and contract. Let’s talk about decisions for a second: The word “decide” comes from the latin “to cut off.” Incisors are teeth meant for cutting – separating one part from another. When you decide to do one thing, you decide not to do others. It’s impossible to decide to do it all.

But even though everyone knows that making decisions is necessary, cutting always hurts. So we have a few tricks to make the cutting and decision process less painful for both us and the client: 1) cut by omission 2) chop & trim 3) chant non-permanence and 4) no wimpy-ribs.

Cut by Omission

Scenario A: Give a monkey 2 bananas and he’ll be thrilled. Take 1 away and he’ll throw shit at you.

Scenario B: Give a monkey 1 banana and he’ll be thrilled. Take none away and he’ll still be thrilled.

Am I calling our clients monkeys? — Yeah, pretty much. But they’re not alone. My team and I are monkeys too. It’s not an insult, just the reality of being human.

At the end of a brainstorm, there are 1,000 small – but tasty – bananas on the table that everyone wants to hoard. If someone starts taking them away right in front of us, shit will fly. I’ve seen it happen. But if we all take a break from the banana table, go munch on something else for a bit, and come back to fewer bananas, no one freaks out.

Enough about monkeys. Here’s how we handle this in the real world. We take our feature brainstorm and physically remove it from everyone’s sight. Everyone knows where it is. It’s not gone forever. It’s just not in front of us right this second. Then we usually talk about how the app should look and feel – a totally different topic than the feature brainstorm that we just completed. Sometimes we’ll go grab lunch or coffee and change up our environment. Then when we come back and start talking about features again, we start with a blank piece of paper. Our facilitator will pose a question like “What are our top 3 user-priorities?” She won’t write down everything everyone says. She’ll condense and summarize things into high-level feature sets. We start to make decisions.

That’s how we turn 1,000 small but tasty bananas into just a few big and really savory ones. It’s such a simple concept, but so infrequently done.

Read more about how to Cut by Omission.

Chop & Trim

There are two ends on the spectrum of decision (to cut off). You can trim away ideas bit-by-bit or you can chop off big chunks in once slice. Chopping is great because you can leave behind lots of mediocre or half-baked ideas quickly. But your design is a living thing and if you chop too much at once, it will bleed out. Trimming is great because it’s far less painful than chopping. But if all you do is trim, then you may never actually reach your core feature set and move forward.

We always do a mix of chopping and trimming so that things keep progressing but don’t bleed-out.

Read more about the art of Chopping and Trimming: The Scalpel & The Axe: What To Do After The Brainstorm.

Chant Non-Permanence

Once we’ve written down an idea, we never cross it out, crumple it up, or throw it away. Since cutting by omission is still an additive process, things stay positive and teammates don’t get defensive when an idea they had gets the axe. Another great tactic that helps cut down on any defensiveness is to chant the mantra of non-permanence. Sounds Buddhist – and I guess it is a bit actually – but the concept is that all decisions are just temporary… for now.

Concretely, if I’m ever feeling resistance to the cutting process (from either my team or from our client), I’ll write the following at the top of the piece of paper in all-caps:

TENTATIVE – NOT SET IN STONE

Then I’ll keep asking my condensing question. “What are the 5 most important things the user can do with this app?” or “If you had to pick, would you rather have X or Y?”

No Wimpy-Ribs

Occasionally I see a design or product that’s all bone and no meat (I’m a Texas-boy so many of my analogies are meat related). Imagine two businesses: a butcher and BBQ joint. If the BBQ business asked the butcher to cut most of the meat off of their ribs to save a little money, the customers won’t be happy and so they won’t come back, killing the BBQ business. If the butcher only sells wimpy-ribs, then they’ll go out of business eventually too. So leave some meat and a little fat on those ribs!

For the non-Texans:

  • Butcher = My Business
  • BBQ Business = Client’s Business
  • BBQ Customers = App’s end-users
  • Ribs = App
  • Meat = Features
  • Fat = ???

Before you get too hungry, let’s recap, talk about iterating, and I’ll finish up by telling you some of our best concrete tactics for the Define & Design step.

Iterate

Remember, this whole process is an iterative one: Expand & contract… expand & contract. We know from experience that by rapidly iterating upon the design (and later the architecture) we 1) better understand where the potential problems and hazards are, 2) incorporate more ideas into the final design, 3) get lost down fewer rabbit holes, and 4) generally set the whole project up for success.

Broad Strokes & Details

Our objective isn’t to iterate in circles. We’re trying to progress towards something. The end result of the Design phase is a precise specification that everyone is happy and confident about.

(Source: Boehm B, “A Spiral Model of Software Development and Enhancement”, “Computer”, “IEEE”, 21(5):61-72, May 1988)

After the Braindump and the Brianstorm we cut way down (by omission, chop-and-trip, and by chanting non-permanence) to quick-and-dirty drawings of the App. At this stage, we intentionally use fat-tipped markers and coarse paper to ensure that the resolution is low and that we don’t get bogged down in the details. We limit ourselves to just a few minutes for each sketch since we know that we’ll end up drawing this at least 10 times before we’re happy with it.

Using low-fidelity tools early on ensures that we can’t even try to make our drawings look perfect. It also forces us to focus on the big picture. How many screens are there? What do they look like vaguely? How do you get from one to another? How do you get back again? We intentionally limit ourselves with our tools so that we can focus on the task at hand: high-level consensus of what we’re going to build.

Immediately after doing a pass, we do it again. We iterate… expand & contract… We just start again – from scratch – resisting the urge to look at what we did in the previous sketch. We quickly re-draw the things that we have already learned and decided from the previous sketches, letting us take our best stab at the things that we haven’t quite figured out yet.

Changing It Up

Another thing we do is the Feature List. The feature list engages the brain in a new way and each feature usually starts with “User can.” User can tap the photo to expand. User can double-tap the photo to like. User can double liked photo to unlike…etc. As we translate our drawings into words, we engage our brains in a new way, forcing everyone to think of new things and things we’ve missed. We catch so many “implied features” by translating our drawings into words and then our words back into drawings – saving us tons of time later in the process.

Bottom Line: Step 1 in our 7-Day App process – Define & Design – is all about iteration: Expand & contract… expand & contract… towards a design that everyone can agree on and that our team can confidently take to Step 2: Architect.