Member-only story
A designer’s starter guide to technical documentation
A short and sweet list of the long and dense documents designers need to understand for success.
It usually goes something like this.
When: any given day.
Who: a friendly engineering project manager.
“Ok. Great! I have to drop. Gotta bounce to my next meeting. I’ll get a kick-off on our calendars once the Ops gets the BRD and our FRD is drafted. But let’s not wait for TDD and we’ll sort out the Test Plans and SIT and UAT later. Do you need anything else? Sprint one started yesterday.”
Yes, this short essay is a document about documents — technical documents. Designers have their own catalog, and should have a command of what, why, and when to use each.
Equally, it is meant to be a starting point to understand the purpose of three key types of documentation that designers often face in software and product design, and insight about how each can best serve UX and UI practitioners.
As a designer, I see the aforementioned lingo as part and parcel of the job. The jargon itself refers to the reams and kilobytes of documentation that get produced during the creation of products and their subsequent features. Over the lifetime of a product, enormous amounts are written. Some of it might even get read. The documents and their titles, while not always consistent, are widely accepted as a standard in the industry. Lots of information about each type and points of view are available.
This is not another article about the niche literary genre of TDDs. This is an article for designers to offer some preliminary guidance and put the common types of documents into context.
These documents are meant to provide clarity, detail and define expectations and achieve consensus. To a designer, they often do the opposite. As contemporary product teams evolve and mature, design increasingly becomes a more central role. These documents no longer need to be a “read only” artifact for designers to struggle through.
If you better understand the purpose of technical documentation, then you can better contribute to their refinement, improvement, and in some cases, even help…
