Design Documentation

[gleaming echo]

As a PM, I only ever look at design documentation to:

a) help with design QA (are things aligned on the screen? Does it use the same component?), especially since most designers tend to have their own "style". Just making sure they're sharing the same assets essentially and that nothing looks wildly out of place.

b) If the design system is more mature (i.e. On Figma, you can drag and drop components), then I'd use it to make screens of my ideas. This helps when I'm talking to my designers about a new priority or feature on the road map, but most companies including my own don't have this level of complexity, so I usually use simple boxes that my designers refine.

I've always viewed design documentation as a tool for design teams to push for more consistency across the board, especially when working with engineers. If you're using it to get buy-in from external stakeholders, I'd rather much see a slide deck or something that details the purpose and metrics of your design.

i.e. This redesign of the signup flow aims to increase # of new users by XX.

And then you can go in-depth about every little choice you made (button placed here increased click rate by XX%) if you'd like, but I wouldn't consider that design documentation if I'm being honest. More like... design report? And this is something you'd ideally work with your PMs or Analytics team since they'll have the numbers.

Ah, but if the broader question is how do you document design I mostly see sections on:

1. Color
2. Typography
3. Spacing / Grid layouts
4. Icons and custom pictures
5. Components and different states (active vs. inactive)
6. Screens of the app (Page for log in, page of sign up)

[fair anchor]

I see, this definitely helps me better hand-off design, because I start to see the purpose for hand-offs is definitely helping QA a lot. But I guess now that you explain it in detail, it's the "design report" that I would wonder how to document one. The more like the "top-down" point of views such as the purpose of the design, the metrics, and things like that. But I'd definitely incorporate this in my documentation for my Project Manager and Devs.

But what do you mean when you said "use simple boxes that designers refine" because I too don't have a complex design system just yet?

[gleaming echo]

Basically a wire frame. Super low fidelity, and I just talk more about interactions and flow (like what happens when you click a button and why it should happen)

Example: The log in button should take the users to their profile because we want to show them the latest news articles so they stay engaged with the app longer.