Why we never hired a designer

Part 1: A lone design generalist

A brief history of design generalists

A few decades ago, every visual designer’s dream job was in advertising — a field where creativity and a good salary converged. However, by the late 2000s, it started to feel like everything possible in 2D design had already been explored. The work often became nothing more than a rehash of previous ads or at best recycled concepts borrowed from old graphic design school projects.

It almost felt like the end of creativity.

Of course, it wasn’t quite that dramatic — creativity was still thriving; it just required a more focused and specialised approach. Hence for many of us designer-generalists, it was time to leave print and advertising to the graphic design specialists and move on to younger, less explored fields of web and digital product design, where we could once again feel like pioneers.

Fast-forward to the present day, and the story seems to be repeating itself. Just as the standardisation of brands through corporate brand guidelines once signalled the end of exploration in advertising agencies, the standardisation of user interfaces through unified patterns and design systems now marks a similar trend in digital product design.

And there’s nothing inherently wrong with standardisation — it’s a natural progression in any emerging field, moving from chaos to order. After all, people like order.

Why we never hired another designer

After hiring our first designer — who, of course, was a generalist — we found ourselves in a curious position:

Some days, it felt like we needed more designers, but on other days, we couldn’t quite justify why.

I like to believe that being a designer is, above all, an explorative calling. We thrive on discovering new, unmarked challenges and constantly seek out “unknown unknowns.” But once all those previously unknown questions are answered and solutions are in place, the role of the designer often loses its soul. It becomes more about following the patterns and standards we worked so hard to define.

At this point, the designer’s job starts to feel more like either engineering — where we assist developers in mapping user interfaces — or product management, where we contribute to shaping the roadmap through user research. Both fields are either already claimed by other professions or have adopted many of the tools and methods we, as designers, once eagerly promoted under the belief that “everyone can be a designer” (also known as Design Thinking).

Designers have designed themselves out of the equation.

As a result, if digital product sales aren’t driven by user experience — which is often the case in B2B software — an organisation can easily function without product designers. They might miss out on some benefits, but if they never knew how to fully leverage designers in the first place, there’s not much to lose. These days, user interfaces can be built by front-end developers, and basic user research can be handled by user-oriented product managers.

Democratisation of digital product design

To create a standard flow, web developers need components, layouts, interactions, and common patterns — all of which can now easily be found online, with plenty of examples to benchmark and draw inspiration from.

When it comes to product-specific flows, developers could benefit from a product designer’s input. However, if the flow is technology-heavy and intended for engineers, a designer’s contribution can become tricky.

For example, in organisations where one designer is responsible for multiple products, it’s challenging to keep them involved in highly technical workflows. These decisions are often made during daily stand-ups or ad-hoc discussions with backend teams, making it difficult for the designer to stay in the loop. In such cases, if web developers are trained to use tools like Figma and have a ready-made UI kit, they may be able to prototype and draft solutions faster than waiting for the designer to first grasp the changes and then provide designs.

The obvious solution would be to have one product designer per team, allowing them to participate in daily meetings and ad-hoc discussions, thus becoming an integral part of the team.

However, this leads to two side effects. First, there’s a tendency for organisations to assume that there isn’t enough design work for each product separately (which is a misconception — the real issue is that there might not be enough perceived value to justify the cost per product).

As a result, the first hire often ends up as a lone design generalist.

Second, the designer can easily slip into the product team’s front-of-the-frontend developer role, focusing on preparing UI for development and fixing visual bugs afterward. Which, as mentioned earlier, is not an explorative enough role for a designer to truly thrive in.

So why would companies hire a product designer when they can simply buy a Figma subscription for their developers? Moreover, why would a designer want to agree to a supportive maintenance role, rehashing the same buttons over and over again?

What can a lone product design generalist do

So far, we’ve established that, due to the wide array of available design tools and shared design knowledge, companies can, at least in theory, build user interfaces without involving digital product designers. On the other hand, designers may feel that their role has been reduced to mere UI maintenance — a shift that can lead to disillusionment and motivate them to explore alternative career paths.

Let’s begin with the first scenario:

In theory, companies can build user interfaces without hiring a product designer,

which can be a lucrative proposition. But is it really as simple as it sounds.

While product teams can certainly create MVPs or proof of concepts without involving product designers by utilising an open-source front-end framework like Bootstrap or Tailwind and drawing inspiration from similar web products. Once they begin expanding the product’s functionality by following the agile process of continuous improvement, the side effects — such as user interface inconsistencies, increased complexity, and broken user flows — will start to take a toll on product usability and, consequently, its long-term success.

To mitigate these side effects, a product design process should be established. And only once this process with its supporting tools and guidelines is in place, can web developers proceed with the product development independently.

That is why having at least one designer is essential to help the organisation effectively adopt design tools and knowledge.

Adopting design tools

Since a single generalist designer can’t cover all of a product’s user interface needs — unless that becomes their sole focus, which is undesirable — the only viable solution is to teach front-end developers UI design.

With how the field of UI design has evolved, web developers actually have an advantage over designers: a deeper understanding of the actionability of UI components. They don’t just see static images but lines of code, which gives them insight into the opportunities for interaction. However, one of their main disadvantages lies in visual design and high-fidelity prototyping.

This disadvantage can now be easily addressed with a UI Kit in Figma or similar tools. Once a designer has created a few initial layouts and taught developers how to use the design tool, they can gradually start designing their own drafts and mockups based on those layouts and existing components. Initially, this is done with the designer’s support, and after a few sprints, once the developers are more comfortable with the tools, they can work independently.

In this case, the generalist designer should:

Convince the organisation to purchase the design tool.
Create a UI Kit that can be easily used by everyone.
Draw initial interfaces that serve as templates for future designs.
Provide a few lessons on how to use the tool.
Continue supporting and assisting until the developers are confident to work independently.
As a bonus — start documenting key UI patterns, e.g. where a toast message should appear etc.

This, of course, requires a few conditions on the engineers’ side:

Web developers should be motivated to create designs themselves.
Their team leads should account for design work hours when estimating Epic sizes and planning sprints.

If these conditions are met, consider yourself halfway there.

Sharing design knowledge

Once developers become comfortable using design tools independently, the next step is to broaden their design knowledge. Surprisingly, the first topics to cover are not UI or UX but the fundamentals of graphic design.

While most web developers already have some familiarity with common UI patterns and principles, it’s often the basics of graphic design they struggle the most — a topic not usually top of mind when teaching UI design to developers.

As a result, in addition to documenting UI patterns, a design generalist could launch a series of informal lectures, which I like to call “Product Design Academy (sort of)”, as these aren’t exactly official academy sessions.

I’d personally recommend starting with graphic design fundamentals:

Typography
Colour theory
Gestalt principles

Then, gradually move toward more product design specific topics, such as:

Common UI principles
Data visualisation
User research

For areas where the lone designer may have less expertise, bringing in subject-matter experts can be especially valuable — and, for once, offer an interesting learning opportunity for the designer themselves.

Ideally, the organisation could also commit financially to bring in external experts for deeper insights — but let’s be honest, few tech companies these days are eager to invest in non-tech learning. This is where a design generalist has an advantage over more specialised designers, bringing a broader knowledge across various design subfields.

Using a design tool with a common UI kit can help web developers to address basic challenges related to maintaining the consistency of web components. However, once the need to make a design decision with multiple valid options arises, or when developers encounter a double-bind situation where none of the solutions seem effective, they will need a deeper understanding of psychological principles and visual rules that explain how people perceive visual information. This is why it is essential to share design knowledge with developers.

Furthermore, to fully address the growing complexity and breaking user flows, developers need to view the product not only as a series of user flows, but as part of a larger task completion process that extends beyond their web app.

However, this can lead to a challenge of mutually exclusive thinking approaches:

one that is focused and practical, aimed at making things work; while the other is holistic and intuitive, considering how users perceive and use the product — and whether the issue is even relevant to them. This may still require someone to step into the role of a designer.

Designer as a role

As it was mentioned earlier, there is a certain design adoption threshold that can’t be crossed without involving a product design specialist. In this case, “designer” isn’t necessarily a job title but a role. However, the person in this role needs a specific set of skills and experience, along with a particular mindset — what some might call design thinking without capital letters.

From an organisation’s standpoint, product design should be seen as a role rather than a job position.

While the job tasks can be handled by a non-designer, the role itself could not be filled by an engineer or a product manager. Why? The quick answer is — they think differently.

In a nutshell, there are three types of knowledge:

episteme answering the question why?
techne answering the question how?
phronesis answering the questions when? where? and whom?

While product managers excel at defining why a product or feature should be developed, and engineers are skilled at how to build them, designers focus on exploring when, where, and by whom those products and features will be used. The latter requires a more intuitive way of thinking, which can often contradict the more analytical, fact-based approaches of the other roles.

Design thinking is a way of applying a series of processes as Intuitive hypothesis formation, Concept creation and Prototype verification techniques applicable by designers for finding and solving problems. (1)

While this way of thinking may still be required to resolve the most ambiguous product design challenges, it should also transcend the confines of the well-established product design discipline, allowing designers to contribute to other organisational functions.

In areas where the adoption of design-related tools and knowledge is less common, designers can help introduce innovative ideas and generate greater value through collaboration.

Deciding whether to extend the design role beyond digital product design is a choice that both the organisation and the designer must evolve toward together. Therefore, the ultimate goal of teaching developers UI design and enabling them to work independently is to meet the organisation’s product design needs — allowing the lone design generalist to free themselves from the confines of digital product design and embark on new pioneering adventures. We’ll explore this topic further in the Part 2.

Next on “Why we never hired a designer”

In Part 2, we will explore a second scenario regarding why organisations shouldn’t hire a digital product designer if they merely need someone for UI maintenance. We’ll also discuss why design generalists shouldn’t agree to such a role and how they can advocate for the adoption of design thinking across the organisation, including the relevant design disciplines and tools involved.

References

(1) Takehiko Yogo (2019) https://digitalcommons.uri.edu/cgi/viewcontent.cgi?article=1090&context=mgdr

Why we never hired a designer was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.