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

Context and Relevance

Who Fieldnotes is for:

Principles > templated process

Let’s get started

I. Project kick-off and discovery

  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

  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

  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

  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

  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.

--

--

--

Product Designer + PM → laijingchu.com

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

How Emily Welsch is using fashion and chemistry to close the gender gap in cycling with Pixi

Prototyping Sprint

Designed Space chats with Mark Fleming

UX of UP: Urinals and Usability in the U.P. (Upper Peninsula)

Redesigning Twitch App — First UX case study

Data Vault Advent Calendar 14/25

YouTubes New Dark Theme

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
Lai-Jing Chu

Lai-Jing Chu

Product Designer + PM → laijingchu.com

More from Medium

11 lessons from a long November walk

Design is the Strategy

7 levels of design maturity

CHRONICLES: Crafting the product that will positively affect the lives of 1 million people with IBD…

What software should I use to make my presentation?