SADA Spec Documentation Hand-Off
SADA Spec Documentation Hand-Off
Lydia Chamberlain & Kelly Su 2022
This document will be provided to SNHU so that they may understand SADA’s typical design hand-off process, and make adjustments where needed. This is NOT for design systems, as SNHU already has a system in place.Workflow Diagram
A High-level workflow of the general process of getting implementation going.
Feature Documentation & User Stories
At SADA, we typically like to have all features in one sheet document. Given the nature and scope of SNHU’s Turbine product, this may be split into several tabs or several sheets. The feature documentation should be as explicit and detailed as possible for a developers eyes, so that it can be translated into a working ticket. User stories will typically be mapped to each feature, which can also be grouped by epic. However, at the end of the day developers will typically treat Jira as the source of truth.
The columns of a feature list is typically as follows for a baseline:
Example Feature Documentation
Epic
Feature
Details
User stories
Acceptance Criteria
Phase
Priority
Design Required
1
There are no rows in this table
After this point, we import all of our features into Jira. Sometimes, some reorganization occurs so that there isn’t overlap between features - some may need to be grouped together in to tasks and subtasks.
Specification Workflows
For specific hand off documents, there are two ways to go about this. SADA has multiple methods due to our nature in consulting. These are centered around feature specs, as the component level specs are already being worked on in SNHU’s design library files. Both methods can be utilized, or one or the other depending on SNHU’s workflow and future developer needs.
Method 1: Figma Spec Documents
Within the main design figma files (not the design systems) spec documentation can be made here to keep everything in context. This allows designers to pull from components, without needed to export the frames elsewhere.
Note: These kinds of designs can also live in places like Zeroheight or the Jira ticket themselves - it just depends where you want developer eyes focused and how you want to document your work long term. If you prefer to include animated gifs/videos to speak to movement, the same would apply.
In your figma file, you can create a “Specs” page where such documents are kept.
Example 1
Example 2
Method 2: Figjam Spec Workflows
Within your typical folder for a product, create a separate figjam that matches back to user stories. These are a combination of user flows and addressing specific functionality. This can be done at the lo-fi wireframe level, or without wireframes at all. Since Figjam doesn’t handle pages at this time, generally 1 full document can speak to a similar grouping of user flows, so it doesn’t get too bloated.
Example
Final Note
This is fairly high level since development is far in the future - so please let me know what aspects of this process you might want me to drill into, or if something won’t work for your team! We are happy to compromise.
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.