Thanks for sharing Ben! Really appreciate you sharing this.
- Could you share a bit more light on how you divide the work on specs between the designer and you? From what I understood this spec is the output of your collaboration, but how did you share the initial/concept idea with the designer - is there a 'spec' you create for the designer as well, or maybe parts of this doc were that initial spec?
- I understand that this specification is beneficial for everyone on the product team, so that you're sure you haven't missed anything important. But I'm also wondering how & when it's 'utilised' by the development team. Do they 'translate' this desc into tasks, according to 'Linear' method?
- It seems to me you've considered a lot of details prior to development. Is it 'a normal' spec for every project? Does it allow you to build/iterate fast enough? How long it took you to prepare it if I may ask?
For these longer specs, for bigger features, I tend to write the whole thing myself. For smaller things the designers write them without my input.
Before starting design, I usually write down the problem and some initial thoughts on how we might solve it. For a recent important project we have 3+ documents that describe the different problems and how we might approach them.
These specs are usually translated into Linear tickets, yes.
This would be normal for a bigger project. For smaller projects the specs are much lighter wait. This lets you build faster, not slower in my experience. One of the slowest things you can do is to have to throw out engineering because you built the wrong thing. This maybe took me a few hours to write.
Thanks for sharing this detailed PRD. Appreciate if you could answer the following questions:
1. How did you determine the specific color palettes and themes for the new charts? Were they part of an existing design system, or developed specifically for this project? Additionally, how did you ensure that the new chart palettes complement the existing dashboard colors?
2. How did collaboration between different teams influence the final design specifications?
1. The colors were not part of our design system. We felt this was more "content" than UI and so the design system doesn't really apply. We looked at all the different palettes in mockups on dashboards to check they looked good.
2. We're a small team, the design spec was mostly worked out by me and one of our designers. We sought feedback along the way though from the team and incorporated.
Thanks for sharing Ben! Really appreciate you sharing this.
- Could you share a bit more light on how you divide the work on specs between the designer and you? From what I understood this spec is the output of your collaboration, but how did you share the initial/concept idea with the designer - is there a 'spec' you create for the designer as well, or maybe parts of this doc were that initial spec?
- I understand that this specification is beneficial for everyone on the product team, so that you're sure you haven't missed anything important. But I'm also wondering how & when it's 'utilised' by the development team. Do they 'translate' this desc into tasks, according to 'Linear' method?
- It seems to me you've considered a lot of details prior to development. Is it 'a normal' spec for every project? Does it allow you to build/iterate fast enough? How long it took you to prepare it if I may ask?
Thanks for reading!
For these longer specs, for bigger features, I tend to write the whole thing myself. For smaller things the designers write them without my input.
Before starting design, I usually write down the problem and some initial thoughts on how we might solve it. For a recent important project we have 3+ documents that describe the different problems and how we might approach them.
These specs are usually translated into Linear tickets, yes.
This would be normal for a bigger project. For smaller projects the specs are much lighter wait. This lets you build faster, not slower in my experience. One of the slowest things you can do is to have to throw out engineering because you built the wrong thing. This maybe took me a few hours to write.
Thanks for sharing this detailed PRD. Appreciate if you could answer the following questions:
1. How did you determine the specific color palettes and themes for the new charts? Were they part of an existing design system, or developed specifically for this project? Additionally, how did you ensure that the new chart palettes complement the existing dashboard colors?
2. How did collaboration between different teams influence the final design specifications?
Hey, thanks for reading!
1. The colors were not part of our design system. We felt this was more "content" than UI and so the design system doesn't really apply. We looked at all the different palettes in mockups on dashboards to check they looked good.
2. We're a small team, the design spec was mostly worked out by me and one of our designers. We sought feedback along the way though from the team and incorporated.