Compare commits
1 Commits
master
...
design-doc
Author | SHA1 | Date | |
---|---|---|---|
c407728f3b |
BIN
rauhala.info/images/sample-designdoc.png
Normal file
BIN
rauhala.info/images/sample-designdoc.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 168 KiB |
BIN
rauhala.info/images/stakeholder-architect-design.png
Normal file
BIN
rauhala.info/images/stakeholder-architect-design.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 35 KiB |
41
rauhala.info/posts/2022-08-19-design-docs.md
Normal file
41
rauhala.info/posts/2022-08-19-design-docs.md
Normal file
@ -0,0 +1,41 @@
|
||||
---
|
||||
title: Design Documents
|
||||
tags: design
|
||||
---
|
||||
|
||||
We had a problem at work some time ago, with implementing features faster than
|
||||
we could refine new items. The roadmap was a mile long, but the quality of our
|
||||
work items left a lot to desire. The solution was to have more concerted effort
|
||||
into the act of designing and refining. One part of this effort was the
|
||||
introduction of design documents to our workflow.
|
||||
|
||||
[Design Documents at Google](https://www.industrialempathy.com/posts/design-docs-at-google/)
|
||||
|
||||
![](/images/sample-designdoc.png)
|
||||
|
||||
We have been experimenting on using design documents for a little over half a
|
||||
year now and have been able to refine them to suit our processes quite nicely.
|
||||
Feel free to read the article above, it's a concise explanation on how they're
|
||||
using design documents, and what I'm going to write is going to focus on a
|
||||
subset of the article, on the aspects that I have found to be important.
|
||||
|
||||
## What are design documents
|
||||
|
||||
![stakeholder-architect-design-loop](/images/stakeholder-architect-design.png)
|
||||
|
||||
When designing a new feature, the stakeholders have a set of requirements they
|
||||
need fulfilled. The product owner collects the requirements and provides them
|
||||
to the architect to be solved. It's this solution, that needs to be portrayed
|
||||
by the design document. The design document should portrey the high-level view
|
||||
of the design, without implementation details, in a way that the developers can
|
||||
take the design and implement a concrete solution.
|
||||
|
||||
### What should the design document contain
|
||||
|
||||
> A feature to add items to a shopping cart. The items needs to be reserved in
|
||||
the backend so that the reservation is synced across different users.
|
||||
|
||||
The design document should be written on a high level, it should explain the
|
||||
problem and it should explain the solution for it, but it should not be the
|
||||
implementation guide. The design document should not contain any code or
|
||||
pseudocode in it.
|
Loading…
Reference in New Issue
Block a user