After 10 years of working at large companies with thousands of employees, I recently joined a 10-person startup. It’s called Rewind (more) and I am absolutely loving my new role for a lot of reasons. It’s a bit different from my previous roles: I’m a product designer but I also spend time building my designs in Xcode. I love having a hands-on route to directly affecting product quality.

Much of my career as a designer has led me to hold product and design quality in the highest regard. It’s not easy. I want to be proud of the things I ship and put my name on them (see also). That 10 year old post from Bryan Haggerty is still as true as ever:

“With small teams, the output, whether it’s an app, web site or any other product, represents the people behind it and the tremendous amount of effort they expended to make it. And it’s common for those people to willingly put their name on it, taking accountability for what’s great and what needs to be improved.”

I’ve worked on numerous projects with large teams where the work shipped felt like a string of excuses—a reflection of tight timelines, cut scope and endless constraints. It never feels great to ship something to real people that is not an accurate representation of the intent you and the team had.

Crafting high-quality software, according to Stable Diffusion AI

As a designer I’m motivated not only by identifying and successfully solving problems for people through software, but also by the care, attention to detail and craft I’m able to put into it along with the team.

I want someone to use something I’ve created and feel that was intentional. That it not only had their exact needs in mind but went beyond to care about the details and have personality. This is a post about well-made, high-quality products and why shipping quality is hard.

I’ve always been something of a hybrid designer and developer. I initially studied computer/electrical engineering when I went to college in 2004. Eventually I felt that was too far removed from the end user experience of the devices we use. I transitioned to a major that combined design and computer science. However, when I graduated I felt like I wasn’t great at either. I spent the 5 years after college working on several startups I cofounded before landing at Twitter in early 2013.

When I joined the Twitter design team I was designing in Photoshop. For things that demanded higher fidelity, I would dive into After Effects to make small UI videos—a far cry from the interactive mobile prototyping we take for granted today.

The next year I became immersed with interactive mobile prototyping. I fell in love with a Javascript animation library called Framer.js—it felt like a superpower. I could make fully interactive prototypes for web and mobile experiences that felt real (old examples here and here).

Prototyping got me a step closer to what the actual product would feel like. It was my interactive canvas for testing out ideas and concepts rapidly. Prototyping dramatically elevated my design process, helped me think through implementation details, interactions, motion, and communicate concepts.

Of course, while high-fidelity visual designs and a complete interactive prototype can help you communicate your concept and get people excited, it won’t help the final product get built.

For that you need a lot more. You need to make your case for what the problem or opportunity is—most often validated with at least directional data and/or research insights—and why your specific solution could work. You need to ensure it weaves into broader company initiatives as well as goals for your team and org. And you need a plan to get your product out there in a timely manner along with ways you’ll further learn and validate your approach. An executive team won’t be thrilled to hear you want to spend a year building something based solely on a hunch.

That’s where the challenge of building quality products starts to creep in. The constant tension of shipping faster versus shipping better. Falling into a cycle of “Ship, then iterate” is a trap. It ends up being more shiterate. Things happen and that “fast-follow” V1.1 release or V2.0 you had imagined probably won’t. There’s always a new shiny initiative, re-org or new leadership hire that throws a wrench into things and changes all plans. Don’t rely on a future release to clean up today’s mess.

Having spent many years going through this constant quality versus speed tug-of-war I focused a lot of time and energy on product strategy as part of my design process. I crafted a story about our customers to our teams and leaders. I wrote a ton of internal documents; product briefs, design briefs, customer problems, product opportunities, vision, et cetera. I spent time evangelizing efforts, working on decks to show where we could go, how we could get there and what it could unlock, while addressing the opportunity cost as well as challenges like built-up tech and design debt.

But even that doesn’t ensure that the thing you’ve designed will result in the high-quality shipped solution you envisioned. There are a lot of reasons why shipping well-crafted, quality products is hard, especially on a large team.

What is quality?

And why is it so hard?

I often use the word quality when referring to apps, products and services I hold in a high regard but another word that often comes up in this context is craft. Craft, as in something that is handcrafted where something someone spent a lot of time on and maybe even embedded their own personal touches and personality in it. Often something handcrafted feels more premium.

There’s a reason high-end car manufacturers boast about their handcrafted cars. Something so premium that an individual person spent time obsessing over the details. Some even prominently display a plaque on the engine with the signature of the engineer that built it. This goes back to that quote earlier about putting your name on something and taking accountability.

Quality and craft are not just words designers toss around when referring to some veneer of polish adorned on top of a product with superficial visual design tweaks and unnecessary, over-the-top animations.

Quality is all-encompassing.

• It’s accessibility so that everyone can use it.

• It’s performance and ease of use so it respects the user’s time and helps them accomplish their tasks when they need.

• It’s reliability so they can feel good about having this tool in their pocket for when they need it.

• It’s durability with designs and components that can scale to withstand future needs and uses.

• It’s well-considered.

• It’s the feeling that a lot of time and care went into creating the product: that someone has already thought of you.

• Of course, it can also be a bit extra and bring delight in unexpected places and important moments.

Apple gave a talk about the qualities of great design where they interviewed people on their thoughts around quality:

Quality happens throughout the entire project whether you’re cognizant of it or not. It happens when identifying the customer problem to solve, designing a solution, validating it, building it, maintaining it, and even when you sunset the product. A focus on quality drives a way of working in which you dynamically either embrace constraints when you need to or challenge them when you see an opportunity.

People hire services not just based on what they can do but how it makes them feel.

Quality has a direct relationship to that. Quality products can take your users from “I’m merely using this thing to accomplish a task” to “this is something I love using and I’m telling everyone I know about it.”

I’m writing this article in a macOS app called Ulysses right now. I love it because it’s quality software. It’s approachable, actually easy to use, fast, and I can personalize it to my taste.

It makes me feel good about the work I’m doing. I could have written it in a myriad of other text editors filled with bells and whistles but I chose Ulysses because I know I can rely on it to let me focus on what I’m trying to write. Quality products make me excited to use them.

If we all generally agree that quality is a good thing, then why aren’t there more high-quality apps and services out there? Because quality is hard.

What affects quality?

Lots of things can affect the quality of your product, especially on large teams, including culture, incentives, skills and tools. Here’s just a few that are top of mind:

• Leadership, organizational support and incentives. Does the organization care about quality? What does quality mean to them? How does it tie into the career ladder, promotions and prioritization frameworks? Do they focus more on execution speed over quality?

  Is quality baked into the normal product development process, or is it often relegated to low priority “polish” tickets that pile up. Will leadership pause a launch if the quality is below their bar? What is that bar?

  If support for quality does not come from the top, it’s far too easy for ICs to skirt over issues and pay a little less attention to details they think their reporting chain won’t notice.

  Do different roles (like engineering, product, design) have different motivations for getting their work done? This, again, ladders up to what the org thinks about quality.

• Culture around quality. To maintain a shared, company-wide understanding of the company’s specific stance is on quality, how does quality get rewarded, celebrated and prioritized? Is there a process in place for delaying a release and having a retro when the quality bar slips? Who decides when quality has slipped? Who’s accountable for addressing it?

  Does everything need to have the same level of quality at the company? Are there certain things that need more or less? Unclear alignment around what deserves quality amongst teams can lead to issues.

• Trouble identifying issues. Do you have the right people with the right skills and motivations to flag quality-related issues? Do they have the right tools?

  Focusing on quality is often thankless work. Tons of time can go into rigorously testing builds, logging issues, providing feedback and coming up with solutions given the constraints.

  Does everyone have an eye and the time for design QA? For the items that are more visual/motion related, are the designers skilled enough at visual design to even know there are issues or be motivated enough to address them? Are there other designers they can rely on on the team for pixel-level details if that’s not their strength?

• Poor ticket/engineer fit. The onus is not just on designers to help identify and document issues to be addressed. What happens when a particular engineer picks up the next ticket and it involves a specific set of knowledge they may not have, for example like knowing about the nuances of animating collection views on iOS.

  Does the engineering manager wait until there’s an engineer better suited to tackle this ticket? Does the assigned engineer compromise with the designer on a solution if this is too intricate to tackle for them? What resources does that engineer have at their disposal?

• Inadequate tooling for effective design/engineer pairing. Back when a designer and engineer might have worked in the same office with each other, they could sit down to iterate on a new build. They could easily try 10 or more different values for a specific animation, build and test together over the course of 30 minutes.

  Contrast that with the new way of working remotely. The designer may feel less comfortable going back and forth suggesting small tweaks to engineering builds, so they only suggest a few iterations so as to not feel like they’re annoying the engineer too much. And these iterations will be less refined because the pairing iteration speed is so much slower. Do you send over ipa/apk files? Does the designer have the dev environment setup on their machine and pull the branch to build and test themselves? Or, worse, does the designer just have to wait a day or two to be able to provide feedback on a build when the code is reviewed and merged into an internal dogfood build they can easily access.

  Relying on screenshots and video clips sent over Slack can only get you so far. Perhaps in the future there will be tools for this. I’d love something like high-fps, low-latency interactive VNC sessions for remotely controlling someone else’s Xcode simulator for example.

• Liberal use of “MVP” or “it’s just an experiment”. Does the team use those terms to skirt around typical quality standards and ship something subpar? Does everything worked on, even experiments, demand the same care as a more mainstream release that goes out to all users?

  That’s a slippery slope because it’s all too easy to simply ramp up that experiment to 100% of your users if it performs well, without addressing quality issues that were neglected prior to shipping to that initial set of users.

  No one wants a slice of cake that is just a piece of the bottom layer. You need to have a taste of each layer with each bite, including the icing. So even if it’s not your entire vision, it has all the right pieces involved. Ditch the term MVP and use SLC (Simple, Lovable, Complete).

Most companies struggle to prioritize small quality and “fit & finish” design issues. On their own, these tickets seem like they’ll have remarkably low impact for the product. How will fixing the alignment of this button help us have a better launch, higher customer retention or a more stable app? However, compounding effects come into play with this kind of work. One or two of them won’t make a difference. But when you’ve fixed a dozen or so? It’s noticeable.

Building that understanding into the way you work is key. But it’s not the singular solution. It still goes back to many of points above. Does your team have the skills and incentives to identify and adequately fix those issues? Does the organization continually reinforce and celebrate work that ladders up to quality, craft and great design?

I didn’t write this section aiming to get to some sort of grand revelation about how you can build great software with one simple trick. Quality is hard.

I’m not saying designers, PMs and engineers should be holding up their projects for months to “get it right”. I’m saying that teams should be working in a way where everything is considered and there’s a framework for identifying, discussing and prioritizing quality-related issues so that quality is a bit less of a sisyphian task.

“But the desire to ship quickly was counterbalanced by a demanding, comprehensive perfectionism. Most commercial projects are driven by commercial values, where the goal is to maximize profits by outperforming your competition.

In contrast, the Macintosh was driven more by artistic values, oblivious to competition, where the goal was to be transcendently brilliant and insanely great.”

Quality is a way of working

It’s not something you’ll get to later

We’ve identified that quality is hard and that it’s tied to a whole slew of things from culture and leadership to experience and tools. Quality is the way you work. Focusing on quality doesn’t have to mean that suddenly your project scope has become bloated with a slew of tasks that will take 25% longer to complete. It can be prioritizing more complete, well-considered chunks of functionality (goes back to the SLC concept above).

What doesn’t work in my experience is marking tickets you can’t get to before your deadline as design debt, tech debt or polish to tackle later. Polish is an easy word to equate to design tickets but it’s an especially poor choice as most people tend to think it’s defined as optional, obsessive and unnecessary details.

I’ve been immersed in thinking about and working on quality for years at large companies. It’s insanely hard to change a company’s perception of quality and process, but here are a few things that help:

Balance long-term and short-term design

Build a working style that always pairs thinking about the long-term design direction of your surface area along with the short-term. By only thinking short-term it’s far too easy to design or build yourself into a corner, only too realize you’ve built a cluttered UI or relied on complicated interactions and flows. Doing so also helps you become a strong ally to your product partners so you can craft a story of where you see the product going and how it could potentially best address customer needs in the future.

I used to think doing long-term (so-called vision work) was bogus. Designers would get assigned to these “vision projects” by various executives, spend months on some explorations and a deck, only for the work to be archived in some internal wiki, never to be touched again. They tended to be run only by designers, not informing or consulting with adjacent roles and teams along the way.

As much as designers want to go off in a corner and come back with magical designs and a roadmap, this really needs to be a team effort, even if your stakeholders are more in the “inform” role of the DACI framework.

Close the gap between design and engineering

Bring design and engineering closer. There’s still a ton of onus on the designer to help illustrate and share their vision with their team. Sometimes designers are limited by what they can make with the tools at their disposal and their skills. If they can’t design or prototype at least a sliver of what’s in their head, how can they expect their engineering counterparts to not only build it but build it well? It may even limit the types of design solutions you explore if you’re unsure how to even communicate it. However, by building stronger relationships with your engineering coworkers you can try to bridge that gap more effectively.

For me, Figma is where initial hunches live; a starting point. Not final designs. it’s not until I start building and really using it that I get more signal to understand what aspects of the design feel good and which aspects don’t. That’s a big reason why I dislike teams that treat their visual designs as complete and “ready for handoff.” Please, never treat design as something you just handoff to engineers. That’s a great way to devalue the contributions of the engineers on your team and lead to a worse product. Treat it more like a conversation between design and engineering.

Some larger teams have dedicated prototyper or design/UI engineering roles. That’s one way to help bridge this gap, though for me they always felt one-step removed from product design and I wanted to also be leading the design in addition to coming up with the final solutions. If you have these roles, it’s important to not just assign them from project to project merely to prototype something a team needs for a research study or other short-term need. Instead, have them paired up with design and research for 100% of the project.

It’s also important as a designer to know when to push on something and maintain your quality bar and when to compromise. That’s your superpower. Everyone will hate working with you if you hold a high quality bar but don’t know how to work within the context of your business goals and customer needs. Getting as close to the technical side will help you. Here’s a good post on this topic from an engineer’s perspective: Effective Collaboration with Product and Design.

Then there’s tooling that can help improve speed of iteration; making it faster for designers to receive and test builds from engineers (as mentioned in the previous section). And finally, provide resources for engineers to learn more of the intricacies of front-end development, UI and motion frameworks. This may be more important for companies that tend to hire more full-stack engineering roles.

Of course, all of this gets a lot easier if you’re a designer who can also code your designs.

Determine what quality means for your team & set your quality bar

Depending on the company, industry and team, quality will mean different things. For one product and customer type it may mean a huge focus on reliability and speed while for another it may be a focus on delight and attention to detail.

A shared understanding of what types of work meets and what type of work doesn’t meet your quality bar, along with executive support, can help with prioritization. Doing so can help realize the compounding effects of smaller quality and design tickets.

This entails understanding how a user-facing visual refinement is a very different type of ticket than something like a performance bug or crasher. If you only have one type of work queue, it’s very easy to only prioritize the bugs and crashers. But when do the other types of quality tickets get prioritized? Try to dedicate a certain amount of time to each type of work for each sprint. This goes back to the SLC concept: you want your slice of cake to be vertical so you can taste all the layers, including the icing (yes, I love this silly analogy).

Don’t always jump to using existing patterns

This is probably the most controversial one. In the design industry there’s a remarkable push behind design systems. They have a myriad of benefits including speeding up design and development time, making it easier to maintain accessibility, as well as evolve and maintain large surface areas in your product. But if design systems are not run well, they can hold you back.

Poorly run design systems can preclude valid design explorations in pursuit of consistency and efficiency; just using what’s already there.

For brand new products, don’t to be too eager to start on a design system. You often don’t know what this thing is yet. You don’t know where the product is going, what needs to scale, what the customer needs are, how they’ll react to your initial version or what the personality of the product will be.

But this familiarity with existing systems can get in the way of helping you tackle new kinds of problems. You may prematurely bucket it into a problem you’ve seen before. Design systems are just one of the tools at your disposal. Applying your design systems thinking (or any other patterns you’ve worked with before for that matter) all too eagerly may prevent you from noticing the obvious. That maybe there’s a different way of thinking about the problem at hand. Apple touches on this a bit in this video about intentional design.

A related tool I like to employ sometimes, especially to break out of my own personal design aesthetic and tendencies, is to ask myself, how would [another company] design this? I might think to myself “Airbnb loves to have these huge headers, bold colors, dynamic cards and sheets, so they may approach it like this.” Then I’d mock that up.. and do the same with other companies. I may hate it, but it will get me thinking.

Sunset or re-evaluate old functionality

Incentivize and commit to sunsetting features that are no longer your core focus, have low usage, or are otherwise detrimental to your product. If you work on a product with millions of users, even low usage things will be sizable and may have secondary effects that are hard to gauge. This is hard, thankless work. It requires support from leadership to allow a team to focus on removing something instead of spending that time that could more directly move tangible metrics.

But without this rigor, your product could all too easily become cluttered, slow and become harder to maintain over the years.

Use what you’ve built before you ship

I’ve seen it happen all too often. You’re working on a project. You build a prototype and work with a researcher to get some initial qualitative feedback or you ship a small experiment to gather data. By the time the research insights have been finalized or the experiment data has had enough time to account for novelty, you don’t have much time left to explore significant refinements or alternative design directions. Your team is already on the hook to ship this before the end of the quarter or has tight timelines to get this code merged before the biweekly deadline to ship to Apple. So you end up compromising with a less-than-ideal refinement, even though you don’t think it’s the solution your users really deserve.

Always leave adequate time after gathering new insights to not only design refinements, but build them and live with them for a bit first. It’s too easy to compromise on quality in the face of existing timelines.

Joining Rewind

Why going to a startup is the perfect fit for me

Earlier this year I decided to leave my job, focus on my wedding and take a few months off. I had a lot of time to think about what I wanted to work on next. I wasn’t sure if I wanted to join another large company, a startup, or transition to contracting with a few companies.

One thing was clear though. I wanted a different kind of design challenge. Designing for mobile had started to feel boring. It felt so repetitive. The same constraints. It felt like I was just going around employing the same few patterns, especially when working on larger teams less interested in taking risks and trying new things.

It would be a bonus if I could find a company where I could more readily influence product quality by diving into the codebase myself. I had a strong desire for interesting work with a great team where I could be proud of what we built together. That’s what we all want right?

Dan Siroker happened to reach out to me around this time. Dan and I had crossed paths a decade ago in Y Combinator when he was starting Optimizely. We caught up and Dan showed me what he had been working on, complete with a live demo of Rewind. I was blown away by the ambition and concept. I immediately grokked it.

Rewind is the search engine for your life. It’s a macOS app that fully utilizes the capabilities of Apple Silicon and macOS Ventura to record everything you see, analyze it and make it searchable in real-time. All while being private by design—everything is stored locally on your machine.

Rewind helps you out in those situations when you’re racking your brain try to remember where you saw something. Can’t find that tweet you know you saw once? Or wish you could go back 15 seconds to recover that long performance review you were writing before your browser crashed? You can search or rewind time. Once you’ve found what you’re looking for you can even copy text from it.

It’s the exact type of design challenge I was looking for. First, it’s a full-screen immersive app with no peers like it. There’s no playbook or existing design patterns for how to design something like this. Second, there’s a ton of privacy implications to ensure people feel safe using Rewind and know that they’re in control. And finally, since there’s no product quite like this, there’s a lot of hard product design and research iteration on the journey to find our specific product-market fit.

All this to say that Rewind was exactly the kind of team and company I was looking for. The product has the potential to change how we interact with computers.

How does joining a startup relate to craft and product quality? Isn’t it harder for a small company to ship well-designed, high-quality software? Aren’t most startups busy scrambling to find PMF, scaling infra and putting out fires?

There’s no debating one aspect of startups compared to large companies with thousands of employees: startups are dramatically faster. Faster to make decisions, plan and build. You can talk about something in the morning then design and build it the same day. No more waiting until the next quarter.

But the main reason why I think it’s easier to influence quality on a smaller team is that I’m able to have a more general design role. I can be relentlessly resourceful and put the full extent of both my design and engineering skills to use. And the best unintended side-effect? I’m also learning more on the coding side as the talented engineers I work with provide tips and feedback on my code reviews.

I’ve only been at Rewind for a few months but this has been the exact kind of role I’ve been looking for for the last decade and I’m confident we’re going to build some great stuff. (And if this sounds interesting, we’re hiring).

Quality is hard

With the right team culture, process, tool, education, and incentives, achieving a higher level of product quality should be more attainable without dramatically impacting speed of execution. I’m not saying it’s easy. Quality will always be hard, but don’t you want to make something great?