Speak first, Code later (don’t shoot the messenger)



User research is a great thing.

Human Centred Design is the best approach possible (at this very moment) to create new products, no matters if you’re designing an app, a rangefinder camera or an office.

The principle of designing something around the ones who will use it, considering the cognitive processes involved in the everyday use gives the team the opportunity to build up products that will not make users frustrated and/or angry.

Research is of paramount importance in this process.

The problem is that research alone is quite useless .

if not followed by a “translation” of the results into solutions.

There are, inside the UX field, two phases, Research and Design.

Theoretically the design cycle is made of both research and analysis/design.

Research – such as contextual research, competitors benchmarking, user interviews, ethnological approach, task analysis, interview, A/B testing etc. – is the first phase. Personally I prefer to observe the user doing something in order to see what he can’t say, because people usually blame themselves if they cannot succeed in doing something or if they take too much time, or they feel uncomfortable in describing some difficulties they may have. The most difficult task is to convince the user that we’re testing the product, not him/her.

I’ve been at a Fair at the National Exhibition Centre in Birmingham. In order to enter the fair a long and detailed subscription form needed to be fulfil. Once completed the form, the system gave a PDF badge to print and sent an email with an activation code for the badge.

Once at the fair I’ve tried to activate my badge. There was a computer connected with a barcode reader and a printer. On the screen there was a kind request to digit the customer code. Problem was that I had an “activation code” and a code without any label on the badge. No customer code. I wrote the latter, it didn’t work. I’ve tried the first and it worked. Soon after there was another request for the activation code. Did I have to digit the same code? I did it, but it didn’t work again. Neither the other code worked. I’ve tried to scan the barcode on my badge, with no results.

I’ve spent half an hour trying to activate my badge without any luck, fortunately a gentle lady helped me by bypassing the system and activating my badge as administrator.

The point is that I was frustrated and ashamed, even if I can clearly see what was wrong – the lack of feedback, misleading and too few information, overcomplicated procedures etc. – I started asking myself why I was not able to activate my badge. Even if I was able to see that the system was badly designed, I started blaming myself. And I know the trick.  When the lovely lady told me that she spent the whole morning activating badges for people unable to do it, I finally got it.

Analysis and design – such as heuristic evaluation, task analysis, user observation, sketches, wireframe, mockups and prototypes – is the other phase.

Coding is not part of UX core skillset, we need to have a good knowledge about coding in order to deal with developers, but that’s all, the reason is simple, to code properly is a complex job and require a lot of time and knowledge, to design something is another complex job and require a lot time and knowledge too, if you want to do both by yourself, you’ll require an enormous amount of time and, more important, an enormous amount of knowledges, and the two knowledges are not overlapping.

The two parts should be performed together because they are part of the same process, they have the same purpose, from two different perspective. Or, better, they are different steps of the same path.

Nowadays we’re more specialized, so there are Researchers and Designers, and they should work together.

Basically in the ideal world the researchers collect data (seems simple, it’s not!) while designers observe, than they discuss and analyse the collected data, and the designer should solve problems, of course always with the support of the researcher then the solution will be tested again.

I’ve often seen a strange phenomenon, consisting in a lot of research, fast sketching on a piece of paper of possible solutions (very low end) and that’s all. It will be coded and the resulting prototypes will be tested again (same panel) and the iterative process will go on.

There is a missing piece. If you say “users have problem with X” doesn’t mean that you can win just giving a different shape to “X” or eliminating it.

It’s not only important what users do, but also why.

Given the importance of this point I’ll back on it in a dedicated post.

The problem is not if the user have done a “mistake”, but why the user have done that mistake, looking for the roots of the problem. Probably a better design could have avoided it.

It’s always important to remember that design is communication, we are trying to make a human being and a machine talk to each other so, if this communication doesn’t work, we should act on the machine, not on the user.

You should understand where “X” is weak and why, it’s possible to use a lot of tools, such as heuristic evaluation, paper mockups testing, prototypes testing , you can also test wireframes, all techniques cheaper and faster rather than perfectly working prototypes that make people confused.


paper mockup


You should not only ask, you should also read actions and reactions, and translate what you read in designs that prompt different series of actions and reactions from the user.

I’ve heard stuff like “23% of the panel have problems with the menu, so we must change the menu” (meaning a different typology of menu was adopted soon after). But did they ask why the previous one was difficult for 23% of the users? All of them had the same problems? And what about the 67% who had no problem? Where was the bottleneck?

The iterative process proved to be really successful, especially when all the involved parts works together (from stakeholders to project managers, to designers and coders), but all the steps are equally important.

People are not numbers, and conventions are more powerful than logic.

For example, we currently use a floppy disk icon for the action “save”, even if great part of the users – the younger – have never used a floppy disk in their own life. Probably most of them have never seen a floppy but as icon. However, changing this icon with something more “logic” could lead to confusion and errors, because it’s a convention now.

Everybody knows that sign means “save”. Why should they learn a different one? What could be the reward?

The interaction between Human being and machines (whatever they are) are complex and if the approach “code first, speak later” is turned in “Speak first, code later”,  probably the length of the project will finally match deadlines, users will be happier, projects will match the desired scope and, last but not least, a lot or resources will be saved.

In the best case scenario of course.