Being the only designer on a product team

Being the only designer on a product team means you own the whole path from a request to a shipped screen, with no design peers to review your work. At Tigg, the accounting and POS product I work on at BIC Technology, that path is: the CEO writes a ticket and explains it, I design in Figma, the CEO and the senior frontend engineer sometimes review, I mark the page "Ready for dev", and the work goes through development, a dev environment, QA, UAT, QA again and a production release. What makes it work as a solo designer is a clear handoff, drawing every state, and treating QA, support and the CEO as research channels.

I joined Tigg in April 2025 as a three-month intern and have been the only UI/UX designer since. I'm now a UI/UX and frontend engineer, so on some features I design and build, and on others I design and hand over. This post describes the design process as it actually runs, and what I'd tell someone starting in the same seat.

What being a solo designer actually looks like

Most of my week is with two people: the CEO and a senior frontend engineer. From time to time I work with backend engineers and DevOps, with QA on bug fixes, and sometimes with sales. There is no design manager, no researcher and no second designer to argue with.

That shapes the work in three ways:

• Review comes from outside design. The CEO reviews for product fit, the senior frontend engineer for what can be built well. Neither reviews typography or spacing the way a design peer would, so I have to hold that standard myself.
• Research comes second-hand. I learn about user problems mostly from QA, support and the CEO. That's real signal, but it's filtered, and I say so in my case studies.
• I'm often the builder too. On cash sessions I designed the web and mobile screens and built the web frontend. On bulk import I designed every state and the senior frontend engineer built all of it.

Our design process, from ticket to release

The ticket

For new features, the CEO writes the ticket and explains it to me or to the senior frontend engineer. Sometimes the request starts elsewhere: I believe cash sessions started as a sales request that went to the CEO. On the configuration redesign, the CEO wrote the brief and later made a six-group prototype himself. My first job is to understand the problem well enough to explain it back.

Design in Figma

I design the flow and the states, not just the main screen. I also look at how other products solve the same problem. Zoho is the product I usually look to for patterns, and for cash sessions I looked at many other POS apps.

Some problems are easier to design in the browser than in Figma. For the configuration redesign I built the CEO's grouping as working navigation inside the product, so we could try it with the real settings instead of on a diagram. Building it showed where the grouping strained in a way a diagram wouldn't have.

Review

Review is informal. The CEO and the senior frontend engineer sometimes look at my Figma. When a design touches someone else's work, QA, sales or a backend engineer may be pulled in. The senior frontend engineer is especially useful early: a design that fights the existing components costs everyone time later.

Ready for dev: the 🟢 and 🔴 pages

The handoff is a Figma page marked Ready for dev. I keep two pages per feature:

• 🟢 page: the final design. Every state is its own named frame: nothing mapped, some mapped, required fields still unmapped, all clean.
• 🔴 page: an archive of what I tried. I don't delete ideas that lose; I move them there because they might be useful later.

The split matters more than it looks. A developer opening the page should never have to guess which version is final. For bulk import, both pages were finished before the build began on 2 June 2026, and the senior frontend engineer built from the 🟢 page.

Development, QA, UAT, QA again

After handoff the work goes to development, then to a dev environment where the team can try it, then QA, then UAT, then QA again, and only then to production. When I've built part of it, I fix what QA finds. When I haven't, I answer questions and check the build against the design. QA's follow-up list is often the most concrete feedback I get on a feature.

How I keep design quality without a design team

These are the habits that do the job a design peer would otherwise do.

Draw every state

Empty, zero, loading, partial, denied, expired, interrupted. If a state isn't drawn, someone will improvise it during the build, usually under time pressure. I keep a list, written up in the state checklist for business software.

Write the reason next to the decision

Decisions get questioned weeks later, by people who weren't there. A one-line reason beside a frame ("the note is required only when the drawer is not balanced") saves a meeting.

Separate final from exploration

The 🟢 and 🔴 pages are the cheapest process improvement I know. They make the handoff unambiguous and keep the history.

Be honest about the evidence

When a design rests on the CEO's knowledge and patterns from other products, not on user testing, I say so. It keeps me careful, and it makes the work easier to trust. I wrote about this in writing honest case studies.

Solo designer vs designer on a design team

Neither is better. The solo role gives you range quickly; a team gives you depth and critique. If you're solo, you have to create some of that critique yourself.

What I'd tell someone starting as the only designer

• Learn the domain before the tools. In accounting and POS, a pretty screen that bends a business rule is a bug.
• Ask the senior engineer to look early, not at handoff.
• Draw the unhappy paths first; the happy path is the one everyone remembers anyway.
• Keep an archive of explorations. You'll reuse more of it than you expect.
• Learn enough frontend to prototype in the browser. Some decisions only show up when the thing runs.
• Treat QA as a design partner. They find the states you didn't draw.

None of this is measured. It's how the work runs at Tigg today, and it's what has held up for me so far.