Tracking designs using watermarks
How to avoid draft designs being used in production
As a content designer, have you been in a situation where:
- Your team is presenting wireframes and flows for early stakeholder feedback, but you haven’t yet had the opportunity to work on the UX copy. The stakeholders share feedback on the copy anyway.
- You’ve received feedback on a piece of content that is still work in progress?
- You realize that less-than-final designs and copy were picked for an internal release. Such a lapse is common wherever handoff protocols between design and engineering teams are not clearly defined.
We feel you.
The design process, the journey from wonder to impact, is a long and winding one. It starts with defining a problem and then goes through a cycle of discovery, feedback, refinement, development, and continuous QA and improvements.
During this journey, we generate a range of ideas and iterate on them throughout the development cycle.
More often than not, these iterations lead to multiple versions living in different locations in Figma artboards, Confluence pages, Google docs, etc.
Often it gets REALLY hard to keep track of the current state of design files and get feedback on the right content within the latest designs. Also during hand-offs, there have been instances when development teams pick designs not meant for production, especially for internal and dogfooding releases.
Finding a fix to the problem
Content designers on the Commerce team at Atlassian dabble with lots of labels, CTAs, messaging, and sensitive legal text to build Atlassian’s purchasing and billing platforms. While we work closely with designers to keep design files up-to-date with the right content, there are times that we’ve struggled for all of the reasons mentioned above.
So the question remains — how best can we communicate the status of the designs to stakeholders/reviewers? Taking a cue from the offline publishing industry, we came up with few status tracking conventions and adopted them as watermarked placeholders in the design files.
How does this work?
We all know the concept of traffic lights. Now, imagine these placeholders as traffic signals that you have to communicate to anyone accessing your design file.
Draft
STOP, no action, please!
These are dummy text that you add for representational purposes or the first versions created before coming up with something more concrete.
Under review
Please WAIT while you test your designs and gather feedback from stakeholders, crit group, and design peers.
Frozen
Finally, it’s time to GO!
You have implemented all the feedback, and are confident to hand over your work to engineering for production.
Simple. Isn’t it?
An example of how these status tracking conventions can be adopted:
Putting it into practice
Our design team maintains an in-house repository of relevant components that are unique to the needs of Atlassian’s customer journeys. It helps designers to work in a consistent way across our multiple workstreams.
To use these watermarked placeholders in our day-to-day work, we have integrated them into the repository to indicate the state of maturity of the designs – what is complete, and what we’re still working on.
While we were at it, we also looked at available options in existing tools like Figma that can help us track status right within the context of design files.
Did it work?
YES!
The status indicators have been helpful in keeping our project triads informed about work progress. For one, it has minimized copy gaffes in design files. Even if the content isn’t up-to-date, the reviewers know what the state of the copy is. It has also helped us gather feedback at the right place, and at the right time.
Have you faced a similar ordeal? Let us know in the comments what has worked well for you.
