The Two-Step Design Process

As developers, we absolutely love when the boss approaches us with news that they’re adding a brand new feature or module to the app or, even better, they want us to create an entirely new app with a particular solution in mind. For the next week or so, developers will be caught leaning back in their chairs, glassy eyed and dreaming of all of the garbage code they wrote (or have to deal with) in the existing app that they can make cleaner and more efficient in the next app. Technically, they’re in heaven. (Bazinga!)

While I could go on an on about the intricacies of how good code inevitably turns into garbage over time, that’s not what this particular post is about. This post is about the two often underutilized steps of the design process that’s allowed me to be successful in implementing most new modules at a high level and ahead of schedule.

The Quick Sketch

"Make me some mockups of the new app.”

This is what my supervisor said to me after sharing the details of how the app is going to work and what problem it’s trying to solve. So after a day of sketching, I gave him something like this...

A few examples of quick sketches to flush out the basic design concept.

“What is this? I want mockups. This has no detail at all.”

He went on about how he wants to see real data on the mockups, wants to know where every field is going to be laid out almost down to the pixel and see every icon in all it’s glory. We then embarked on a lengthy argument.

What I was trying to explain to him is that design is a two-step process. The first step is going over some very quick and very rough sketches to lay out the most basic idea of how the information will flow. This is where you make the a lot of the technical decisions; does it use navigation controllers or tab bars or a split view? What are the visual differences between the iPhone and iPad versions? What’s the authentication flow? Do you need any custom controls?

It could take a week to create a full app mockup with the level of detail that my supervisor was requesting, all the while not knowing if the design direction is the correct one.

In this particular instance, I’m glad I didn’t work on the detailed mockup because we ultimately ended up going with a completely different design direction than the one I was pitching. If I had taken a week or longer to create a detailed version of my design idea, one of two things would have happen:

1. We would have quite a bit more time invested in my design and it’s harder to back away from it, even though it may ultimately be the wrong decision for the customer.
2. We would decide to go with a different design, wasting that week’s work.

All of this could have been avoided by simply going over the quick sketches and making some key decisions before moving on to the next phase.

The Prototype

A typical “new” project usually consists of this type of time allotment:

Typical New Project Time Allotment

This means that if you have 100 days to work on a project, 20 days should be spent designing, 50 developing, etc.

I believe that the time allotment that works best should be closer to:

Recommended New Project Time Allotment

Crazy, I know. How in the world can anyone create anything with a 20% development time?

This time arrangement might not work optimally in all programming jobs but in jobs like mine, related specifically to enterprise iOS development, it’s pretty darn reliable. 

Have you ever used mockup or wireframe tools before? There’s hundreds of them and many of them are even specifically built for mobile app projects. But it still takes hours to tediously design all of the views for a standard application, and even more hours linking them all up to have them function in a way that “sort of” gives the end user an idea of how the app might work. That’s great, the end user can request changes and you spend more time tweaking these wireframes. After a few rounds of revisions, he gives you the thumbs up and you’re ready to start programming.

What happens to these wireframes you spent weeks on? Well, they’ve done there job, now they guide you as you start to develop the app from scratch. What if these wireframes were actually usable code that you simply drop into your application? That, my friends, is iOS storyboards. 

iOS storyboard prototyping is significantly better than wireframing because:

1. This isn’t a wireframe, it’s a working prototype. The behaviors that the user sees on their device are exactly how the app will function once it’s finished.
2. Storyboard prototyping, in my experience, takes roughly the same amount of time as wireframing a comparable end product but all of that design time is actually development time, since these same storyboards will be utilized in the live application. 
3. Any “issues” with UI design are being handled during the prototyping phase and not mistakenly promised to customers just because the wireframe tool had a nifty feature you wanted to show off.
4. Every iteration you perform on a wireframe is time not spent on development, so it’s critical to keep these iterations down to a minimum. However, iterations performed on a storyboard prototype is development time so this allows you to perform more iterations than you normally would to ensure the best possible product before the deep development starts.

I can typically get a fully functioning prototype to an end user in about a week, even for a fairly large app. Here’s a snapshot of the quick storyboard prototype I put together for Lori’s Hands, a non-profit volunteer network.

Storyboard prototype of Lori's Hands App

All of the data that is displayed are simple hardcoded dictionaries. Almost all of the buttons function exactly as they will in the actual app, informing the user how each data point will look and how the app will flow. 

The only item I typically avoid at this point is passing data between views, for example, when you tap on a particular client on a list and the next view that slides in has information for the client you tapped on. In my prototypes, the data is hard coded so the same client information will appear no matter which client you tap on throughout the app but users can typically see past this and understand what’s going on.

At this point, the user can come back with as many visual requests they want; changing animation speeds, moving buttons or swapping icons, re-arranging the data, etc and all of these changes go directly towards development time and end up in the final application. 

Once they’re happy with the prototype, you dedicate that focused 20% of development time to swapping out the hardcoded data backend with a data connection or database then add business logic and validations.

Conclusion

The initial quick sketch portion of the design phase is common knowledge and works in all development environments but as I mentioned before, this rapid prototyping design phase is likely exclusive to iOS development (probably doesn’t even translate well to iOS video games). However, if you work in an environment that can pull this off, I encourage you to try it and measure your results.