Designing AI products before the patterns exist

Most product designs start with references. You study the category, borrow familiar patterns, and decide where to differentiate.

But what happens when the category is still being invented?

Emily Moreton designed Scribe Optimize zero-to-one as the only designer on it. Optimize was a new AI-frontier product in the specialized intelligence space, so there was sparse reference for existing best practices. On top of that, we were discovering new capabilities of the technology as we were building the experience, literally building the plane while flying it.

How did you get to be the designer in charge of such a nebulous and critical project?

Emily: There was a period where I was the only feature-work product designer on the team, working across a bunch of teams and projects at once. I can’t speak for leadership, but I’d assume being able to manage that put me in a place where our CTO and cofounder, Aaron Podolny, and others decided I could handle it. I had also been at Scribe for long enough to have historical context about Scribe’s products.

For such a frontier AI product, there was nothing else on the market to reference. How do you even start?

Emily: It's twofold. One is having a really solid understanding of the specific problems our customers face, and getting a lot of feedback that way — that makes it easier to shape the UI in a direction. When in doubt: what solution better solves this problem?

The other is that while AI products are new, there are practices getting established that I can borrow from. There are so many agent-focused products coming out that you can audit them and see how different tools try to accomplish similar things, even when it's not exactly the same. So you look at analogous patterns — in AI and agent tools, but also in products that aren't fully AI — and optimize for what best solves our problem.

Jing: Do our customer problems and those outside patterns line up, or is there translation to do?

Emily: There's overlap, but it's not one-to-one — a different product is solving a different set of problems even when it borrows the same patterns. So it's important to pick and choose which ones are actually appropriate for us.

Optimize gives leaders visibility into how work gets done, so there's an inherent need to consider the end user's privacy. How did you handle that?

Emily:  I think about the two specific personas. For participants, it's about being transparent about the experience and keeping it simple so it's not something they have to think about. For the leadership side, we orient the product around repeated patterns and best practices on teams, not individual people.  Anonymization techniques like pseudonyms also help.

Was there a direction you'd invested in that you had to throw out?

Emily: Plenty. One was how we implemented our opportunity score. We built it to help people decide where there were opportunities for improvement, but we'd put it on too many things, so people didn’t understand what was most important. And we couldn't explain why something scored high or low in a precise way, which was losing us trust. You need really good reasons when you're telling someone where to focus.

So we simplified it. Now, for any given team, we just surface a ranked list of issues and a list of which workflows it touches.

Jing: Was that frustrating — feeling like you could've gotten there sooner?

Emily: Hindsight is 20/20. I always question if more user research could have saved time or energy in the long run, but you can’t know for sure. With 0-to-1 there's a constant trade-off between moving fast for feedback and planning thoroughly. I lean toward planning: not just moving fast, but moving fast in the right direction. 

What did you learn about yourself, building this from zero-to-one?

Emily: I thought I was already a flexible designer, but that grew. It's a big project, and your sense of what it even means to step back and see the big picture keeps changing. I can think bigger now without dropping into UI specifics.

The other thing is that I have a perfectionist streak, sometimes to a fault. Measure twice, cut once (but more like measure 45 times). Optimize taught me the value of shipping something that works relatively well and understanding that it will evolve. Change is inevitable with any product, I've been grateful for times I didn’t sink tons of hours into what was going to evolve regardless. It’s also important to consider what elements are needed for a feature to hit the minimum valuable bar (not just viable). 

Jing: How would you help someone shorten that lesson?

Emily: Have a vision for the end. Design with that intentionality, but don't detail every part of the blue-sky idea. Understand the building blocks and how the pieces fit, and be okay with some "we'll figure that out." Let go of the next step's details while still knowing what the next step is. That being said, know that change is not only possible, but likely.

Having experienced this, what's a hill you'll die on?

Emily: The most important thing is always “does it solve the problem”. Other than that, I do think whatever you ship should be high craft — in the UI and in the product thinking. I care about something feeling well designed, almost from a point of pride. It's important to me that it's the correct number of pixels. That taste is a critical part of a designer’s job.

The part that stays with me from talking to Emily is the inherent tension between quality and speed, the discomfort of erring too much on one side or the other, and how we resolve that as designers. Moving fast doesn't necessarily mean lowering the bar; it means shrinking the scope to something valuable enough to learn from, and holding that smaller thing to a high standard. The skill Emily cultivated with Optimize is one every strong designer has to develop: telling the difference between "this isn't ready" and "this could be better, but it's worth shipping." Everything moves. Taste is how you decide what's finished anyway.

We're hiring on Scribe's team. If this sounds like how you want to work, we'd love to talk.

‍