I am glad to welcome everyone whose hearts are crazy in love with interaction design and design in general. If you were scared by the huge amount of text, you can easily go to video mode. As for letterholics, I am glad to see them and suggest moving on.
I love my job, but most of all there is nothing like leading the project from the very beginning: to see how the idea is being born, how it is transformed, is being covered with limitations and overcomes them in order to get out of its cocoon with a beautiful butterfly-decision.
But despite all this, quite often, instead of designing a full cycle, you have to perform only a part of the work: either researching or transforming the idea into reality. So, if fate had it that someone else got the role of researchers in the project, there is a high probability that you will inherit a 200-page report, where “everything is sorted out”. Such a report is a detailed description of all-ranked problems (the guys would know better how to conduct research, wouldn’t they?). But the problem is: how to work with these reports? So crazy an idea is next-door to madness, in most cases they are abandoned dusty on the toilet bowl or on your hard drive.
And that’s a big problem, since these reports contain a huge amount of super-useful information that is simply not taken into account when making a solution. There is a huge gap between research and implementation.
Actually, this is what I would like to ponder over in this article, I mean the solution of this problem: how to build a bridge between research and prototyping coasts.
But looking into your eyes, I must admit: I have just deceived you, there is no gap and no bridge that is needed to build. In an ideal world, the phases of research and prototyping must begin at the same time and go hand in hand.
So, that’s all. There is nothing new here, so you can close the tab.
Well, now, when only the most persistent stayed, let’s think together — how? And if we know a lot about UX research from books and articles, there is far less information about prototyping, therefore I will look at the problem from this angle.
Prototyping is now much talked about: everyone says that you should always check your decisions, you shouldn’t immediately get down to visual design and so on and so forth. This is not entirely true: you can proceed immediately to visual design, and I’m sure that many designers (suppose that they are a vast majority) do in such a way. And there is nothing wrong with this, if your experience allows you to feel confident in the subject area and come up with right solutions for the first time.
But let’s take a step back and figure out what prototyping has in its original sense. Many of you, after reading up to this point, still draw a parallel “wireframing = prototyping”, although it might be a little misleading. Get ready, it’s high time for your world to turn over;)
Let’s move away from the usual idioms and clear our minds, be free from prejudices and stay open to everything new. Ready? And now let’s think, why do we need to prototype anything? I think it will be correct enough to say that we need this process to model solutions in view of their verification and improvement. Moreover, the modeled solution will be very ambiguous and shallow at first, but with each improvement iteration it will more and more resemble the final product. I dare say that there is a movement from something abstract to something specific.
Moreover, the more abstract is the matter we deal with, the faster we can make changes, and therefore, save even more time and money. Take for example, the wireframes — the correction of monochrome screens without graphics is clearly easier to edit in comparison with the established compositional solution. But why do we think wireframes are the starting point, zero of abstraction?
Let’s make it out. What is your favorite mobile application?
I’ve been using Lifesum lately! It’s a very good application to keep track of your gastronomic preferences. It immediately shows how many calories you can eat so far, breaks your diet into proteins, fats and carbohydrates. To add a dish is very simple — just tap on a floating button and start typing the name. And you shouldn’t worry about the wording: a lot of options created by the users themselves immediately fall out into the expanded list. Calories for a portion are also indicated there, which is quite convenient in calculations. After you add all the information, the advice on what you could eat more pops up, or, as in my case, “Where are you yet?” it is caviar(e) to the general.”
But why do I tell you about all that?
You probably realize what has just happened — using words, I made my thoughts take shape and afterwards gave them to you. In other words, I have just created a prototype, without using any graphic images. That’s what I‘m talking about, the level of abstraction and the speed of change is on such a level that it’s enough only to replace a couple of words, and here is a diet for a day instead of the list of products itself, or using geolocation the application determines the position where there is a cafe with tasty and healthy food. This kind of prototyping is called storyframe, when we tell a story about the interaction of the user with the application / site / service.
As you can guess from the title, the storyframe is the history of user interaction with the product. Usually, this history is framed in words and takes the form of a novel. Describing the use of my favorite app, I have already given an example of this technique. And I’m sure that many of you have already been using it, describing the desired behavior of users. Usually this happens at the kick-off stage or after the piloting survey, when you have already collected all (as it seems to you) the necessary information and the gears in your head have swirled, forming a blurred appearance of the new interaction. Many make up these thoughts with technical requirements, calling them User Stories. But!
A good storyframe differs from your imagination in that it is based on the mental model of users, in other words, how they imagine interaction, and not how you or the developers imagine it.
“Well, where is the research?”, you may ask. The point is that this type of prototyping can be used even during the research, it’s more accurate to say — you can start with it.
We usually start the research stage with different kinds of interviews: kick-off with customers, interviews with potential users, retrospective interviews, testing of “thinking out loud.” Meanwhile, the main focus of these conversations is the identification of problems and barriers users come across. Of course, having defined “where it hurts” we can diagnose more accurately and treat a symptom. But, why so few people ask about “How would you like it to work?” or “What do you think, how could we make the current functional better?”. And if such questions are aroused, only for a tick and they are not always transformed into something significant. The maximum they take is some individual cravings. Although you can get much more valuable information that will lead you to the right decision, and even may become it.
Of course, to trigger a user on a flight of fantasy can be quite difficult, especially when there is no experience in this matter. But do not despair, there is one interesting method that will help you to do it. I call it “The drooling unicorn.” The point is very simple. If you want to define the optimal process of interaction, during the interview you can say the following: “Okay, Tom, and now, let’s keep our mind away from your past experience and fly to the wonderland. Imagine that you see a magic service in front of you made from the saliva of a unicorn, it can do whatever you want and can solve any problem you have. How do you imagine working with it? What can it do? How? “And so on and so forth. Such a comic way helps the user to tune into unserious spirit to be able to suggest ideas that he would hesitate to say before that. This “magic” service helps to suggest solutions to problems that previously seemed unsolvable.
In any case, after the interview, you can get a draft of a storyframe. Why is it going to be a draft? Well, because users do not always know exactly what they want. As Henry Ford said, “If I asked people what they want, they would all ask for a quicker horse”. And Mr. Henry is absolutely right that no one knows the exact accomplishment of the user’s goal, but the main focus can be identified. If we applied our method, then the storyframe of Henry Ford would sound like this: The user sits in / on / between something to get to the right place, and does it very quickly 🙂
And here is a case from my experience. In EPAM, there is a special service which allows to collect a feedback, to learn your weak places and to work over them. It sounds like a good intention, but nobody liked it. Well, what could be the best solution to the problem than the redesign … It was successfully produced, moreover, quite quickly, but how well — no one knew.
Approximately half a year ago, I was asked the question: “Did it work out”? In short, the metrics were improved, but the attitude towards users remained unchanged. I decided to conduct an interview in order to get to the bottom of this, and at the same time to form a mental model of users using the method of the “Drooling unicorn”. As it turned out, users disliked not the service itself, but the process underlying it. That is, people regarded the feedback as a duty and forgot half of everything that needed to be reflected (feedback could be left only 2 times a year). Thus, users told me what they wanted, but they were very superficial and could not expose their thoughts to a specific visual solution, since they did not have the experience and skills.
Thus, after creating the foundation, we can impose technical limitations, business requirements and your experience on the pure mental model of the user to somewhere expand your history, and somewhere to fit it into the existing framework. The best way to do this will be by building a storyframe right into the persona or by creating a UJM.
If someone has ever made a so-called “personas”, then they should know how difficult it is to determine the criteria that will influence the design process: usually, this is a set of useless fields that cannot be relied upon in the design. I suggest the idea of embedding the field of the mental model, along with the most necessary motives, goals and tasks, in order to make this artifact as useful as possible.
As for UJM, this “baby” is already an updated storyframe. In our case, it looked like this. And with this you can already work;)
By the way, all these activities helped to convince the leadership of the need to review the process. So now, we generally went beyond the service and are developing a universal digital assistant, which will ask questions and collect feedback. And that’s all just because users said that they would like to communicate with a very clever friend …
But no one is perfect. Having super-abstraction is both a gift and a curse. Along with the speed of change, here comes one complexity that is not so clearly visible at first sight. Let me give an example: Imagine a dog … I’ll give you a few seconds to make it a bit overgrown with details. Are you ready? And now I ask you to describe what you see before your eyes: is it large? Small? Black? Redhead? Someone can see a sheepdog or a bulldog. I can see “@”.
Do you understand what I’m getting at? Due to the fact that storyframes are very subjective, they are useful only for generating the most successful solution, but are useless in testing, because everyone will see something of their “own” in them. Thus, I would not advise showing them to anyone besides yourself and the people with whom you have synchronized … brain waves. So let’s move on the path from the abstract amoeba to the clear decision. And next stop is paper prototyping.
May the bibliophiles forgive me for this term, because original “Paper prototyping” means precisely the process of creating something from paper. When you, for example, cut out an iPhone, fold it like an origami, and after that you scroll the screenshots through it like a film-strip. What is discussed below is called Sketches. Or, as I like to call them, “scribbles.”
Drawing something by hand on paper is a super-productive occupation. Many people miss this step, and in vain, because the moving immediately into the digital environment is fraught with immersion in pixelification, instead of creating a working concept. Moreover, everything is ready for a quick sketch: UJM literally begs to prototype him. Actually, there is nothing super-complicated here, no secret that the main thing is not to be afraid or embarrassed that you don’t know how to draw. You don’t need this skill here.
“Dot, dot, comma, dash, smiley face in a flash” — suppress your pedantic idealist inside and start doing everything crookedly and quickly. Remember the Paretto principle: 20% of efforts = 80% of the result, which is exactly what you need.
And so that you do not complex about your sketches, I’ll give an example of how this happens to me.
First of all, we subtract the story frame and determine the functional components required on the page, the cards, or whatever you want to sketch there. We define the weight of each element, e.i. the proportion of the user’s attention that you would like to pay to this element;
All the questions, ideas, alternatives, apps and restrictions are placed on the margins;
Satisfied? No? Go to step 3.
Everything seems to be fine, here we have created one screen, the second one and everything seems to be like “Uncover the Sketch and drive”, but I have to power your horses down. Let’s recall the research, during which the information architecture was created: you are likely to have some artifact, where it is reflected (UJM, User flow, Workflow or Sitemap), everything you find is suitable, and if there is a choice — stop on the Workflow diagram because it reflects all the user’s interactions with the system. If you don’t have anything like that, don’t worry. You just need to mould the image of the designer-researcher once again and create it yourself. It looks like that.
But what happens if we splice our sketches and the Workflow diagram? It is already done for us and the name to this chimera is already given: Microframes. Now there are a lot of libraries for this work, and you can use them in the digital environment. And at the same time, I attributed microframing to paper prototyping, because I prefer to do it on paper. The reason is again in saving time and avoiding the temptation to roll into pixelphilia.
The main difference between microframes and sketches is that they show transitions between states of the system. In addition, here all the kinds of little things, which are often forgotten, are very thoroughly worked out: pop-ups, notifications, tabs and so on. Thus, you test the system for isolation and the user’s ability to achieve their goals. And at the same time, this system is not devoid of shortcomings, and the most important of them, as well as with story frames, is the subjectivity of interpretation. Of course, here we transformed our words in more specific images, but this level of detailizarion is still not enough to adequately assess the solution. It’s all about our brain, because even when we draw, we unconsciously try to give the draft a finished look, distorting the shape, proportions and even the format of the data. Quite often, in fact, even the best ornated sketches in the digital environment become unrecognizably ugly.
For the same reason, I would not recommend testing on unprepared users at this stage, since you risk to throw out an excellent concept because of your subject’s subjective-nasal brain. So where you can start real testing on users is at the stage of … visual design, but for now, let’s talk about wireframing.
It’s easy to guess that this is the first stage of transforming your concept into the digital world. Our ideas are developing so fast … Wah. But why does wireframing stand out in relation to visual design? What are its differences from the finished design?
And to answer this question, let’s define what the wireframe consists of.
Typography, a monochrome color palette, areas and the simplest forms … That’s it. I deliberately did not include here visual metaphors (such as icons), the development of which can harm in the early stages. I immediately foresee the disgruntled exclamations and can say that wireframe is a very fluid artifact like ether. Sometimes I can not even blink an eye, as I already have a prepared visual solution. And at the same time, I recommend starting with these elementary particles.
That’s because at this stage there is no goal to create a black and white version of all screenshots, as many people believe. The task here is more to develop constant patterns of user interaction with the system, navigation solutions and the appropriate composition. It is more correct to say that here we start to work with the user attention, which is quite difficult itself, especially if we start drawing every little thing. It’s much better and faster to replace these graphical metaphors with areas of a certain color and size. So you firstly support the consistency of the system, and secondly, you can make changes with minimal efforts. Just remember that you need to name the area correctly, otherwise you forget what should be there 🙂
The loss of graphical metaphors on the stage of the wireframing will force a single tear to roll down your cheeks, but hey! But, as you could see, I put typography into the field of elementary particles instead of them. Yes, I advise you to start working with the text on first stages, since it depends on many things, such as the vertical rhythm, which in turn affects the composition.
Also, text blocks have their own weight on the page, which should be taken into account. And you can not just take and replace the text with gray rectangles, because the density of the font, leading and the length of lines can play a cruel joke with you.
And in order to minimize the risks of collapsing situations, I advise you firstly to start working with real data. Believe me — this simple advice will help you save a lot of time on related fixing.
And finally, for pudding, I’ll tell a little about the work with attention. As I said above, for this, in my view, there is a phase of the first approaching in the digital environment. I believe that at this stage we should lead a person along the way of interaction, distributing his attention on the page in the way we need.
Again, we should look at the artifacts obtained earlier: we need to know what is more important for the user on the page in order to prioritize correctly. For example, on the page of feedback writing we need to pay attention to the input field and submission forms, rather than to export in word. Such a simple example, and many make such a mistake very often.
By directing the flow of attention of a person, you choose something against the background of everything else, you create a “mountain”, the starting point. That’s the place from which the attention of the user goes down, to less essential elements. And this difference is going to be the contrast. I want to note that if we want to highlight everything, we won’t be able to create dynamics, just to “raise the plateau above the sea level.” So, it is a must for you to approach the process of creating a contrast very carefully and selectively. Moreover, it can be very different: size, saturation or brightness of the color, the distance from the other elements, and even the movement — it’s up to you. I’m only saying that you need to decide on where and how you will lead the user.
And once you’re done with it — you can start testing the attention flow. The moment where we do not even concentrate on the behavior, but simply observe if everything is going according to our plan, or we need to add contrast somewhere. Along with this step, you can start testing accessibility: how much areas are available for use and whether their purpose is easy to understand.
Thus, the connection between wireframing and research is in a competent allocation of attention, based on research insights, as well as in testing. Well, when the attention flows in the way you need it to go, it’s high time to add a few more variables!
Thusbeing quiet and unobtrusive, we got to the point that we know best — visual design. Unlike with wireframes, here are the colors, images and effects on the way.
The features that I would like to dwell on — all these extra decorations should serve some purpose. So it’s time to go back to the basics and come into synergy with space, so to say. In other words, with the purposes and features of users. And they can affect a lot.
For example, a mental model of a user may mean being in a certain emotional state at the time of interaction. And depending on this our color choice can either emphasize it, or vice versa, try to withdraw. In our feedback example, we found out that a person can be either furious or extremely happy to leave feedback on someone or something. Moreover, we can’t define yet what a person keeps on their mind, therefore we decided to stay neutral: not to annoy them evenmore and not to make fun of him, so as not to ruin the awe of delight. That’s why the interface turned out to be very-very laconic. In general, the entire visual language should go in synergy with the goals and user characteristics.
But this is not the only connection between visual design and research. Another one point of contact will be the process of testing.
A lot is already written about user testing usability, therefore I will not dwell on methods of retrospective interview, and if you wish, we can discuss it on the sidelines.
Now, I would like to talk about how to test your work. How can you understand that your decision made the interaction better? And here, as a superhero comes to us the research. And not a simple, but a heuristic one.
This type of analysis will be very relevant for the redesign of all kinds. Its essence is based on the fact that we need to determine the main indicator(s) of the effectiveness of the interface, measure them before and after the redesign. Thus everything comes down to the inequality “Before?” After.” That’s all. But don’t let the apparent simplicity bother you, because it is not easy to determine these indicators. Although now there are entire frameworks that you can rely on, for example 10 Nielsen-Norman heuristics groups or Ben Schneiderman’s universal heuristics applicable to any interfaces. As for me, I prefer to use the latter, because they do not depend on the context.
Here is a vivid example: vocation formalization. For this scenario, the speed of the application and the absence of mistakes will be more important for the user. Therefore, exactly the measurements of these indicators will need to be carried out. And if in your solution this scenario takes less time than the original one — I congratulate you, you have made the life of users better. And what about business? From this side, it is also worth considering your decision, adding to your user heuristics, also the KPI business. Conversion, if it sounds more familiar to you.
It can also be very difficult to determine: landing pages are simple — they generate leads, e.g. transitions or registrations, but with the product interfaces the matter can be a bit more confusing. Sometimes, the goals of users and businesses go toe-to-toe, but often it does not. For example, in our ASMT service, it is important for the user to get or to give a new title. Business wants the same, but it also gets information about how well these tasks are managed by employees. And they enter the rating, making it a mandatory step before completing the resume.
And in this case, KPI from the user’s point of view will be “How fast can I get or give a feedback”, and from the business point of view also “Get the rating of all roles”. Therefore, you need to measure how quickly users filled out the form and how often they put the grades. By comparing these parameters before and after we get a verdict.
Finally, I’m going to say that even at this step one should not become attached to one’s decisions, because they can be completely revised. I’ve already mentioned the example when, as a result of testing, all the heuristic metrics were fine, but the whole process could be improved. Therefore, be prepared for everything, even, to start all from scratch.
And if to be more unfolded, then …
1. Artifacts for the sake of artifacts themselves are useless,
2. It is necessary to prototype at the research stage,
3. Work with the team.
1. Words are faster than a mouse,
2. Torture the user until he gives out the mental model,
3. Use the benefits — change.
1. Get rid of your inner perfectionist,
2. Mix for a better understanding of the process (microframes),
3. Draw, crumple, throw, draw …
1. Alchemy only with a monochrome palette, text and areas,
2. Take care of the landscape, so that the attention flows in the way you need,
3. find a friend with thick fingers (test for availability).
1. Think about it, and then make decisions,
2. Check for yourself (KPI test),
3. Be ready to start from scratch.
I decided that those people who read this huge long-read are too interested in their own development to leave them without further steps. And I’m a little afraid of your patience … So, here’s a little material for further more in-depth acquaintance.
As a small bonus, I’ll add a link to Vanilla Time — my quiet channel in Telegram. No spam, only links to selected materials and short descriptions to them.
Thank you so much for your attention. If you have any questions, do not hesitate to write to me and ask them. I really want to answer them.
Be happy, healthy and rosy-cheeked, and I wish you the ship of love, driven by the winds of inspiration.