Behind the Scenes of Product Development
Introduction to methods used by product professionals to define problems, create concepts and choose the best solution to implement.
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:
- 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.
- 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.
- 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.
- 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:
- 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.
- 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.
- 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.
- 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. đ€