By Lanre Fadire

The first time I realized I was truly on my own as a designer, it was not dramatic. It was a Tuesday afternoon. A product manager Slacked me about a new feature. Engineering had questions about spacing tokens; support wanted help with usability complaints, while marketing needed visuals for a launch. In all of this, there was no one else to forward the message to. I remember leaning back in my chair and thinking: Oh. It is just me.

Over the course of my career, I have been the only designer in two very different environments. In one organization, I owned a single product within a larger company that had other designers across teams. In another, I was the only designer in the entire company. Both experiences were exciting but challenging in different ways.

What follows is not a handbook in the traditional sense; rather, it is what I’ve learned about staying effective, and sane, when you are the only person thinking about design full-time.

One of the first lessons I learned is that not all solo design roles are the same. Sometimes you are the only designer on a product, but you still have other designers in the company to sanity-check ideas with. Other times, you are the entire design function. No critique partner. No design lead. No inherited system. What I know for certain is that the difference matters.

When I was product-focused, I had ownership but also quiet support. When I was company-wide solo, I had to create my own feedback loops from scratch. I had to decide how much depth to go into on one feature versus how much breadth the company needed across five.

And very quickly, I learned something else: design priorities must start with business priorities. When everything flows to you, you cannot afford to chase interesting problems. You have to chase impactful ones.

I once joined a team that immediately asked me to redesign multiple surfaces. It would have been easy to start polishing visuals. Instead, I stepped back and mapped the user journey and what I discovered was that the biggest drop-off was onboarding. Not the dashboard or the UI theme, but onboarding. So that was where I focused.

Improving that single flow moved adoption significantly more than any aesthetic refresh would have. That moment shaped how I think about solo design: if you do not prioritise ruthlessly, the backlog will prioritise you.

Another tension I constantly navigated was quick wins versus foundational work. Small usability tweaks can reduce friction immediately. But if you never invest in systems, you will keep solving the same problem repeatedly.

At one point, I noticed inconsistent form validation patterns were generating support tickets. Instead of fixing each form individually, I built a standardised validation component. It did not take long, but it quietly improved the experience everywhere. That was when I understood: solo design is not about doing everything, but rather it is about designing leverage.

There is no second designer who “just knows” what you meant six months ago. So I became obsessive about clarity: naming conventions, annotated components, version histories. My files needed to be understandable without me in the room. I also learned to think in systems earlier than I might have otherwise.

Instead of jumping straight into components, I started with tokens; color, spacing, typography, interaction states. It felt slower at first. But once those foundations were in place, building components became faster and more coherent. Engineers appreciated it and I appreciated it even more.

Also, time became my most guarded resource. I batched similar tasks to reduce context switching. I templated recurring deliverables. I blocked deep work hours, and I quietly evaluated requests against a simple question: Is this high impact, low effort, or just urgent? Being solo forces you to say no more often than you’re comfortable with.

The biggest misconception about being a solo designer is that you are alone, but you should not be. When I was the only designer company-wide, I started by building internal allies. I educated product managers and engineers about design reasoning. I invited them to critiques. I gave them language for feedback beyond “I like this” or “I do not.” Over time, they became design champions.

Externally, I built relationships with designers in other companies. I sought feedback carefully; never sharing proprietary work, always abstracting the problem. That boundary is non-negotiable. Trust matters.

User research also became something I had to make manageable. Instead of waiting for ideal conditions, I created a monthly research day. I scheduled interviews back-to-back, synthesized insights immediately after, and kept it lightweight. It was not perfect, but it was consistent, and consistency beats perfection when you are solo.

Furthermore, one thing I underestimated early on was how much explaining design matters. People do not automatically understand why a change is necessary, so, I started recording short walkthrough videos. I used before-and-after comparisons. I connected design decisions to metrics.

I also learned to speak different languages. With engineers, I focused on feasibility and specifications. With product managers, I talked about retention and activation. With executives, I connected design to business performance. Design became less about pixels and more about persuasion.

Eventually, I began hosting informal sessions for interested colleagues. We discussed principles. Reviewed case studies and previewed upcoming work. Those colleagues started advocating for design in rooms I was not in. That was the moment I realised scale is not about hiring first. It is about influence.

Another key takeaway is that if you want design to be taken seriously, then measure it. Conversion rates, workflow efficiency, support tickets, satisfaction scores, A/B testing results.

I tracked my workload over months and noticed most of my time was spent executing, not researching or improving systems. When I presented that data, alongside industry benchmarks, it made the case for additional resources far stronger than opinion ever could.

On a parting note, if I had to summarize what being a solo designer has taught me, it would be this: prioritise what truly moves the needle. Document so well that your absence does not confuse. Build allies. Connect design to business outcomes. And never truly work alone, even if you are the only one with “Designer” in your title. The strongest solo designers are not isolated; they are orchestrators.

Lanre Fadire is a Senior Product Designer with over 5 years of experience creating user-centered solutions. His background includes being the only designer in various contexts, from product-specific roles to company-wide positions, giving him unique insights into thriving in solo design environments.