App design: where to start?

In our last article we saw that before we start developing an app, it’s helpful to begin with a product design phase that can bring the idea to life through a mockup that shows the user interface, and perhaps a few work flow examples.

A variety of programs exist for developing mockups. The main advantage is being able to design screens by dragging and dropping the native smartphone components and little else. They’re just designs, but you can make them quickly.

What I’ve seen in my mentoring work is that even starting with a mockup can put us off course: even at this level we tend to use classic design criteria, and at times the result looks a lot like an old school business application.

So where should we start? In the last article I pointed out a crucial difference between apps and classic applications, which is the fact that apps are not general purpose. Instead, they run specific, well-defined processes. These processes are desired, activated, and controlled by the people who need them.

So, the safest starting point in designing an app is to research the people who will use it, the user types, also called Personas.

How do we study a user type? It’s like when you want to make a friend: the key thing is to identify with them. Identifying with your users may seem like an easy thing to do, but often you run the risk of allowing your own idea to prevail over the reality. If, for example, I need to develop an app that will be used by young people in the club, I’ll have a tough time succeeding if I haven’t been in that environment recently.

To help me step into users’ shoes, the method I use consists of putting together three different documents.

The first is called User Profiles, and it contains the description of the user types collected in the analysis mentioned above. The human characteristics of each type must be described, along with the problems to be addressed (pain) and the advantages you propose to offer through the app (gain).

The second document contains User Stories. For each user type, we need to tell a few stories that describe realistic situations in which the problems we’re aiming to solve occur, and how the app would have made life simpler.

The last document is the Business Model, which describes how the app will be sold. This part is important for the designer as well the accountant. In fact it’s the very functions of the apps that have to support the business model.

Writing these documents seems like a trivial task, but in practice it’s pretty complicated. But once it’s done, it’s far clearer what app we’re trying to make, and that’s the best time to mock it up.

In upcoming articles, I’d like to look deeper into these three documents to show you what information they contain and how they’re organized.

Andrea, what you describe is essential to not only the successful development, but the sales and usability of an app. Old school
Approach which still works for me is Use Cases – a UML appproach. It is not a quick task. The effort put into the design is reflected in the speed of development, and more importantly, reduced maintenance and changes.
I proved this looking after Architects. The ones who spent the time before a brick was laid had fewer problems than those who started building during the design phase. Prototyping is fine for conventional corporate systems, but I like your approach to mobile apps, both of which I am desinging to run from a corporate database of supplier information.
I do have an app idea which I have not seen anywhere else. Had quite a bit of interest. How should I get the details to you and what IPR do we need to resolve?

The approach I suggest is a bit different from UML practices, and in the coming weeks I’m going to explain it better by using some examples.

I’m glad you have such an innovative idea. If you’d like to talk to us to have our point of view on the best way to develop it, why don’t you send me a short description by e-mail? We can then make an appointment for a webex meeting. Of course, we will consider any content you will share as strictly confidential.