Considering the number of plugins (e.g. Sketch Measure) and or dedicated tools (e.g. Zeplin) we – as designers – have access to, I'm curious to hear if traditional design specs are part of your deliverable hand-off. Traditional in the sense of documented prose, interaction details, etc. as a living shared doc. What does your "design spec" include?
I've been running the product design team at FarmLogs for a few years, here's how it went for us.
We didn't use anything more than casual documents or Invision for a long time. As our product grew large, it made it really hard for engineers, designers, and PMs to understand how our own products worked. Backend refactors would subtly break something without us knowing until a user complained much later, important details in how we showed data got lost in redesigns when a new person came onboard, etc.
Now we have two forms of specs: our "Design Language" is in Sketch documents shared in Zeplin, which help us maintain the latest version of all of our UI components, visual styles, animations to some degree, etc.
Our "feature specs" are wireframes and descriptions about the product itself in a wiki. They're co-owned with engineering and product management, and they describe what each page does, how the information should be displayed, edge cases, etc. These feature specs link back to the hi-fi Zeplin components so engineers know what "building blocks" to use to build each page.
It's a pretty new distinction for us, but the separation between abstract components that "hold" data and the data and pages themselves has already been a big help to our team.
interesting, could you explain your last paragraph about separating components and the data/pages a little more or an example?
So a UI component would be a Table for example. We have a bunch of versions of our tables in Sketch--tall rows, short dense rows, sortable tables, etc. These are defined w/ pixel precision on an 8pt grid using the standard set of colors and type on each platform (web, ios, android). There's only one high-res spec for table, though.
The "feature" spec is separate--an example might be the Rainfall History page. The spec includes how the amount of rain should be formatted (units, degree of precision), how many days to show, what to show if there wasn't any rain, and what the columns should be. A different page, Heat History, would have different content in a similar format--this time units in degrees, with different columns, etc. The images on these pages are just rough wireframes of a table, but they both link to the original Table hi-fi spec.
Happy to answer any more questions if that's not clear!
Always depends on the situation (of course) but I haven't delivered a real spec in a long time, and try to keep them as living things.
When working with one larger company with a less talented (and less detail oriented) dev staff, we delivered static but functional markup/js prototypes for web platforms. Within that prototype we called out specific interactions, to spacing, down into code standards. This is far from the norm though imo, it was very involved
More recently I used Zeplin for an android app 'hand-off' and was very successfully utilized. Made asset generation, typography and spacing work much easier. Worked very well here since there weren't any real custom interactions desired outside the standard material library.
In our team at Moze we use for websites Zeplin along with a short meeting with developers to introduce them to main interactions.
When it comes to products as part of our agile development process we create Job Stories that include:
- The Job Story description.
- A link to Zeplin or Invision to all the layouts regarding that Job Story.
- A list of acceptance criteria in the Given-When-Then format.
As a designer I can tell that writing acceptance criteria or any other quick form of written specs it's also helpful to me to brainstorm on behaviours and interactions.
In any case close and early collaboration with developers is key.