Designing Insanely Great Apps

Steve Jobs first used the phrase insanely great when trying to inspire the original Mac team to build not just a great product – that had been done many times, he said, but their goal was to build an insanely great one.

Let’s begin with the way you must not design an object which is to be used by people: do not design its form or appearance first. The key is to design the function of the app, and then decide what it looks like.

For example, consider the iPhone. Jony Ive designed the phone to be held in one hand and operated with the other. So intent was he on what the phone looked like, that he produced a slick, slippery device that 99% of us can’t hold at all. The result is we all buy cheap plastic cases to cover the sleek, elegant phone in something which looks like a recycled food wrapper. Don’t make the same mistake with your app – don’t use subtle shades of grey on slightly darker shades of grey for the UI controls, for example, regardless of how nice it looks. Function first, then form!

The secret to designing insanely great apps is:

Design a physical model which allows its users to manipulate their conceptual model of it, in the way they do their jobs, to reflect their mental model’s need within the problem domain.

It’s a mouthful of technical terms, so let’s break it into more digestible chunks by using an example. Consider a marketing manager planning her marketing department’s annual budget using an Excel spreadsheet.

Users use your app in their problem domain. We’ll focus here on business applications, where this domain is your users’ personal area of expertise, their vocation, and thus their daily field of operations. This domain is the raison d’être of your app. You design it to provide the functions your users need to do their jobs: to manage a project, to calculate their department’s budget, or to design an airplane, and so on.

The user’s mental model is the image in her head when she’s thinking of her problem domain (the marketing department). She’ll think of the department she’s managing, not in abstract form, but in real life details like the actual office space, the people in the team and their roles, and so on.

The physical model, the Excel spreadsheet in our example, is, for most of the apps we’re talking about, the Graphic User Interface’s windows, panes, and controls and the physical ways your users interact with and control your app.

The conceptual model is the bridge between the physical model and the user’s mental model. In our example, it’s the spreadsheet which to the manager is her budget. It’s the way your users think of the physical model, within the context of their problem domain.

So how do you use this to design a truly great app? For convenience, I’ll repeat the definition:

Design a physical model which allows its users to manipulate their conceptual model of it, in the way they do their jobs, to reflect their mental model’s need within the problem domain.

Note that the statement in italics does not say anything about the function or how it should be provided. The key is not to focus only on the what of the function, but also to understand how the user performs the task. In other words, you must understand your user’s approach to the task he’s performing at work. Not the function, per se, but how he goes about doing his job.

To illustrate within our example. Imagine our marketing manager is working on her departmental budget. She wants to add an expense row to reflect her Pay-Per-Click (PPC) costs for the Google AdWords campaign she’s currently running. If Excel truly understood her job at this instant, it would allow her to label the new row, Google AdWords Campaign #1, click on it (with a command/option combination of keys) and be taken via a new browser window to her AdWords campaign on Google’s AdWords site. And there she would point to the column with the first month’s actual PPC costs and Excel would automatically ripple the monthly entries across the columns into her budget’s equivalent columns within the row.

Forgive me if I am stretching the analogy, but the essence is that Excel’s physical model, the spreadsheet, ideally would enable this action because it’s one of the tasks a marketing manager performs when she’s doing her job. It would, referring to the definition above, be enabling her to reflect her mental model’s need (to show the expense of the campaign in her budget), by allowing her to think about the issue conceptually, “I need my budget to show the monthly PPC costs as an expense,” and thus enable her to easily manipulate the physical model (the Excel spreadsheet) to reflect the costs of running the AdWords campaign.

The good and bad news

The good bit is that if you could climb inside your users’ heads and watch them perform their jobs using your app, you would see not only what the function must do, but how they go about doing it. You could then design the app to make the user’s job easier, quicker, and more repeatable, because, by definition, the ways to manipulate the physical model are now intuitive. And if you capture an expert’s way of doing the job, your app will inspire other, less expert users to do the job in the same way. It’s the kind of technology-based coaching built into the Sensei Labs platform, for example, but instead of being housed in the corporation’s digital intelligence, its built into the app as a do-it-this-way guide.

The bad news is, of course, that you can’t get into a person’s head this way. Not yet, anyway. So, your choices are:

1. Design an app for a field in which you are the domain expert. By being inside your own head, you eliminate the gap between all 3 models. Obviously, most developers are not in this position.
2. You can partner with a domain expert, a company, team, or person, who begins by explaining what’s needed, and then uses your early releases to provide feedback on where they have trouble transforming their conceptual model to meet their mental model’s needs.
3. You can hire a domain expert to help you in the design and testing stages. This isn’t ideal as the feedback loop should be a permanent one.
4. You can do what most developers do: take a first cut and iterate towards a better solution as you learn more about the problem domain and its use cases.

The last one is the slowest and least sure path to success and thus the 2nd approach is usually your best bet. But in both 2 and 3, make sure you hire a real star. Hiring a mediocre domain “expert” is like setting out to soar with eagles while flocking with turkeys.

One more example? Consider our marketing manager again. Let’s say that in the real world of her marketing team, she needs to transfer Mark from his position in the content team to the telemarketing department. Looking at the conceptual model, our marketing manager understands that she must move Mark’s row in payroll from its current position to the new one. She selects the row, grabs it, and drags it to the new location. But when she gets there, she realizes she wants to place it in between two existing rows – she wants to maintain a specific order, perhaps. But when she hovers her cursor over the line between the two rows to indicate she would like to insert it there, and then drops it. Excel responds with an error:

There’s no understanding built into the physical model that a user will want to insert a row between two existing ones. You must cancel the operation, use the main menu at the top to insert a row – there isn’t even a shortcut – and then repeat the select, drag and drop. I have the same kind of issue with Word: it opens a long document at the beginning every time instead of at the location I was last editing. I have either to use the function-end combination of keystrokes to get there, or even worse, search for the place because I was working somewhere in the middle!

These are small inconveniences, true, but oft repeated ones. Next time you’re thinking about your app, ask yourself where your design does the same thing. What features have you implemented, in what is usually the easiest way for you and your team to do that, are forcing your users to do 2 or 3 extra steps to accomplish what they are really trying to do?

Final thoughts

Insanely great apps are so good because their users don’t have to change the way they do their job to use your app. Your app, in fact, not only allows them to do their jobs the way they like doing them, but it shows them how an expert would do this same operation, potentially adding significant value.

To design an app which works like this you have to design the UX before you design the app’s functions. You can’t tack a UX like this onto the functions after you’ve designed them because the function must be designed to mimic the user’s actions.

Happy designing – think insanely great! – your users will love you for it.

A note from the author

If you’re undertaking a UX design exercise on behalf of a new startup, you may find our COVID response course of some use. It’s a crash course on how to launch a startup and its seven steps begin with The Idea. We’ll even show you how to find one if you don’t have one already! Think of it as an entrepreneur’s apprenticeship because by the time you finish the theory and exercises, you’ll have launched your company and be your own boss.