"I endorse this message" — Plato

The strategic design of our next app, Languages, continues apace.

In the last post we gained an understanding of our personas’ experience without an app. We now need to imagine how an ideal app could make this experience 100% better, without worrying about bothersome constraints such as money, technology, time, or reality. It’s time to build a Platonic app (Plato, as you’ll recall, thought that all physical things are fail and that their is an ideal, perfect form of all things floating in heaven). Construction materials include aether, fluffy-golden clouds, and joyful thoughts.

It is essential to have a vision of an ideal app so that we know to what our imperfect app should aspire. You have to have a clear understanding of the ideal if the real is going to approximate it.

Here’s how it works. We look at our three experience domains (solo, social, and travel), look at all of the experience nodes in those domains, and then yell out ideas for how an app could improve those nodes 100%. Jeremy then writes these ideas on a sticky and posts them in our “ideal assistance” section beneath each experience node. The aggregate of all these ideas is our fantasy app.

Please pardon the calligraphy and the shaky-cam.

For example, when we examined the “social” domain, we determined that when you’re in a business meeting in Milan and an Italian colleague says “sono molto dispiacentissimo” you want to be able to nod your head and find out what that means without him knowing that you have no idea what he said. You don’t want to look like a fool. So we wrote down “incognito,” indicating that the ideal app could feed you definitions on the sly (of course this sounds impossible; but stick around). We also determined that an ideal app would feed you definitions extremely quickly, because you don’t want to spend five minutes in the street figuring out what “Achtung! Achtung! Ein Auto kommt!” means.

Once we have posted all of the characteristics of our Platonic app on the wall, we go through and draw a big, red x over all features that (1) are beyond our means or (2) would bloat 1.0. We call this step “killing the baby.”

Killing the baby is a traumatic experience for some.

So, of the two feature examples above, we put a big, fat, red x on “incognito” due to technical constraints. But we kept the idea of quick definitions because we felt that it was doable and essential.

What we’re left with is the list of features that will appear in Languages 1.0.

Now we’ve established how Languages serves our business goals, identified the market, and sized up the competition. We’re convinced that the app is a good idea. The preliminary investigation ends. We can now pull out the microscope to analyze our potential users.

We first have to identify all of their relevant characteristics. We have a leg up, in this regard, because I happen to be a linguaphile. I’ve studied various languages seriously (Espanol, Italiano, Deutsch) and have dabbled in many more (Latin, Greek, Swedish, Old English). I’ve studied languages over an extended period of time and in many academic contexts. I’ve used all sorts of translation dictionaries, physical, digital, and mobile. So I basically embody many of our use-cases (not the business one, unfortunately).

After thinking about it, doing some research, and banging around ideas, we come up with a list that runs the gamut of user characteristics. It looks something like this:

We identify which of these characteristics we should focus on. We decide to not worry about the professorial use-case, reasoning that foreign-language professors either won’t need Languages or will demand something much more academic and rigorous than we want to provide. We put asterisks beside the characteristics that we deem important.

We take the salient characteristics and click them together into several personas. These personas, on the one hand, embody the important user-characteristics; but they also help us think about how our app fits in the context of a real person’s life. Personas bring us out of the abstract and into the concrete. And we find that abstract thinking is the death of good UX. Concreteness, on the other hand, forms the foundation of good design.

We then come up with this:

Now we’re designing for “actual” people. We can now barrel ahead into the next stage of strategic design: mapping out the user’s experience.

We’re going to need a wall for this.