How to design an app
First comes the need. Your own maybe or someone’s else. The need to be not disturbed by the information inflow when you are really busy. I felt it myself. Then asked people around me. Collegues, friends. nearly everyone described his/her workarounds to escape from this distracting continious stream of who, what, when and why.
Then an idea appear. What if give users an instrument to regulate this flow? Then came a question: how to? The way to find out the answer: let’s observe and let’s imagine!
What do my friends do to manage the information coming from the global cyberspace when they are busy? Actually, they screen themselves from it in one or another way. They ban social network sites, switch of ring on the phone. They delete chatting software from their computers as well as their mobiles (and then install back when the deadline time is in the past).
So what if give them an instrument to manage messages, notifications, invitations and events in less aggressive way? Make so that they wouldn’t need to remove talkative software? Give a magic button that can help switch the phone mode from “show all notifications” to “no notifications” and back?
All or nothing approach is something but it is not all. Users may want to get some notifications inspite they are busy. Or not to get some notifications even if they are free. So they would need a tool to set up this filtering instrument according to their needs and wants. What settings would the need?
Let’s check the hypothesis: users want an opportunity to filter messages from all their applications. Texts, comment on social networks, notifications from calendar, chats, e-mail and more. It seems to be a good hypothesis to start with. But should these settings look like? And how should we separate settings for different modes from each other? Tabs? Lists? Switches?
And then another chunk of quistions: What is more convenient: to show all settings in one list, grouped according to the app, that they influence, or show the list of apps first, making user to tap on each app name to check settings for it.
This was a point where experts who did heuristic evaluation step in. Compactness is sacrifised for ease of access and clearness. Users SHOULD view all settings at once.
One more stumbling block was the colour scheme choise. Colour is a statement, colour is expression. So what colour to choose? I fixed upon the light purple. This colour seemed to be strict enough and still it is not black and while. I’ve done the app interface in light purple but again and again I reconsider the idea of changing colour scheme.
When the prototype was to some 70% done, testing process was started. Testing is the process where a prototype (theoretical construction and its realization) meets real users. Real users have habits, believes, likea and dislikes. They have their own ideas of what is good and what is not. They create hypotheses how your proposed app should work (and they don’t ask you whether they are right or not). And, what is very important, they can do the same task in several different ways, some of which you couldn’t even imagine!
NotMan has a synchronization function which is intended to help user set up all things once and then to distribute them to his/her other electronic devices (all or any). The concept seems to be easy; the realization — even easier (special page for flexible synchranization in special cases and just one button to synchronize all settings with all user’s devices situated on the main page). But the testing process showed that there were some problems in using this simple design.
First, the button on the main page. Some testers expected that the button would bring them to the Synchronization page. Others got the idea of its behaviour, but didn’t expect that the synchronization would start at once, without any additional warning. I believe that I managed to solve the problem by adding a warning dialog that is shown to the users after they press the button. But what I really loved this situation for is that it showed me how people interpret the same ideas (or the same set of words, icons and buttons) in completely different ways. It was just one example of it — and I guess that if I dig deeper, there would be more such situations.
Testing (especially, testing in person) helps to uncover such situations. Online testing is different. Particularly, if a lot of participants take part in it, two versions of the same page and an instrument to organize A/B testing. A/B testing is really funny. In the A version half of the testers clicked tle left button, and the rest clicked the right one. You don’t know why, but you observe a trend. In the B version all but a few participants used the left button and — though you still have to find out why — you see different trend. the trend may me statistically significamt or not (you have statistics to analyse the data), but this feel of a trend, a tendency — it is puzzling and attractive.
Like the rest of the interaction designing process.