Behind the Scenes of Product Development

Similarly to the argument about designer job titles, it’s a never-ending discussion if designers should or shouldn’t code. For starters, we’re talking about fundamentally different mindsets. While developers think more in technical process flows, designers are focused on series of actions performed by users, as their purpose is to come up with a solution to customer problems.

Therefore, product designers (or UX designers, but as I mentioned before, I’m not a fan of that title) usually don’t do any coding, simply because the activities we’re engaged in are full-time responsibility. As this Twitter thread also shows, most of a designer’s work is actually not even building graphical user interfaces, but doing a lot of communication and research. 🔍

Houston, We Have a Problem

Usually, when I get in the picture the process has already started. Our product manager comes to me with a problem to find a solution to. There are several ways to define problems, like assumptions made from data analysis or competitor activity; technical improvements giving us more space; or direct requests from our customers.

The first — and most important — step is understanding the problem. Let’s say we’re staring at our analytics and see users are dropping off at a certain point of a flow, abandoning it without finishing a task. The question is: why? Before you give a solution, you need to figure out what you are about to solve. You need to understand the motivations, goals, needs and how your users currently solve the problem.

Ideas coming directly from your customers can be really good improvements to your system, but you need to be cautious. The bigger your system is, the bigger the chance your users won’t know everything about it, which can lead to false assumptions. There might be “hidden” details which they’re not aware of but if they were, they would ask a much different thing. The user’s belief of the system in hand is called the mental model. It simply means they believe they can or cannot do something with your tool, based on their current knowledge of it. The mental model can change through education or experience, so before you jump into coding, you might care to understand why they want that specific thing. Maybe the solution is not what they ask for, but you can give them a much better one.

There are several methods to gather information about the why, and two of my favorites are surveys and interviews. You can collect some high level questions which you would ask from all of your audience, and send out a form. It’s not always easy to find the best platform for your questionnaire: while one channel could get you tons of answers, another one will be a dead-end.

Timing is also important: you should be aware of the schedule of your audience. They won’t have time or energy to help you when they’re too busy, or not even working. There are many more tips for good surveys, but the point is you need to be patient, trying out several ways to reach out to your audience ‘till you find the best for your case.

Real Connection to Your Users: User Interviews

Another practice I love is doing user interviews. It’s what it sounds like: you sit down with your users (preferably 1-on-1) and talk to them. You need to prepare questions again, but while surveys help you to understand a little of a lot of things, an interview will help you cover only a few, but more deeply. It’s important to have an actual conversation instead of interrogating your customers: the questions you collected are the base of the interview, but as your customers answer you can go sideways or even completely hijack the discussion (as long as you talk about the problem which you both want to solve).

It helps if you bring a note-taker with you, so you can fully concentrate on the conversation while your partner writes down the most important takeaways. If your customer agrees, you can record the interview, so you can listen to it later and write your own notes. 🗒

It’s important to observe a wide range of your users, especially if you have several kinds of users in groups. If you focus only on one group, you’ll probably satisfy the needs of that couple of people, turning your back on the others.

When I have a satisfying amount of answers to our questions, I can start the actual “design” work by creating sketches, or basic mockups. At this point I don’t focus that much on the outlook or precision, I just try to build some visual support to my ideas. Sometimes I don’t even build the whole feature or page, just a specific part, like a complex controller, a modal, a form, whatever. I also try to come up with 2-3 concepts at least. It will help me to communicate my ideas to the team: that’s where I involve developers, because the next step is understanding the technical constraints. It doesn’t matter if I figured out the best-ever UI element for our users if we’re not capable of building it, of course.

After collecting all the information we needed — must-haves from our users, constraints from our developers, and possibly other factors like design, a11y and consistency guidelines etc. — our focus is much narrower. This is where I start to work on the pixel-perfect UI. I create clickable prototypes, so I can give a snapshot to the team of how the actual software should look and work like, and much more importantly they will be the core of usability tests: yep, we’re going back to our users.

Introduction to Usability Testing

User tests are similar to interviews, you’re talking to 1 user at a time, but instead of questions, you give tasks. You should prepare 3-4 tasks to be performed, like what they would normally do in your system if it was already live. It’s a good way to validate your work, to see if your users will really be able to solve their problem with this particular concept of yours. How you conduct these sessions may vary by projects, concepts and even people, but here are a few highlights which can come in handy:

1. You test the UI and not your users. Whatever they do wrong, it’s not their fault, it’s a deficiency of your interface. They should know it, so do you.
2. Don’t give detailed instructions, write high-level tasks instead, similar to what they will get in real life. Even if they’ll be educated to use your software, there won’t be someone with them all the time to show their way around. To simulate this, you must not guide them through your prototype either.
3. Include options not directly related to the tasks. If you use some prototyping tool, it will probably highlight the clickable elements somehow. If the only clickable things are the controllers of the test, they’ll easily find their way around. But if there are several different actionable items, they’ll be able to look around, open and close things, get lost if it’s the deal. Even if you feel like “come on, it’s there, why don’t you find it” you should resist your guts and stay silent. It might be clear for you, while it’s a riddle for them. The goal of these tests is to uncover the riddles, not to justify your ideas.
4. Remind the participants to think-out-loud during the whole session, so you can understand why they do what they do. Same as during the interviews, you should create notes and possibly record the session. You can also have a little chat with your users after the session. You can go back and ask why they did specific things if they didn’t explain it during the session. You can even ask their opinions at this point, but never during the session. Dropping ideas about the UI can lead you away from the goal of the tests, so stay focused and keep your participants focused, as well.

The results of these sessions will help you see the weak-points of your concept, or just help you choose the best one. You can rethink a few things, and re-test them before moving further. The number of tests and iterations depend on your time and budget: according to Jacob Nielsen the best if you test with 5 users, considering the number of uncovered issues and the cost of sessions, because after a while, users will repeatedly find issues others already uncovered.

It’s also important to properly recruit your participants. If you are about to build an application for accountants, you probably won’t get valuable feedback from a mechanic. Same if you’re about to improve an existing service, you better talk to people already using it instead of new recruits (except if you try to figure out how newcomers would interact with a new feature).

A Common Mistake to Avoid

There’s another practice called design critique, where a larger number of team-members — designers, developers, QAs, product managers etc. — sit together and talk about designs. You present your ideas, and others can ask questions and propose changes based on their concerns of consistency, technical constraints, a11y issues or simple usability assumptions. It can be really helpful: when you spend a long time trying to solve a problem you might get stuck. Fresh eyes and other perspectives can help you out of that state, and it’s always good to do a little brainstorming anyways.

However, teams often confuse DC sessions with proper usability validation. There are a few reasons why you can’t just replace UX studies with them:

1. Detailed explanations. While during a usability test you’ll give tasks and see how others interact with your prototype, design critiques are about telling the whole story by yourself. You go through the flow and tell the team what is happening and why. It makes sense easily that way, but if there is no explanation only the UI, it might fail.
2. Domain knowledge. The team you work with has a significant domain knowledge, even if you’re just working on a contract project. You know how the system works, you know what is happening in the background, how data is transferred, what APIs are called… users don’t know that kind of thing, and you are not your users.
3. Subjectivity. While you might like something, others might not. Also, while you think something is clear, others might not understand it. When you say “I think it works” it's only your point of view and others might argue with that based on their perspective. Disagreement can help the progress, however, if it’s constant it’s a flag that you should see how users react instead of fighting over your opinions.
4. Ego. I don’t say it’s always around, but these kinds of discussions can easily turn into opinionated arguments, where everyone tries to convince the others of their ideas. I cannot stress it enough: you don’t design — or code — for yourself, you do it for your users. If someone in the team has a better idea, or just found a mistake in yours, be happy as you have an opportunity to improve your product. It’s not a one-man show, you fail or win as a team.

Furthermore, it’s a lot harder to prove yourself through a single presentation without any actual data. When your design is based on conjectures it might be hard to defend an idea, as you cannot support it with facts. Others might have different suppositions and from that point the argument stands or falls on the persuasive skills of the participants.

It doesn’t mean these sessions aren’t useful at all, they just cannot replace research as they help you in different ways. I also think arguments are generally good as we can learn a lot about each other’s perspectives. What I say is that uncertainty makes things difficult, as you’ll only see results after your work is published. The best thing you can do is to both research and synchronise regularly with your team, so you can make sure what you’re about to build will serve the users well, while it’s still technically feasible.

Referring to my previous article again, everything you create results in a user experience. UX is not something you design, it’s an inevitable outcome of your work. Please, keep that in mind. 🙏

Should Designers Code? Should Developers Design?

I think this eternal question exists because graphical UI design itself is not typically hard. UI design tools like Sketch or Figma are pretty straightforward, they’re easy to work with even with little experience, not talking about the hundreds and thousands of quality tutorials and resources available on the web. Graphical UI design is a skill, and being an expert means you have a whole lot of other valuable skills, which will ultimately define you.

Because of the core differences between the mindset of designers and developers, I prefer to combine research with design, rather than design with coding. If you’re biased by your own technical knowledge of a system, it may be more difficult to find an abstract solution to a problem. That’s why I see true value in the collaboration of multiple disciplines, and the combination of different perspectives.

However, a visual representation of your work still can be beneficial, as it helps you to find potential blind-spots and missing edge cases, also helps to connect the dots and see the overall picture, and last but not least: it’s a lot faster to fix things in a design tool than in the actual code. So, while I don’t say developers should design, some design skills can be a good addition to your workflow.

If you’d like to learn more about the values of designer-developer collaboration, or how designing can help you as an individual developer, stay tuned, I’ll get back to you soon. 🤟