How to Write a Software Design Document (SDD)

If you are a developer, reading and writing software design documents – also known as technical specification documents – is part of your routine.

It is also the part that everyone loves to hate, so before diving deeper into what makes a software design document great, it’s important to remind ourselves what it is, why we need to write it in the first place, and what impact it may have on the ultimate success of your project.

What is a software design document?

IEEE defines software design documentation as “a description of software created to facilitate analysis, planning, implementation, and decision-making”. In essence, a software design document (SDD) explains how a software product or a feature will be built to meet a set of technical requirements. If the requirements document describes the “what” of your project, the design document focuses on the “how”.

It serves as a guiding document for the development team and other stakeholders throughout the project. A well-written, comprehensive SDD should contain all the information which may be required by a programmer to write the code.

As software development methodology evolved, software design documentation has been the target of strong skepticism. “We don’t have time for design documents,” is something you may have heard often. There are many who consider the design doc obsolete, a remnant of a long-gone era of software development that has no place in agile documentation.

Why write a software design document?

The software design document in its original form may indeed be irrelevant today. A rigid, long, MS Word document that becomes outdated the moment it’s written and is never read by anyone has no place in modern software development.

Our workflows have evolved – and so should the concept of a design document.

While an important function of a software design doc is to communicate the technical details of the planned solution to your team, it’s not the only reason why it’s written. The objective is no longer to create a detailed, fixed blueprint for your design and serve as documentation later on. It’s to help you organize your thoughts before wasting a bunch of time implementing the wrong solution or the solution to the wrong problem. It’s a collaborative exercise for your entire team.

As Angela Zhang, an Engineering Manager at Plaid puts it, a detailed and thorough design document remains “the most useful tool for making sure the right work gets done”.

If you are working as a freelance developer, a design document can also save you a lot of trouble down the road by helping you avoid potential disagreements with your clients and adding clarity to the agreed-upon goals. “Without this document, you’ll end up in a loop of acrimonious equivocation, clients disputing what they told you or what you told them, angrily sending cut-and-pastes of previous communications, interpreting and arguing until the time comes when the client demands that you make changes,” warns Christopher J Fox, a freelance Software Engineer with 30+ years of experience.

The anatomy of a software design document

A software design document describes the solution to a problem. So naturally, since every problem is different, there can be no one-fits-all template. No two software design documents are alike.

Here’s what a software design document could look like in Nuclino. Nuclino is a unified workspace where you can not only collaborate on design documents, but also build your internal knowledge base, collaborate on internal documentation, plan sprints, onboard new employees, take meeting minutes, communicate asynchronously, and bring all your team’s work together in one place.

While your project may require a custom design document structure, you might want to consider including some of the following commonly used sections:

Overview and stakeholders

The title of your design document and the list of people planning to work on the project. A high-level summary that every engineer at the company should be able to understand.

Context and goals

An explanation of why this project is necessary and how it fits into the overall strategy. A description of the expected impact and the metrics that will be used to measure success.

Proposed solution

A specific, detailed proposal for a new technical architecture.

Timeline

The breakdown of how and when you plan on executing each part of the project.

Of course, there is no such thing as a definitive design document template. Many alternatives have been proposed, some simpler, some more detailed. The choice would strongly depend on the scope of the project and the size of your team. However you decide to structure your SDD, the important thing is to find the format that works for you and your team and continuously iterate on it.

How to write a great software design document

The style of writing a software design document is purely subjective and usually a matter of personal preference. However, a design document would only be useful if it’s actively read and updated, and while this usually isn’t the most exciting thing to read, there are a few ways to make the experience more engaging.

Make it collaborative and invite feedback

Everyone working on the project needs to be involved in the process from the start. Keep it collaborative. It may lead to a lot of discussions early on, but it will save you time getting everyone on the same page later.

There are many collaborative documentation tools that can facilitate such workflows, including Nuclino. “The important thing is that there be a way for your team members to be able to make comments on the document and point out errors and omissions,” said David “Talin” Joiner, a game programmer and former software developer at Google+.

Make it visual with charts and diagrams

In many cases, visual aids, such as charts and diagrams, can be more helpful in conveying your point than plain text. In Nuclino, you can embed live diagrams by simply pasting a shared link from draw.io, Gliffy, or Lucidchart.

Be thorough

Don’t leave things out – even the things you are confident you won’t forget. Ideally, it should be possible for anyone other than you to understand and implement the design as written, in your absence.

Don’t write it in Word

As mentioned earlier, software development is a collaborative process, and feedback loops and reviews are crucial for a successful outcome. Word is a great tool that has its applications but it’s also rigid and closed in nature. Writing a design document in Word would virtually guarantee that no one will read and let alone update it.

An ideal tool for writing an SDD is open, collaborative, and organized – Nuclino aims to be such a tool. Keep your design docs easily accessible to all stakeholders by keeping them in your shared drive or your internal knowledge base, making them easily discoverable and searchable.

Don’t make it too long or complicated

There are no set rules about the length of a software design document. But keep in mind that the longer your document is, the more effort it would take for you to keep it up-to-date and for your readers to absorb. Keep it under five pages if you can and use clear, simple language when describing your solution to your team.

“Don’t let your desire to show off how clever you are become a distraction,” recommends Joiner.

Don’t let it become outdated

“The design will evolve, and the changes should be captured in your document. In my 25 years of experience, I have never once worked on a project where this didn’t happen. Even then, I created a design document with detailed specifications, and adjusted it as necessary,” explained Christopher J Fox, former Senior Engineer at Microsoft and RealNetworks.

Your design will evolve, and so should your document. To keep all the stakeholders on the same page, you would want to update the document every time you make changes to the original solution or update the scope or timeline of your project. To draw the attention of the stakeholders to a particular update in Nuclino, simply @-mention them and they will get an instant notification. Track the evolution of your design document and restore earlier versions if necessary using the version history.

As your project moves forward, the design doc will be there to keep everyone on track, saving your team from getting buried in details and keeping in mind the larger vision for the product. And if you end up losing confidence in the proposed solution while writing the document, see it as a win rather than a waste of time. As long as the design document helps you weed out projects that are not practical or viable, it was worth the time you invested in writing it.

Nuclino: Your team’s collective brain

Nuclino brings all your team’s knowledge, docs, and projects together in one place. It’s a modern, simple, and blazingly fast way to collaborate, without the chaos of files and folders, context switching, or silos.

• Create a central knowledge base and give your team a single source of truth.

• Collaborate in real time or asynchronously and spend less time in meetings.

• Manage and document your projects in one place without losing context.

• Organize, sort, and filter all kinds of data with ease.

• Integrate the tools you love, like Slack, Google Drive, Figma, Lucidchart, and more.

Try it now