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

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.

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.

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).

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


  1. Know how the existing product platform and functionality work back to front. Understand the business goals, user needs, technological constraints.
  2. Break down the user journey to decide on the right KPIs.
  3. 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.
  4. The final deliverable is user stories. Ruthlessly prioritize them.

II. Design


  1. Rule of thumb — the greater the confidence you have in the solution, the higher the fidelity.
  2. Use real content in your wireframes to make sure the UI won’t break.
  3. 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.
  4. Prototyping should be integral to the design process — it helps you discover usability issues, especially in the absence of usability testing.
  5. 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.
  6. 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.
  7. Designing better does not always mean more engineering time.

III. Testing and iterating


  1. Document every session through recordings and notes, and finish each study round with actionable insights and executive summaries.

IV. Hand-offs and follow-throughs


  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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


  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. Make sure every relevant stakeholder agrees with the product release through an official or unofficial sign-off process. No one wants to get shocked.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store