Just recently I joined a new project with a big company who I would have thought had their design process already in place, but no. Just as many others (or most of them) they’re missing one big important part that everyone hates doing (not me) and that is documentation.
Be honest, besides your design, what other thing do you deliver to your Eng team to start developing the product? Probably not much, and I get it, it’s tedious and boring.
Now place yourself on the other side, if you were to develop a product (I mean code and everything), what would you expect from your Design team to hand over to you? I’m guessing full detailed functionality and designs.
Documenting projects is the least favourite part for many PMs or designers, but it’s essential for the whole process to go smoothly. It’s essential for every person involved in the team to understand the context of the project and the work to do, or the work getting done so far.
This is an example of how I handoff my designs to dev using Figma for everything design-related, and a Functional Requirements Document (FRD) for all functionality and behaviour that complement my designs.
Figma:
First off, I arrange my Figma document as the following image (Fig 1). I start creating the cover of the file where it should be written the name of the project, team involved, and project status. This becomes the thumbnail.
Then I add another Page where I write the minimum information needed for anyone involved in the team to understand the context of the project. I also add links to any other source of information or workspace.
Another page for the UI Kit. I recently decided to always create a UI kit when designing anything. This is for future me to have everything in place and organised.
Every design iteration that is not final goes in the Sandbox.
Doc:
My Functional Requirements Document (FRD) or Product Specs Doc, is organised as follows (Fig 2):
- It’s important to start with the entire customer journey in the form of a diagram flow. Add any other visual aids that may help the dev team better understand the project documentation, for example, some entity-relationship diagrams, use case diagrams, or actually any other kind of information diagram, add a sitemap too.
- Continue with the specifications of the global elements. Global elements are the elements repeated throughout the platform, some of these are the header, navbar, footer, modals, cards, notifications, errors, among others. Each element, whether it’s a global element or not, needs to provide the following: description, user story, design, annotations, client requirements, and risks.
- The next section should describe the functionality of each of your user flows or features. You’ll have to provide the feature description, including the what, when, where, why, assumptions, and exclusions. If applicable. Add all screens contained in this flow and annotate (more on this later) each of these screens. As written in the previous bullet point, each screen must provide the description, user story, design, annotations, client requirements, and risks. Not all of them are applicable but write down the most information you have so every decision is clear for all team members involved in developing the product.
- Continue with the next screen and/or the next user flow and repeat until you are finished.
This is an excerpt on how it should look like (Fig 3, 4, and 5) when you put it in practice:
Finally, how do you write annotations? It’s actually pretty simple. Take one of the screens and put an annotation (as Fig 4) above each element included in the screen. Now create a table (as Fig 5) in which you describe the detailed functionality of each of the elements contained in the screen.
As you progress through the whole platform’s documentation you can start leaving some elements without annotation if you have already written the functionality. The main goal of annotating each element is to describe in detail what will happen when a user is interacting or not with some element.
Take a look at the example provided in Fig 5, locate element B in the Annotation table, see how the age dropdown is described as to what exact options will be displayed. Now see element A, the NavBar; this description also references another screen and ties up all functionalities that will eventually create our final product and guide the user through the full journey.
After this doc is completed, it’s ready for the technical specs, which is done by the Tech PM; and only then, the design is ready to be handed off to the Eng team to start the developing process.
Was this information useful? Hopefully, it was. If you’d like a template of my file set up just ping me and request a copy level up your game.
No one at my job has complained about how unclear the project was or how the flow didn’t add up. Expert advice: try to make your requirements document so clear and with the correct amount of details to minimise future misunderstandings.
Honestly, there will always be more questions, but I assure you, doing your work correctly will reduce them by at least 80%.
