Wearing Multiple Hats Without Tripping
Over the past quarter-century, product design has matured considerably. We now have tools and practices that let designers work faster and more collaboratively with engineers and product managers. But that maturity brought process — sometimes too much of it. While building the design practice at Heap, I tested ideas around Pragmatic Design: fewer, lower-fidelity artifacts; design briefs over endless mockups; product-quality reviews in place of design reviews; and early, continuous collaboration across Design, Product, and Engineering. The results were encouraging enough that we shipped more with a smaller team.
In 2020, I left Heap to found Miter, a startup trying to make meetings better. If Heap was a testing ground for pragmatic design, Miter became a crucible for extreme pragmatism. For a long stretch, I was the only designer, the only PM, and the only engineer. That raises sharp questions: When you're doing everything, what process is actually worth keeping? What can be optimized, and what can't? And what changes once you start hiring?
Even if you're not a founder, it's worth asking why each piece of the design process exists and how far you can push its limits. A lean process benefits a team of ten just as much as a team of ten thousand.
The Advantage of Multidisciplinary Designers
Many designers already wear multiple hats — doing a bit of product management, or throwing together a prototype if they're technical. That breadth is often what makes the work fun. But it's also a genuine advantage, not just a personal preference.
A broader toolkit means more ways to experiment. With some engineering knowledge, you can build working prototypes or design directly in the codebase when that's the most efficient approach. Small, straightforward projects can sometimes flow straight from brain to product:
Team growth doesn't erase that benefit. No matter how thoroughly we think through edge cases, we can't predict every turn a design takes during implementation. I've long argued for design and engineering to proceed in lockstep throughout the process. Being a lone designer-engineer has reinforced how powerful that is — my designs change radically long after they're "done." That's easy to manage solo, but it's manageable on a team too.
In short, a little conversation can substitute for a lot of process. That's easier when designers speak some Engineer, engineers speak some Designer, and everyone speaks a bit of Product. In a quick conversation, you can make trade-offs, generate creative solutions, and reprioritize based on your evolving understanding of ROI.
At Miter, we built the product to work whether you're signed in or not — if you have the URL, you can join a meeting without an account. That was a strength we wanted to preserve. When we planned Dynamics, our facilitation feature, we assumed it would work the same way. During sprint planning, Nico, our first engineer, raised questions about distinguishing among anonymous users. Identifying users is central to Dynamics in a way it isn't elsewhere in the product.
The options were all doable check-none were easy. So I made the call, wearing my Product hat, to make the feature signed-in-only. Nico disabled the button for signed-out users. I recognized users would need more feedback, put on my Design hat, decided it was worth doing before launch, switched to my Product hat again, and spent a couple of hours implementing it in code.
Designing in Code Has a Catch
Building designs directly in code can be efficient, but it carries a risk: your engineer instincts can undermine your design instincts. Every argument designers have with engineers exists for a reason. When you're engineering, you want to simplify: reduce code paths, avoid async situations that could cause race conditions. But sometimes those complications are exactly what makes a design great.
While implementing, I catch myself pushing back on my designer self — and since the engineer self is doing the work, the designer self tends to lose. I have to step back periodically, put the design hat back on, and reconsider.
That separation is easy to preserve if you do all your design in design tools, but going that far defeats the purpose. Sometimes things are straightforward enough, as with the Add Task example above, that separate design work isn't worth the time. The key is recognizing when you need to be thinking in design mode versus engineer mode.
Say Which Hat You're Wearing
It's not enough to know which hat you're wearing — you should tell people. One afternoon, my co-founder asked for help with a marketing email. I started with the usual designer questions: What's the goal? What does success look like? Those are fair questions, but he didn't realize which hat I had on. Instead of a curious designer gathering requirements, he heard a skeptical CEO challenging his plan. A few tense moments later, we sorted it out. Now I clarify my hat upfront.
This matters most in leadership roles, where power dynamics amplify misinterpretation. The CEO of a startup I advised went so far as to keep two physical baseball caps on his desk, labeled "CEO" and "Product."
Multidisciplinary Fit Depends on the Team
This approach isn't universally welcome. Some teams value specialization and expect people to stay in their lanes, particularly at larger organizations. I once got feedback that I needed to "act more like a designer." It stung at the time, but I eventually realized it reflected a misalignment with that team's culture rather than something fundamentally wrong with how I worked.
The Takeaway
On any team, it helps when everyone understands each other's specialties. Actually wearing all those hats may be less valuable at larger companies, but the fastest way to understand another discipline is to practice it. I'd urge any designer to learn to code and to think holistically about roadmaps and launches the way a PM would. How you apply that knowledge depends on your team's dynamics.
Stripping Design Down to Its Essentials
Most of what designers do day-to-day is about communication and persuasion: testing to justify decisions, mocking multiple options because it’s expected, writing specs so engineers get details right, and presenting in critique to invite questioning. But when you’re the only designer at your own startup, none of that is strictly necessary — you’re convincing yourself. The question becomes: what still matters?
The Art of Quick Sketching
Design naturally moves from broad and low-fidelity to detailed and high-fidelity: bullet points, sketches, wireframes, mockups, prototypes, then implementation. In practice, you rarely do all of those steps.
Paper sketches are a favorite for early-stage work. They’re faster and more flexible than wireframes — which have largely fallen by the wayside — and are even worth bringing to executive reviews.
Sketches become even more powerful when you’re the only audience: they don’t need to be legible to anyone else. That one weird blob in the corner can mean anything, as long as you remember. The ability to run through variations quickly makes sketching a regular but brief habit before moving to higher fidelity.
Design Briefs
The Design Brief was created at Heap as a substitute for both lengthy design docs and exhaustive mockups. It’s a fast, early artifact — paired with sketches — to ground cross-functional discussions from scoping to leadership reviews before significant time is invested in details.
Larger projects still use briefs. They don’t take long to write, and the writing itself clarifies thinking, moving things from high-level and hand-wavy concepts to more practical territory. Briefs also serve as a record of intent — what you were thinking and why — which helps your future self retrace steps, especially when design reviews do happen.
Product briefs and engineering briefs follow the same pattern, both proving useful. The trick is keeping them brief, as the name suggests. Templates help, but they should be treated as guidelines, not requirements.
Hero Mockups and a Centralized System
Mockups remain essential. For significant changes or new features, mocking is far faster than building even a semi-functional prototype. The key is focusing on “hero” mockups — the critical states, not a comprehensive set. As the team grows, that will expand, but the philosophy stays: rely on briefs, real-time conversations, and design-minded engineers rather than drowning in mockups.
Miter has a working design system: a library of reusable Figma components with consistent global colors and text styles. Even with no other designers around, it’s worth the effort because centralization makes change easier, safer, and faster. A single change propagates everywhere instantly — want square buttons? Make it once, done.
Not everything deserves component status. If it’s too early or too prone to change, leave it one-off. The right time to extract a component is when the same element appears in a second project — Project N’s component becomes needed in Project N+1, and it’s time to formalize it. (Figma’s copy-paste between files and libraries could be smoother, but that’s another matter.)
Centralization matters even more in code. When mockups and code disagree, the code often wins, and that’s fine. The canonical style guide is the Global.less file of CSS variables. There is exactly one button component, used everywhere. Writing and reviewing code, being ruthless about centralization ensures consistency and easy future changes. The goal: never be the company where a simple design improvement dies because it has to be implemented five separate times.
Feedback Without a Design Team
Feedback is essential, but Miter has no designers. It does have design-minded engineers and a COO who can critique from product and go-to-market angles. A lot of critique happens via quick Slack messages asking for opinions, with occasional scheduled design reviews.
The missing piece is brainstorming and critiquing with fellow designers. Hiring one is a future goal. In the meantime, there’s no easy fix. The idea of solo designers forming cross-company peer-review groups is appealing but rarely finds time. Instead, the approach is to explain the rationale — and general design principles — to the rest of the team so their critiques grow more informed over time.
Research: The Productive 20%
User research often suffers from systemic issues: underfunding, being weaponized in cross-functional debate, ignoring foundational work for tactical studies, misinterpreting usability tests as direct feedback (leading to doing what users say rather than what they need), and dropping findings due to deadlines.
At a small startup, there’s no dedicated researcher. Research falls to the founder, whose time is already split. That makes every research effort count. The guiding principle: designers know how to design. It seems obvious, but it’s easy to forget, assuming anything untested has an equal chance of failing.
Roughly 80% of a good designer’s work should be usable without testing. Good designers also sense where the remaining 20% lies — the bold, unique, unknown, or ambiguous elements. That’s “UX Risk,” and that’s what needs testing.
Mistakes still happen in that safe 80%, which is why monitoring data matters. One recent example: multiple users interacted with Miter’s pre-meeting screen but never pressed Start. A hypothesis emerged — the topic list looked like a note-taking UI, not a meeting prelude. Session data and average topic length confirmed it. The fix was simple: make topics look more like topics and less like notes.
Research might be more extensive than typical for an early-stage startup, and other founders might question that spending. But heading toward the next fundraising round, it provides far greater confidence when speaking about the target audience and their needs.
Lessons from the Bare Minimum
What stands out about a stripped-down design process is how many traditional artifacts remain in regular use. Very little from a larger team’s toolkit is entirely abandoned. The tools for exploration and iteration are the same ones used for communication and persuasion. The real difference is comprehensiveness. Key takeaways:
- Use the full toolbox. A broad array of design tools exists — use them, but match the tool to the job. Not every project needs every artifact type, regardless of whether you’re on Agile, waterfall, or something in between.
- Low fidelity beats no fidelity. Low-fidelity work is faster and easier, and in cross-functional settings it keeps stakeholders focused on the forest, not the trees. Skipping it because you’re working alone is tempting but risky. A few minutes of sketching or bullet-point writing clarifies and solidifies designs at a stage where changes are cheap.
- Understand your motivation. Are you mocking something up because you need it or because stakeholders will see it? Neither answer is wrong, but they require different approaches. A mockup meant for your own eyes has vastly different requirements than one destined for an all-hands slide.
The Traps of Wearing Both Hats
Designers have a curse: they see pixels. Misalignment, fuzzy borders, missing transitions — these are visible and they bother us in ways others can’t perceive. Early-stage founders have their own curse: a lack of resources. Agility is unmatched, but capacity is limited to one or two things at a time.
These curses collide. With no one to stop you, polishing can eat the product alive. The industry is littered with design-led companies that built beautiful things nobody wanted. However, the design-led company’s true advantage is great design as a differentiator — a polished, elegant, usable interface that stands out from competitors, and that’s worth aggressively pursuing.
The balance lies in wearing the design hat fully, reveling in the details, then switching to the product hat to keep detail work proportionate. It’s a healthy dynamic when the pressure isn’t one-directional. As a leader, nitpicking details gets them fixed — that’s good — but it carries a cost. Recognizing when to stop polishing is as important as knowing how to polish.
