In recent weeks I’ve tried to highlight the challenges that designing an app poses, especially for those of us who have already developed a lot of business software. To get off to the right start, we can do ourselves a favor by writing a few specific documents before starting the mockup.

In this article I’ll show you a practical example of the first of these documents, the User Profile, which describes the characteristics of the users of the application, their problems (pain) and how the app could help overcome them (gain).

Since I like to talk in practical terms, I thought of a common problem that a lot of people encounter in everyday life, and I tried to see if I could fix it by developing an app. The result is ToBuy, the best app for family shopping.

These are the best cases, because describing the characteristics of the typical user of the app is easy: simply consider your own experience. Other cases require a more complicated process of identifying with users, which in turn requires an initial phase to research and directly understand the categories of users that interest us. This is in fact the only way that we can understand who our future users are and what they actually want (the personas I mentioned in the previous article in this series).

But let’s get back to our shopping problem. Not all shopping is the same; in this case the solution focuses especially on people shopping for their families. So, what characteristics does a typical user have and how do they perform this task?

  1. Men and women of working age, with partners and children living at home, usually shop for the entire family at the same supermarket on the weekend. That means they have a long list of items (40-50 rows) in many different product categories.
  2. The list is written on a piece of paper before going shopping, working from another paper list of approximately 100 frequently purchased items. The list-making process is slow and relatively disorganized, so it’s not easy to keep track of the order that the merchandise is displayed in the supermarket.
  3. While shopping, users struggle to figure out what they need on each shelf, and they have to keep checking the list to see what’s left. Since it’s written on paper, users can’t even check off the list, so it’s hard to know if they’ve already bought everything.
  4. Users aren’t shopping just for themselves, so the list can even change while they’re shopping, usually as a result of a text to their phone, and of course there’s no guarantee that the shoppers will see that text. Also, users can’t make changes to the paper list, so they need to remember to add whatever was requested via text.
  5. If during the week family members notice that a certain item has nearly run out, the user and his or her family have to find a shared way to make note of this and then to remember it when making the list.
  6. For some types of items, like detergents, it can be hard to find the right one. It would clearly be very helpful if you could see a photo of the product.
  7. People may also go shopping with other family members. In this case, it’s very difficult to work as a team, because no one knows who has purchased what.

If you’ve read through this whole list, it’s now easier to picture an app that optimizes this specific process. Otherwise, any analysis of the app would have been generic, and maybe not suited to any actual type of shopping.

That can happen often: if you go to the app stores and download the shopping list apps, you’ll see that no one has been able to make it truly efficient for people who shop the way I described above. And that’s why I had to develop ToBuy!

Next week I’ll continue with an example of the second preliminary document: User Stories. In the meanwhile, if any of you would like to try writing a User Profile for me to read, I’d be happy to!


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.

If you get a great idea for an app to develop in the meantime, I’m here to talk about it.


In recent weeks I’ve had the opportunity to help a few members of the Instant Developer community set up projects using the Cloud edition, working from their own app ideas. It was a very interesting experience because it helped me understand what obstacles must be overcome for people who have already developed a lot of software and now want to tackle apps.

Naturally, we approach a new world using the criteria we already know, and people who develop software for a living are therefore tempted to reduce the problem to the technological level, thinking that the solution for creating an app is to learn to use new languages, new frameworks, and new platforms.

What’s the problem with this approach? That there are crucial differences between classic applications and apps that are difficult to detect at first glance; only by understanding them fully can we create apps able to bring the proper substance to the many great ideas I’ve seen.

But what are these differences? I think they can be summed up in three main points.

The first and most essential difference is that apps are not general purpose containers that let you do a little bit of everything. Instead, they run specific and carefully characterized processes. So, a very important rule to keep in mind is to always focus the app.

The second difference is that apps are software as a service. No one will ever be tasked with physically installing the apps on the devices: users do this themselves. And no one expects to attend a training course to learn how to use an app, because it’s operation should be natural.

The third difference is that apps have to offer a state-of-the-art user experience. And today, the state of the art is very, very advanced: professional graphics, real-time operation, and support for native device characteristics are the minimum requirements for keeping up with the competition.

Those people who, like many of us, have already developed a great deal of software, use different criteria: they analyze, develop, and test with a method that doesn’t usually take these differences into consideration. What can help is to set aside the technological aspect until later, and begin with a product design phase.

I’m not trying to steal any work from professional designers here; they are definitely crucial in complex cases. But I do think that there is a basic level that’s within everyone’s reach, and it’s often enough to create prototypes that hit the mark.

In upcoming articles I’d like to go into detail and see how we have handled this basic level in the cases I’ve had the chance to be involved with, so I can present you with a method that might work for everyone.

Would you be interested? Have you ever faced this level of design in building software?

Image: Roberta

{ 1 comment }

We’re well into September, and it’s time to start up with the iceberg again. Now that the weather has cooled a bit, we’re ready to be with you every week.

We’ll start right away with some excellent news for our whole Community: as of September 12th, Instant Developer Foundation is fully compatible with iOS10.

That makes release 15.0 r3 a very important update. We all know that with every new release, apps have to be updated and sent to the app store again in order to be fully compatible with the most recent mobile OS from Apple. As usual, for all the developers in our Community, preparing for publication is extremely straightforward: simply upgrade to 15.0 r3, recompile the apps, and that’s it.

I have to say that once again the company from Cupertino really gave Luca and his team in production plenty to do. As they told me, they had to tease out a variety of problems that still had little documentation (inevitably, I’d say), which made them even harder to resolve because often developer forums are no help either (and Apple support even less so…).

So it was a tough job for the tech department, which is a clear example of the value you can get from our maintenance service. In fact, since September 13, the official iOS10 release date, users have been updating devices, and it’s to be expected (or rather, it’s been shown) that within just a few days a significant percentage of people who use your iOS apps have the new operating system on their devices: so it’s crucial to be ready right away.

Don’t waste any time. Upgrade to 15.0 r3, recompile, republish, and don’t worry about it from there. We’ll take care of issues with the updates.

I mean, in the end that’s what we’re here for, right?


Bootstrap + Foundation: watch the preview


A few months ago we announced that the most important innovation for Instant Developer Foundation this year will be the new rendering engine based on Bootstrap. Since we’ve talked about Instant Developer Cloud a lot recently, you might think we’ve forgotten about that promise, but the project is moving along quickly toward release in version [...]

Read the full article →

Offline and synchronization with Instant Developer Cloud


This week’s article will bring us to the end of the interactive tour that has been teaching us how to develop apps with Instant Developer Cloud. And like the best action films, the most thrilling part has been saved for last. People who develop apps know that you can’t count on internet connections that are [...]

Read the full article →

Using native plugins


After the break last week when we saw how to configure Cloud Connectors, we’ll pick up again with our learning tour of Instant Developer Cloud, exploring how to use the native functions of smartphones and tablets and how to test the application directly on the devices. Instant Developer Cloud, like the Foundation edition, uses a [...]

Read the full article →

How do I install a Cloud Connector?


Many programmers have asked us recently to start developing projects with Instant Developer Cloud working from closed databases in private networks, and thus not accessible from the Cloud. A solution to this problem exists, and it’s called Cloud Connector, a software agent that’s installed near the database to be published. It permits safe, high-performance access [...]

Read the full article →

How to connect the front end to the back end


In the last few weeks, we’ve seen how to create a document-based Back End with Instant Developer Cloud and how to build the Front End views. The final step is to connect them, and this is a delicate subject because it affects both the security and performance of the application. People who use Instant Developer [...]

Read the full article →

How were the TripTrak pages built?


The success of an app depends on the type of user experience it offers. Designing attractive, responsive, and animated pages is crucial to a state-of-the-art user experience. How was all this tackled in TripTrak? The interactive tour I want to offer you today answers that very question. This is perhaps the part of Instant Developer [...]

Read the full article →