📜 ⬆️ ⬇️

Analysis of the design methodology: errors, situations and useful conclusions from them

Last time I wrote an article about designing in 2011. Then I was going to write much more, but I thought: “There is a technique, but it is not tested by time, clients and projects. What devil will I write about her? " And he did not. Two years have passed, for which we have designed about fifty different projects with the team: corporate websites and product catalogs, private offices, management systems, services, landing pages, mobile applications. Much has changed: I have statistics, conversion data, user and customer reviews, and a lot of errors in the methodology and process have been made and corrected. Now you can write.

I will begin by reviewing these errors and conclusions for the last two years. I hope this will be useful for you. Separately, I hope to receive feedback from your personal experience.

Speak as much as you can with the client during the information gathering phase.


I shared (and partially share now) the view that the client often leads projects that are incompetent or unprepared for this, but this does not mean that they do not need to talk to them. No one has more information about the client’s business / project than he himself; even if he is a marketer, describing his audience as "25-50 years old, men."
')
By asking the right questions, you can learn a lot of useful things for design. Then, when you tell your conclusions to the client, he will be very grateful and will use them in his work (if not a fool).

Put the responsibility for completeness and quality of information collection on the client.


In no case do not take this responsibility on yourself, if you do not have a staff of researchers and analysts like Gallup. Since we are merely designers, we must analyze and interpret; In any case, the client knows more than us: he has data, statistics, materials, experts, clients.

Putting responsibility on the client, you are doing the right thing, not because you take it off yourself, but because the client, by definition, is more interested in you, so that you get the most useful information and draw the right conclusions. So let him provide it, and you will think and make decisions. The architect of the business center does not measure the soil and does not analyze the flow of potential customers, right?

UPD: This item does not mean that we turn off from the process of collecting information! On the contrary, we “torture” the client and all his employees who can tell us something useful, provide materials, statistics, and so on. Usually, at the stage of collecting information, the client gets tired most of all because he has to answer my questions and requests for materials every single day.

Marketing, positioning - completely customer responsibility


I naively believed that I could tell the client something about positioning, and it would make sense. Yes, I can tell, but more often it is: a) not accepted by the client, because he “knows better”; b) stupidity, because the client really knows better.

I realized that the best thing I can do is to help the client to formulate the positioning, but not to correct it and, moreover, to create it. In the end, this is his business, and let everyone do their own thing and bear their responsibility.

Put the client in an awkward / difficult position


At the information gathering stage, inconvenient (even impolite) questions proved to be extremely effective. For example:

It's amazing how well the head of the client starts working at this moment. It's a shame and I want to fix everything as soon as possible?

Sketches needed!


This is one of the main conclusions that I made for myself. They help you to understand and think out the logic and content yourself, to the client, to understand what you offer, and to the designer to understand what to do. Words, many words, mindmaps - this all works poorly without visualization.

I had a hypothesis that the sketches cut off the flight of the designer’s thoughts, limit it to what he sees, and force the client to treat the design as a sketch coloring. Fortunately, this is often not the case, but a lot depends on the quality of the sketch and its presentation. The sketch must be a sketch, ie:

Separately, I want to say about fashionable interactive prototypes. Our experience says: an interactive prototype in 99% of projects is a waste of time. He doesn’t add much understanding, but it takes much more time to create and edit. In addition, it does not meet the requirement of “looking like a draft”, because it is too collapsible.

In the sketches, work out the logic, not the appearance


This is an extremely important remark, because I saw a mistake of “formalizing” my colleagues and made it myself. The emphasis on logic allows:

In no case do not give the logic completely to the designer (I made this mistake repeatedly, unfortunately). Yes, he is an expert in interfaces and design, but you know the logic of the project and the characteristics of users (characters) better. And you know what to select, what formulations will be more understandable, and so on. Let everyone do their own thing.

What I just said does not mean that you should not listen to the designer. It is even necessary, but it should not determine the logic of the project - only to correct mistakes and help to do better.

Describe logic after sketches.


Yes, I used to think that it was necessary to describe all the logic, and then make sketches for it. Now I realized that these processes are going on in parallel, and it is better to first identify key points (concept, general structure), work out the details in the sketches, and then describe it all.

The same goes for scripts. Designing detailed scenarios for the structure and sketches did not give (me) visible positive results, so now I throw in general scenarios showing how the user thinks, and then I make a description of specific scenarios of his behavior using ready-made sketches. Why is it good? Because the general course of thought of the user helps to determine the structure, communication and accents in the interface, and scripts written from sketches help to check your decisions in action.

Test sketches


Show sketches to potential users with whom you interviewed at the information gathering stage, and check your decisions for completeness and consistency of information. This is not a site yet, there is no interactive in the sketches, but they still help to see if the information organization is understandable to the user, the language you speak with him, further actions (targeted).

Designing together is best


Designing alone deprives you of a valuable view from the side (the client does not always help, because it is extremely passive and is waiting for the first pictures). Designing the three of us is a swan, a crayfish and a pike . But the design together allows us to look at the task from different angles, argue constructively and back up, if that.

It is best to combine designers of slightly different styles — for example, those who perfectly design communication / content and are more likely to work with interfaces. If you try to reduce the very different, do not agree.

Get understanding from the client


Make sure the client understands all the important decisions (not necessarily made). The concept, each idea and sketch needs to be explained, not just sent out, and after waiting for a reaction like “yes, everything is fine” or a few incomprehensible edits, it is easier to take a breath and move on to another task. Most of the clients (so far) have not encountered design and do not understand its meaning and significance, which cannot be blamed. You have made a concept - put it into a simple presentation and personally, or, in extreme cases, via Skype, present it with detailed explanations why it was done this way and not otherwise. Also with sketches.

This will save everyone time and nerves, more likely to achieve understanding and agreement on the right decisions. If you do not do this, you will be re-designing, but already at the stage of creating a design or, even worse, programming. Minus money, time and reputation , because you are to blame.

Do not ship customer technical information


Try to turn technical descriptions into human-readable. Instead of “CMS contains the functionality for editing the“ News ”entity with the following fields: 1) title, 2) description ...” write “The control panel should allow editing the title and content of the news”. So you will gain more understanding and less irritation; the words “desription” and “title” do not at all show your professionalism, as many think, but simply besyat.

Do not torture women


I don’t know exactly why, but women managers suffer less from the painstaking design process when you make them check every word in the description of logic and every element of the interface. But they have many other advantages: constructiveness, a desire to find a common language, less self-indulgence and stubbornness (he listed not everything clearly).

Is this contrary to the “Understand” item? Yes. But my experience has shown that the benefits of torturing a client are like a goat of milk: the brain of our dear client turns off and starts reacting absolutely inadequately. So if you start designing with a woman on the other side, be prepared to take responsibility for the decisions on yourself.

Make sure the client is able to implement the solutions.


In the project, you can think of anything - a video presentation, a cool recommendation system, analytics of user actions in 56 sections. But what's the point if the client does not have the time and resources to do this? When proposing solutions, be sure to verify that the client will be able to implement and support them .

This even applies to banal news: if they appear at the client every six months, then you don’t need to put a “News” section into the project with the output of the tape to the main page, right? Or if the client does not have a good writer, then it’s somewhat naive to make the blog / article core of the project.

Make recommendations for creating content.


Even if the client has the ability and resources to create and maintain the content you have planned - a blog, news, event reports - give him recommendations on how to do it: tasks, size, content, style. In their absence, the client will write the devil knows what (I will not give examples, because it is incorrect).

Do not do more than two projects at the same time.


One project is good because you can dive and meditate. Two projects - not bad, because more money. With three or more projects at the same time, efficiency drops sharply, wild porridge appears in the head, elements of another appear on the sketches of one site, and so on. The brain does not seem to be able to process so much different information in one way.

Take to work "the same" projects, but not at the same time


The projects that are identical at first glance, when correctly applied, are almost always different: in communication, business processes, and content. Feel free to tell the client that for him a big plus is that you designed the site to its competitor. But never do such projects at the same time: you will not go anywhere - you will offer the same solutions.

Decisive "No!" To the client designer


Under no circumstances - with the exception of a million dollar fee - do not enter the development with a client who, at the design stage, shows himself a tyrant and “versed in design”: he says that it would be nice to move the logo 2 cm in the sketch and make it bigger or requires "make the interface as in Windows 8".

If at the design stage, where there is more logic and common sense than in design, he does this, imagine what will happen when you show him the first design layout.

findings


Articles made to draw conclusions. I have one and quite obvious: never think that you are doing everything right, notice, acknowledge, analyze and correct your mistakes.

In the next article I will offer a quick and efficient way to make a concept (of a site or service). I deliberately skip the stage of collecting information, because almost everything is said about him here: habrahabr.ru/company/kelnik/blog/155003 .

Source: https://habr.com/ru/post/168191/


All Articles