DaS™ — Development Section
Overview
Welcome to the seventh article of the 3x3 series — Confluence for Designers looking at the communication structure for medium and large organisations to achieve transparency, which leads to frictionless and smooth design delivery.
This article will be opening the third and last pillar that utilises — Development [001↗], Releases [002↗], and Integrations [003↗] sections, building from what we have discovered, acknowledged, redefined, tested and designed to this very point.
“Documentation is like sex:
when it’s good, it’s very, very good;
when it’s bad, it’s better than nothing.”
— Dick Brandon
Every product team aims to empower developers in delivering well-written code that is easily deployable. The focus here is on the handshake between these two different functions and mindsets that neither one wishes to document.
In the same way, as the Design or Experience section is design-led, the development section has its specifics. Especially when it comes to setting up the environment, listing the APIs or reporting the releases in one place — every team I have worked with has a different method how documenting code.
Note of the author: Please acknowledge that the fact that…
