Summary
- Role: Manager of Content Design, self-directed
- Status: Launched to team; org-wide deployment in progress
- Deliverables: Working Figma plugin
- Tools: Figma API, LLM API, Glean Agent
- Collaboration: A member of my team with a dev background
The Brand team at Docusign created a Copy Rubric that was supposed to help us keep our copy consistent with Docusign’s brand voice and tone. Content designers are great and the content designers on my team are especially great. But they are human. Asking them to break their day-to-day workflow and go into an isolated Confluence page to reference things just isn’t realistic.
We needed a way to bring the rubric into our day-to-day workflow.
The problem
So, Docusign has a copy rubric, but we had no way to check our work against it. The downstream effect of this is that we can’t maintain consistency and stay on-voice across 7 team members touching tons of surfaces, features, and products.
Plus, how can content designers actually defend their decisions without data? I’ve certainly been stuck in arguments with PMs, designers, and/or engineers about tone, where we were just citing our opinions instead of something objective. And from conversations I’ve had with the folks on my team and peers in the industry, this is a very common situation.
What I built
The solution to both was to build a Figma plugin that calls to a LLM, compares the content against our content rubric, and then creates a “sticker” with a score which can be placed on the Figma canvas. My goal here was to create a lightweight feature that slots into the tools we are already using that will help solve both problems at once: staying consistent with Docusign’s brand voice and tone and helping us defend our content decisions with data.
If you’re reading this, there’s a very good chance that you’ve noticed something about me: I’m not a coder. I’ve worked on front-end copy for a long time, so I have some basic understanding of HTML and CSS, but anything more complicated than that, you lose me. So I needed help. But it was basically a guarantee that no engineering resources could be spared to build something bespoke. So my first step was to build a Glean Agent, running on Claude but pulling in resources I’d found on building Figma plugins. It quickly earned its keep as I iterated, troubleshot, and slowly improved it.
After a lot of iterations, the plugin worked and the workflow was super simple. You just boot it up in Figma, point at the screen or screens you want reviewed, and click a button. The plugin takes the content, sends it to an LLM that’s then able to score it against our rubrics and content standards and give it a score out of 20. Anything below a 15 gets rewritten.
Now my team doesn’t have to leave their primary work surface to get their work checked for consistency and quality.
Why a tool? Why not a guideline? Or even a new process?
At a basic level, I rejected the idea of building a guideline for a pretty simple reason: the guideline already existed, but nobody was using it. Frankly, multiple standards exist at Docusign but most of them fail for the same reason. If a guideline falls in a forest and nobody is there to read it, does it really exist?
The tool changes guidelines from a reference to part of a writer’s workflow.
The goal with building the plugin was to change when the guidelines show up. Instead of being something you have to remember exists and go look up, to something that is checked at the moment work is actually being done. That way writers can stay in the surface where the work is being made and stay focused on making it.
Rollout
The basic process of rolling this out was pretty simple:
- Start building the plugin on my own
- Show it to Brand, get approval from them to use the rubric
- Bring in teammate to help improve my code
- Roll out beta version to the team, while working with Docusign’s LLM and AI team to get metrics
- Package up a more complete version for the team
- Distribute to the rest of the design org
Currently we are at step 4. I’ve gotten a ton of great feedback from the team. Getting real usage and honest, detailed feedback before it’s judged/used by non-content people has been critical.
How can I tell if this is successful
I’m broadly thinking about success in two buckets: adoption and impact.
Adoption is the near-term benchmark to hit: if I can get everyone to download it and start using it that’s a great start. Once I get some usage metrics, tracking something like weekly active use of the tool would prove that the plugin is being used and is being useful. I thought about using % of shipped Figmas run through the tool, but sort of rejected it out of hand. Both because it’s often not clear at times that a Figma has actually shipped, but also because it sidesteps the question of whether the team is getting use out of it.
Impact is where we can really see the difference. For example, if my team uses the tool and can show that we’ve increased the content’s adherence to the rubric by like 20%, that’s a strong positive impact directly attributable to the tool itself. This hasn’t happened yet, but we should be able to start collecting early data soon.
The issue of course is that I need Docusign’s LLM and AI governance team to give me access to metrics; Figma plugins’ built-in limitations and Docusign’s security control has made it difficult to get metrics on my own.
What would I do differently
I think for the most part I’m pretty happy with this, but the dependency on Docusign’s internal LLM team to get usage metrics is a real problem. I can’t finish proving that this is effective without them devoting time and effort, which is just simply out of my control.
It’s not a total blocker (and I didn’t really know this would be a problem when I started) but I would probably have gone to them earlier to get buy-in and find out when they could feasibly get me those metrics.
Ultimately though, the tool is in use and is already helping my team write better, more consistent copy and win fights with Product. And at the end of the day I can’t ask for more than that.