How do designers log design decisions? How does a designer picking up a project from another designer find out why something is the way it is? 🤔

I don't know if this is a dumb question but what constitutes a "design decision"? I would think certain decisions are obvious.. For ex: something that is directly derived from a design system. I guess what I'm wondering is: How detailed would this be (ideally)

To be clear I think this is a good idea but it makes me wonder: a) who is this really for and b) is this potentially the result of an org not trusting designers to do their jobs effectively (whether it's the decisions themselves or justifying them)

I would also say that if designers are expected to do this kind of thing, I would also expect the same of other EPD roles.. It just seems like it would be unfair otherwise lol

Ok, so I agree with you that in some cases it can feel like there’s hidden micro mgmt / not trusting designers in there, in our case there was something very specific that led me to suggesting using Decision Records in the future..

We had to redo our company website & there were conflicting opinions about which platform / tech stack / etc to use. We looked at different solutions & made certain decisions & months later another lead designer swooped in and made a conflicting decision that changed everything.

So in that explicit case (leaving aside the fact that if someone is not in charge they should not be randomly making decisions like that, lol) it felt like we had reasoning for the original decision but this was not 100% documented 🤷🏻‍♀️🤷🏻‍♀️🤷🏻‍♀️

Ah, I see.. That does make sense and can lead to very messy situations. I do think this is something that should/could be co-owned by EPD as far as what's actually implemented and why. Design decisions are a part of it, but the "source of truth" is really what ends up being built

Basically just to say that in lieu of a designer (like if they leave the company, just as an example) the product manager/owner should also be able to speak to "why is this the way it is" if not someone else involved

I agree with you. But I also know from experience that sometimes something that seemed like a good decision 3 years ago wouldn’t be one 3 years later, and sometimes it’s much easier to have an actual record of the decision very clear on the page, not buried in the docs.

(Me speaking from the perspective of someone who was in PO/PM positions as well in the past)

I 100% agree, especially with keeping pertinent information in the actual Figma file. I think cross-referencing also helps though that can quickly become a convoluted mess loll

Maybe a way to cross reference neatly is the thing that needs improving... and getting people to actually document... that part of the process needs work too from what I see and hear

One thing I started doing Sid is to just create a master document of where everything is. It sounds tedious but basically I have a public (within the company) overview in confluence for each project I’m in charge of: where is the design system, where are the meeting notes, etc.

Sounds like a very similar setup! Making effective use of confluence and Figma for documenting in a way that doesn't duplicate info while still maintaining some sort of linkage feels most beneficial with the limitations they both individually offer

Great convo here and I agree that a decision register that affects the product shouldnt sit within the tools and rather be in a place where everyone can see them. Perhaps theres a place for finer details within tools like Figma.

ADRs are pretty great and we do use them. We created DHRs (design history rationales) but its interesting what goes in and its not very consistently used. Theres also a lot of friction involved here unfortunately

In case you’re not familiar with ADRs, this is an example of what it would look like, roughly: github.com/joelparkerhend…

architecture-decision-record/locales/en/templates/decision-record-template-by-michael-nygard/index.md at main · joelparkerhenderson/architecture-decision-record

Architecture decision record (ADR) examples for software planning, IT leadership, and template documentation - joelparkerhenderson/architecture-decision-record

github.com

This is a really good idea and I wish I’d heard of it 6 years ago

This would live in the same place where the documentation for the project lives (so mainly Confluence for us). Eng also started to introduce DRs/ADRs so it’s not that far off imho to do this for design as well.