What’s the key difference between UX/UI and product designers
Hi! 👋 I’m Victoria, Head of the Product Design Team at START streaming service.
Whenever I had to hire someone for an in-house position and looked through the job market, openings, and CVs, I noticed that many product teams were looking for UI/UX designers instead of product designers. I mean, the job market is a bit confused when it comes to the naming conventions. And it makes sense — the environment and requirements are constantly changing, and even the courses for designers are called differently. But more often than not, UI/UX designers become a “tool” when it comes to a product-oriented team, and most of the work has to be done by the product owners.
Why does it happen? For the most part, UI/UX designers work at design studios. What are the differences between design studios and product-oriented companies? Most often studios practice the project-oriented approach. Designers receive some specifications for the task, create cool images within a tight deadline, and hand it over to development. That’s it, the project is over.
What skills are important for a project-oriented designer?
Of course, the quality of deliverables and usability. Mind this, usability but not user experience (UX). There can’t be any user experience at this point — there are no users yet. Project-oriented designers should also know all the guides (because development must be cheap) and be able to present the deliverables to the customer.
Product-oriented approach involves iteratively improving one product. This requires designers to have deep-cutting skills: ability to analyze metrics, understanding of DAO, MAO, and retention, and knowing the difference between ARPU and ARPPU — the product must have value for business, and that value must be calculated. It also requires working with hypotheses and the backlog, conducting user studies with real audiences, and taking corner cases and interactions with different product teams into account. Volumes upon volumes of information must be learned by heart and any mistake increases the cost of product development.
Working under strict specifications produces things that are detached from reality. Sometimes, this can take months to notice — one day, deep into the development cycle, it may turn out that graphics for some states are straight-up missing. Tasks keep getting postponed again and again, making planning impossible.
This was the situation when I came to START. The first thing I heard was, “The team can’t keep up with the tasks, we need more designers.” This seemed like an obvious solution. But it never is that simple — failure to meet deadlines is not the issue, but a symptom of the project-oriented approach.
To illustrate, let’s break down the typical workflow for a task.
You’ve got a hypothesis or an idea, a hypothesis-to-be. Then come the metrics, research insights, benchmarks, and maybe even some techy stuff: a microservice here, some terrible legacy stuff there, and here’s the team rolling out A/B tests… Somehow, these things work in harmony and the task, eventually, comes to the designer’s table. Sometimes it happens right away, and sometimes after the system analysts have done their job already. But the important thing is that the product designers get their tasks as specifications.
Take a look at this example: a button here, some text there, needs to be a modal window, and the images don’t really matter — it’s up to the designer.
What happens next? Well, the designer designs. Usually strictly following the specifications. The results depend on the quality of the task outlined in the specifications. If the product owner didn’t take something into account or forgot to outline it in the specification sheet, there will be some rewriting, reexplaining, and remaking to do. Going back to my example. After the design is ready, the product owner suddenly thinks that the pop-up should be just a bit different for unauthorized users, amending the specifications. The task goes back to the designer. Next, the development team grooms the design, and it turns out that we already have a similar pop-up, already coded and can be reused with a couple of tweaks to the images. The task goes back to the designer, again.
After grooming at the stage of development or by project managers, it turns out that images for some cases are missing: nobody thought about the request errors. The task goes back to the designer.
Next up is a design review and task completion. At the review, the designer finds out that it all looks terrible in adaptive 320px. Needs an urgent mockup to fit into the task.
All of this happens, obviously, during more than 1 sprint. At stages of grooming and development, the designer usually has another task and is switching back and forth constantly. The product owner is also busy, getting pinged from every corner. This is, by the way, the point where it starts to feel like there aren’t enough designers and you need to hire more people.
As a result, the time to market for the design triples, and the quality of development also suffers because corner case situations were designed in a hurry. This causes design debt: a wrong icon here, non-matching placeholders there, color not featured in the palette. Snowball!
Shall we try fixing it?
The product manager has a hypothesis or a hypothesis-to-be. A designer is needed as soon as this stage. But what are the nuances? Often designers are put together as a dedicated team and fulfill the role of a studio within the product. It’s very cool if your company is making progress towards cross-functional teams or has already implemented them. If not, time to create teams for design discovery. What’s that? You add a designer who closely follows the product owner, becoming their right hand. This designer is now responsible for the flow, becoming the design owner. Since this transition would also change the processes within the design department, it is imperative that the head of design be involved.
After the designers are broken into separate teams, the product owners will need to explain the approval processes and introduce the designers to stakeholders. The better the designer understands how things work beyond their scope of responsibility, the easier it will be for them to fit into the new process. They will need to participate in discussions with other teams. Together with their product owner, the designer will look for research insights and discuss how to influence the metrics. At this point, designers start speaking the language of solutions, rather than separate images.
To speed up the process or improve the skill, you can have the designer attend specialized courses.
This way, the designer will know all the ins and outs already during the design discovery phase. Next, to make these changes stick, we forget all about specifications and introduce design discovery documentation in the mix.
A design discovery document should answer three basic questions: what, why, and for what purpose. It may contain the following subsections.
This means, that the design discovery document holds all the things you managed to dig up. In some companies, the design discovery document is a single artifact that is iterated upon by all the employees involved in developing a feature. It’s also where designers, for instance, put all design descriptions at the end of the work, developers outline all the requests, methods, and APIs, while the product owner summarizes the design and the results of A/B tests. This allows you to keep the whole knowledge base in one place, instead of having it scattered across Miro, various design docs, Confluence, etc.
Abruptly switching from specifications to design discovery documentation is likely to make designers nervous, especially when it comes to complex tasks. So start small. Product owners should also add some possible implementation variants in the design discovery document.
Next, the designer begins to… well, design. For the first few tasks, they will obviously have to frequently consult with the product owner. Novelty breeds excitement, new ideas are being born, but also doubts and many alternative decision paths. Designers need additional support during this transition period. It is better if you do not tell them the solution you think would work best, but slowly nudge them in the right direction, asking things like “Why do you think this solution would work better?” The most difficult thing is to stop treating your designers as tools, as executors.
You must invite them to grooming meetings and let them talk about the solution themselves. The designer will feel a sense of responsibility, and learn all the issues and peculiarities firsthand. You know you’ve done well when the product can skip a grooming meeting without things going awry because the designer is able to handle it themselves.
In the product-oriented approach, the designer needs to also be included in the discussions on A/B test design. If you don’t do A/B testing, you can discuss how the hypothesis will be tested and what are the criteria for success: this will give the designer a broader perspective on the task.
Here’s an example. I made this screen one time.
Here we have added the ability to sort search results by category. Since there can be lots of categories, I decided to make a dedicated menu (on the right). The test gave positive results, business metrics were decent and, six months later, we added the element to the different parts of the app. You can imagine my shock when I learned that almost no one actually used the menu. It was an unnecessary element that we’ve added everywhere across the product! If I were involved in an A/B test discussion, I would have learned that there’s an event attached to this element or I could have asked how the element worked, because the element’s usage conversion is a measure of my performance. So give the designer a chance to discuss the A/B test design.
These changes will greatly decrease the number of issues in development. Or, at least, this will give you more time to fix them. In fact, when the barrier between development and design is erased, designers start asking questions as early as the mockup stage — this helps reduce the likelihood of issues arising. But what about other tasks that threaten to bury the designer in a mountain of work whenever something goes wrong? This can be optimized too, with a very simple tool — a roadmap.
More often than not, product owners track deliverables using the roadmap. But the roadmap can also contain the hypothesis development stages. Such a roadmap is infinitely more useful for designers, as it enables design-focused vision and resource optimization.
As a designer myself, let me elaborate a bit: seeing the plans for the product (and being able to influence them) helps me track future deliverables better. You start optimizing things, switching to a more robust mindset, “Here I can design two features as a bundle and tell the development team about all the nuances. Here I can save time because all corner cases will be elaborated in this task. This task is difficult, so I’ll leave more time to fix the issues that will definitely crop up. Here two product owners want their respective features done at the same flow stage, we should discuss that.
You can use any tool to outline the roadmap, be it Jira, Miro, or even Excel — all that matters is that it’s kept up to date.
Having gone all this way at START, we managed to cut the number of meetings and calls by 3 hours per week, on average. Design solutions were better thought through, designers stopped working under severe time constraints and now had more knowledge about the task. If before, because of the never-ending deadline pressure, designers simply ran with the first solution they came up with, now they can afford to think about simpler, more elegant, and scalable solutions. Team morale also improved.
The biggest impact of the change, in terms of product development and the overall business, was the reduction of time-to-market at the design stage. As a supervisor, I now see that tasks are closed much faster in Jira. Unfortunately, I can’t give you the exact figures, as we didn’t add a counter to Jira. If you are going to start changing processes, be sure to do so right away.
Every design course features a section about the product-oriented approach, but product owners rarely get a chance to learn about it and appreciate its value in their courses. That’s why product owners often treat designers as a studio that makes custom design mockups — that produces things made to follow the specifications down to a T. By transforming your approach to design, you will gain a design assistant, better quality of deliverables, and a higher satisfaction rate. Help your team adapt to new processes, improve the way things are run, and empower them to create an awesome product. Good luck!
