Usability testing should start as soon as possible in the process is fundamental, and everyone knows it. It’s incredibly crucial to identify the problem in the initial phase before starting with development. Most testing should happen with mock-ups and prototypes, whether low-fidelity prototypes or high-fidelity interactive prototypes in later stages.

Low fidelity prototypes are great because they focus on the concept and functionality rather than on the details – which are better handled in one of the subsequent phases of the design process. The other advantage is that they also take less time, which means it’s straightforward to correct the mistakes and improve.

Spotting the problem early in the design process is cost-effective as developers’ work is costly, and you don’t want them to spend their time fixing the imperfections. And besides, it would be very expensive to redesign, refactor the code and finally make sure that it works correctly.

It’s well known that developers don’t like to see the changes been made in a design. They feel like they are doing unnecessary work repeatedly, which should be easily avoided in the first place. And I agree with that as well. To fail quickly and early in the process is the key to a good project!

The fact is that everybody should attend usability testing sessions, not just designers and developers. Project managers, product owners, business analysts, the entire team should be present to see, hear and feel when the user succeeds or fails in completing the given scenario.

Here are 4 reasons why I think developers should attend the usability testing sessions:

1.  Understanding the user

When testing with users, we always prompt participants to think aloud and let us know how they feel when they are, e.g., completing the form, uploading the document, sending a message, etc. We want to know their expectations when clicking the button, their feelings when the action happens, and what they would change if they can.

When developers are there, they can understand the problem better (if it exists) and see what that means for a user. For example, they might think that a particular feature, a button size, or position is not so important. Still, if a user cannot find a way to send a message because the button position is not in the place they expect it to be, they will struggle, lose patience, and, in the end, have a terrible experience.

2. Generating new ideas

Another reason developers should attend usability sessions would be the ideas they can generate by observing the users. For example, we had a situation when we presented a prototype form to our users with an assignment to fill it as they were applying. The feedback was great on the entire user interface and functionality; the form had a conversational approach and was very simple to use. We had only one question per screen, and they could focus easily.

The only complaint they had was around the speed of the transition between screens. Three out of five users said it was too fast, and they didn’t even notice they were on the next screen.

In the same session, one of our developers suggested slowing down the transition between the pages. He also pointed out that we can add a button animation, ripple effect, or similar, so they have feedback when they click. It doesn’t require a lot of work, but it gives a lot of value.It was a great experience because we all felt like a good team, all of us working together and for the same goal – build things that our customers will use without any difficulties.

3. Understanding the rationale behind every decision

Sometimes developers don’t completely understand the reason behind the designer’s request, which can also be avoided by including them in usability testing sessions. At some point, they might think there is no sense in building the specific feature because it won’t bring value, or it’s too similar to the existing one.

However, when developers hear the real reason from the actual users and their feelings and thoughts, they can put themselves in their shoes and figure out with the designer what’s the best solution to make the best experience for a user.

For example, we had a similar situation on the previous project when one of the developers didn’t see the difference between using the appropriate keyboard for email input and the default one. I asked him to join us on the next usability testing session, where we tested an entire end-to-end flow.He was a bit skeptical at first, which is always expected when people attend the sessions for the first time. Then we started with the first participant, and we got the feedback straight away! Users don’t like extra clicks – users hate extra clicks. Every time they tried to type in their email address, they had to switch between keyboards, look for the “@” sign, and then again to put “.com.”

This feedback was enough for my colleague developer to understand he was wrong and see the importance of using the proper keyboard and its meaning for our users. He also became more conscious about the future requests made by designers and gave more importance to them because he knew that we don’t ask for anything without a specific reason behind it.

4. Including developers in design decisions

In the end, we all know that it’s all about the users. It’s all about making them happy and careless when using our program, app, or service. We can avoid a bad user experience from the start, and usability testing is the right way to go if you want to skip that part. You don’t want to end up having a final product that has terrible reviews, and people hate it. Having designers and developers included in usability testing in the early stage means resolving many things in advance, as developers can give us great feedback from the technical side.

For example, imagine the scenario where a business decides to have a specific feature in the task app, a separate count of the tasks marked as “Done” and “To-Do” ones. The designer does his part of the job, designs it, and puts it in front of the user. In this case, let’s say that our users don’t react to the feature; in fact, they don’t even notice that it’s there. The developer, in that case, can give us feedback from the technical side and say: “Well, from my perspective, this requires a lot of work. I’m going to spend five days building this feature. On the other side, we can see now that the user doesn’t even notice this feature nor appreciates it. Let’s try to propose something that requires less work and adds more value to the customer.”

And that’s exactly what you need. Get the feedback from a user and from the technical side in the real-time and all at once. It helps us make better decisions and act faster because time is precious, and there is no sense in wasting it if we can use it better!

 

The most important thing that I would like to highlight here is that if developers attend usability testing from the very start, this would ultimately affect how they work. They would be more eager to fix the problems when they feel compassion for the user. It gives a lot more meaning to their work.

It’s pretty different to do something without knowing the reason why you do it; it’s like tapping in the dark and using no brain or whatsoever. Instead, on the other side, you see the entire story behind every single designed screen; why in that particular order, and why is it made that way. Behind every “Why?” there is a proper “Because,” supported with user’s actions, positive and negative feedback, and the good and bad experiences they previously had.

So, yeah! Invite your developers to join you on usability testing sessions. It helped us a lot in our projects, and it helped them as well because now they have a different approach to their work. And in the end, it’s all about collaboration and teamwork!