Fieldnotes #1: Principles of an early-startup product designer

Around four months in as a product designer, I wrote this post to chronicle my guiding principles working as the only designer in a startup. Two and a half years have gone by, and as I’ve built up a bit more experience, I’d like to keep up the effort in documenting effective techniques that underscored my way of working and have tried and tested to produce positive results. This is the first article of a series I will call Fieldnotes.

Context and Relevance

Let me start by explaining the context of my experiences so you get an idea of how my notes may apply to you.

I’ve previously worked at two early-stage companies roughly a year each, both of which were actively fundraising at the seed stage. There were no product managers, project managers, or product owners. Given that early-stage companies are resource-scarce, I faced constant pressure to demonstrate ROI by “getting a valuable product out the door” rather than just “churning out endless wireframes.” To that end, I have created processes that streamline my workflow all the way from discovery research to shipping and designer’s QA, to the point that it was hard for me sometimes to determine which hypothetical job function an activity falls under. When I do research, am I doing it as a product manager or a researcher? When I’m writing out user stories and prioritizing milestones the roadmap, am I doing it as a designer or a project manager? It’s all one to me.

Such demands may be taken as an unfair situation where I was thrust into more responsibilities than I signed up for. However, as someone brand new to the industry, these challenges gave me the much-needed opportunity to demonstrate my abilities and shaped my DNA as a product designer. I gained the ability to speak to numerous “tough” questions that came my way in subsequent job interviews.

Being in startups, time is money, and different design decisions incur different design and development timelines. On the one hand, I’ve learned to establish a rhythm with engineers for timely launches, and on the other, I have learned how to set realistic expectations with cross-functional stakeholders. This involves the use of clear documentation and a very data-driven time-tracking process so that I can explain how every ounce of project team energy is being spent and why. In lean startups, mistakes are tolerated if not encouraged as long as they are made quickly, smartly and that you learn from them.

Who Fieldnotes is for:

I have started the Fieldnotes series to document some of my techniques and methods to help myself remember my own learnings and takeaways. There are a few principles that have served me pretty well in these environments (as I continue to learn more), and I hope that these principles can help designers bring value to their organization, advocate effectively for design, and come away from the experience with results they could be proud of.

I hope that by sharing my approach with others, I could help those who had just started in the field or had found themselves in an early-stage startup for the first time. Because of my first job, I was able to speak to a lot of tough questions that came up in subsequent job interviews, and that’s the gift that I was able to take away.

Seasoned professionals might also want to try their hand at an early startup, drawn by the sense of ownership and potential to make a bigger impact. Of course, there are many product teams in large companies that take a “startup-y” approach, in which case, some of these high-level principles might still be relevant. Now that I am working in a large company, I would not say that the principles here no longer apply, but rather, I have more to learn.

Principles > templated process

Unlike other articles that might tell you “how to run a design sprint,” “how to create user flows,” or even the “tips and tricks to using [X tool],” etc., the focus of this article is not the “how-to” (or the process), but the “what for” (the outcomes and results).

Projects, goals, teams, and methods and tools may change, but principles tend to be the same. Solid principles help us avoid getting stuck in busy work and cookie-cutter processes. My working principles empowered me to discover ways of doing things and still achieve satisfactory results even if it is the first time I tackle a given task. They had helped me grow, and in turn, I generated more principles.

I may not know every tool, method, technique under the sun. However, these general principles shed light on what I don’t know and guides me to decide what’s the next thing I should learn. The opposite of this would be just to post a bunch of templates for you to fill in, and the world’s had enough of that.

Let’s get started

The following is a list of guiding principles for how I conducted and paced my work. I may eventually convert some of the following points into individual articles — feel free to follow me if you are interested in staying in the loop.

I. Project kick-off and discovery

Principle:

The discovery phase is a means to derisk the project and increase confidence in each design decision. Resolve as many unknowns as possible so that you are ready to go.

1. Always conduct user interviews in batches and close time proximity to have enough data points to draw a conclusion.
2. Know how the existing product platform and functionality work back to front. Understand the business goals, user needs, technological constraints.
3. Break down the user journey to decide on the right KPIs.
4. Keep a paper trail for all the documentation, or else it is as good as not doing it. Create short, high-level summaries to communicate findings for busy executives — this is a good time to advocate for any resources you need or steer the project's direction.
5. The final deliverable is user stories. Ruthlessly prioritize them.

II. Design

Principle:

Catch usability friction points up-front by stress testing your own work, and keep good design hygiene to work efficiently.

1. Line up the user stories on Figma (or tool of choice), so you don’t miss out on any critical flows. Then start your design, whether that is low-fi or high-fi. It’s autopilot from there.
2. Rule of thumb — the greater the confidence you have in the solution, the higher the fidelity.
3. Use real content in your wireframes to make sure the UI won’t break.
4. Usability tests are just due diligence. Don’t hand off anything unless you’ve done them, or unless it is a very high-confidence solution.
5. Prototyping should be integral to the design process — it helps you discover usability issues, especially in the absence of usability testing.
6. Demo designs to stakeholders as a clickable prototype (or built engineering prototype). Avoid panning on the artboard. It is the difference between being in the driver’s seat and watching someone drive by from the sidewalk.
7. Maintain good design hygiene. Keep one source of truth for all components/symbols. Avoid breaking components/symbols. Use features like autolayout, nested components, and variants as much as possible so that down the road, it is easy to iterate on the design. Clean up layer order and names.
8. Designing better does not always mean more engineering time.

III. Testing and iterating

Principle:

Iterate to the reality of your users — the difference between “I’ll use this thing” and “I won’t use this thing” is often extremely fine-grained and nuanced.

1. With every interview or usability test, always batch 3~5 sessions within the timespan of a week. It is not worth having them few and far between as you won’t gather enough data points for a solid conclusion.
2. Document every session through recordings and notes, and finish each study round with actionable insights and executive summaries.

IV. Hand-offs and follow-throughs

Principle:

Don’t make engineers guess.

1. Think of your hand-offs as an Ikea manual—make it super clear and easy to follow with as few words as possible. Use flowlines in your wireframes so that others won’t have to guess the connection between two frames. Failing to do so, you’d be relying on other people’s imagination, and that’s never going to be accurate.
2. Make very functional logic and UI spec that you care about explicit to the engineers. If you think expressing them in human language is tedious, imagine writing them out in computer language.
3. Have a shared understanding of completion and success. Avoid the word “done” in progress checks with engineering: some engineers consider “done on local” to be “done,” while others consider a real deployment to mean “done.” If you’re not specific, I can promise you you’d never see the end of a project.
4. Name artboards and pages in ways that make sense to the viewer, or else you’re generating a ton of visual noise on the screen, and it’s very uncomfortable to look at.
5. Make a list of your own acceptance criteria upfront so that when you get to the QA phase, you are equipped to undertake the inspection. If you don’t do this, I can guarantee that you won’t be able to spot half the mistakes.
6. Establish a workflow for engineer’s work to check back in with you for your QA inspection before real deployment so that you can make sure the built product is aligned with your design intentions. At a small startup, your value is judged by the released feature, not the wireframes.

V. Product Ownership

Principle:

Once you’ve built a vehicle, be clear on where the vehicle is headed.

NOTE:The following list will not be your sole responsibility if you have a PM to collaborate with. However, as a designer, you can and should support your PM and engineering team to achieve the following:

1. Don’t say yes to everything — ruthlessly prioritize feature requests and bug fixes. Set up criteria to make these decisions. It takes time to develop a feature, and if you keep getting swayed, you will get nothing done.
2. Know which product metrics matter the most and target your effort at improving them. Finding out what they are and tracking can take energy and time but is well worth it.
3. Be responsive — if you’ve prioritized and promised to deliver something, don’t make the relevant stakeholder guess the status it is at. This is essential to building trust and rapport with the team and others.
4. Once you’ve helped establish a predictable rhythm of shipping work, start to build a roadmap so the rest of the team know what to expect.
5. All documentation is only as good as how updated they are, so make sure to keep them fresh by integrating them into your everyday workflow as much as possible.
6. Make sure every relevant stakeholder agrees with the product release through an official or unofficial sign-off process. No one wants to get shocked.