Lessons Learned As A Designer-Founder

In the quarter-century I’ve been a product designer, design has matured. We’ve developed tools and practices that allow us to work faster, better, and more in concert with engineers and product managers. Things are a lot less chaotic than they used to be.

But with that change comes the process. I’ve written elsewhere about the dangers of too much process; in the years I spent building the design practice at Heap, I tested and evolved my ideas around Pragmatic Design and its potential to reduce process. I encouraged lower-fidelity artifacts; design briefs instead of endless mockups; product-quality reviews instead of design reviews; and I pushed for early, ongoing collaboration between Design, Product, and Engineering. The results were encouraging: we got more done with a smaller, scrappier team.

In 2020 I left Heap to found Miter, a startup whose mission is deceptively simple: make meetings better. And if Heap was a testing ground for pragmatic design, Miter’s been a crucible for extreme pragmatism: nothing is scrappier than being the only designer, the only PM, and the only engineer. What process is worth keeping? What can be optimized and what can’t? And what needs to change again as we build a team?

That’s useful context if you’re a designer-founder yourself. Still, even if you’re not, it’s valuable to think about why each part of the design process exists and how (and whether) we can optimize it in various ways to be more efficient and better collaborators. So whether you’re designing on a team of ten or ten thousand, this post is for you.

Multiple Hats #

Founder or not, designers are often multidisciplinary. Many of us do some PM’ing or make a little prototype if we’re technical. If you’re like me, you enjoy that breadth and chafe a bit when forced to wear just one hat.

What makes being multidisciplinary an advantage? To begin with, it represents a broader design toolkit. With a little engineering knowledge, you can build working prototypes or even design directly in the codebase if that’s the most efficient way to experiment. And small, straightforward projects can sometimes go straight from brain to product

As a team grows, understanding diverse perspectives can improve collaboration and results. We can’t predict all the twists and turns our designs will take as they’re built, no matter how diligent we are at thinking through edge cases. I’ve always advocated for design and engineering to proceed in lockstep throughout the process; being a lone designer-engineer has reminded me just how powerful that is. My designs can change radically long after they’re “done.” That’s easy to deal with when it’s just me but feasible to manage as a team, too.

To put it simply, you can substitute a little conversation for a lot of process. And that’s easier when your designers speak a little Engineer, your engineers speak a little Designer, and everybody speaks a little Product. In a quick conversation, you can make trade-offs, generate creative solutions, and reprioritize the backlog as your understanding of ROI evolves.

For example, Miter was built to work whether you’re signed in or not: if you have the URL for a meeting, you can join and participate without an account. That’s a strength for us, and when we set out to build our new Dynamics facilitation feature, we figured that would remain true. But during one sprint planning, Nico — our first engineer — raised some questions about how we’d distinguish among anonymous users given we’re unable to identify them; doing so is central to Dynamics in a way it’s not elsewhere.

Legionary Studio is a full-service web design agency that specializes in creating beautiful, responsive websites that are easy to navigate and look great on all devices.


647 Woodland Drive, Sioux City, IA 51101 USA

[email protected]