A glimpse of the discovery documentation template I built for the enterprise company

How to document design discoveries on Confluence?

As a designer, I got told to document my design decisions early on in my career. Unfortunately, I didn't listen much to that advice because I was busy with execution. But spending just over five years as a tech product designer, I jumped into the world of documentation while working on a hybrid B2B + B2C company. I mainly designed low-code interfaces, conducted research, and churned out rapid iterations every week. All of the work I was doing had to boil down into a convergence point, and that's where a documentation format came into play.

Reasons for documentation

For me, these are some of the reasons I experienced before and after I decided to build my documentation template —

1. Documenting those decisions: Design documentation allows you to record all your past and present design decisions.
2. Room for more: Since design documents are open-ended, they can contain a lot of artifacts like past versions, supporting research, quotes from stakeholders, and learnings from past experiences.
3. Design influence: A good discovery template allowed me to build design influence uniquely across the team. I used this template for over 70 design discoveries and improved it whenever I got feedback.
4. Documenting changes: Documenting those pesky changes might be the most painful task of it all. But it is important to hand off essential projects to other team members onboard new product managers onto an existing project. It helps others understand why you had to make the decisions you took.
5. Building a portfolio of projects: When I documented over 70 projects in my last company, I influenced and created a massive wall of projects authored in my name. It allowed me to have a place to look back and revisit some of the design decisions. It also let me get known within various company circles. I saw many people I didn't connect with previously reaching out to me after they stumbled upon one of my design discoveries.
6. Taking charge: When I started documenting my design decisions, no one else wrote thorough product requirement documents (PRD), and all the information fell between the creeks. As a result, bad PRDs affected my design more than I could even imagine. Hence, I decided to take charge and do something about it. So, when I first started, my documents were more of product documentation, and then slowly, I added more to the template while also retaining the most relevant bits of the PRDs.

The Format

The way I designed this template was in three distinct folds or sections —

1. First fold: The stuff that business and product management teams needed, like business objectives, meeting logs, and internal links from Confluence and JIRA.
2. Second fold: This is where I build my research wall. User testing, personas, user flows, and more artifacts will help me or others to design the best solution to the problem at hand.
3. Third fold: This is the iteration space. I reserved this space for documenting all design iterations and the reasoning, feedback at each stage, and why I took the decisions, I said I took.

Although all three folds are quite information intense, I believe the first fold was where most eyeballs were gathered and attracted the maximum opinions. The second fold attracted fellow researchers and product designers. While the third fold mainly was for people entering into an existing project,

#1st Fold — Product & Business

Business Objectives

What business objective are we trying to address? Deliver value and achieve product vision. E.g. 10% increase in usage after <release_version>.

Outcomes & Key Results

Outcome(s): Which indicators predict the business objectives we seek? Usually, early indicators are in a hypothesis and eventually backed by data.

Key Result(s): What change in metrics are we looking to achieve to say the feature delivered business value?

Problem Definition

Elaborate the problems being attacked product outcomes as solutions that will impact these business metrics. What problem are we trying to solve for our customers?

Target Customer/Personas

Which customer/user are we solving the problem for in this feature?

Product & Engineering Interlock

Links

It can be any link. JIRA, Confluence links, and competitor links or related articles.

Figma Link

A link to the Figma file.

Prototype

Format: <version><date><link>

Different version/iteration prototype links taken from the original Figma file.

Meeting Log

Format: <date><meeting details>

This part contains a log of all the meetings related to the product feature. This section is helpful for product management and product designer alignment and the progress so far.

Risk/Blockers

Things that don't add up or will be problematic in the future.