Features
Tips & Tricks
Misc

Running a Guidelines pilot on your team

This guide takes you through the steps that are required to run a successful pilot of Frontitude's Guidelines feature. From defining success to collecting feedback from your team at the end of the pilot, following this guide will increase the chances of success in finally making your team write as one and create consistent UX content without a hassle.

Step 1 - Define your KPIs

Without measuring success, it's going to be hard to understand if any new solution/process is worth it. So, first things first, you should define what you'd like to improve with the UX Writing Assistant at your team level. This can include number of KPIs:

  1. Time spent on maintaining consistency. To measure this, you need to quantify how much time team members spend on maintaining content consistency. Whether it's going over the static content guidelines in Figma or an external document, or sending relevant questions on the team's Slack. This can be done by counting messages or asking team members for estimation (like weekly hours).
  2. Time spent on content reviews. In teams which include a UX writer, this can be the time they spend on content reviews. If you don't have a UX writer on your team, this can include the amount of time that is spent on content review as part of the design review/critique process.
  3. Quality of user experience. This is harder to measure, but can be based on gut feeling, mixed with user feedback. What is the level of UX content quality that you deliver? Rate it. Then, you can go back to it and check if your feeling has changed after the pilot.

Step 2 - Define the pilot scope

Testing the UX Writing Assistant doesn't necessarily require your entire team. It requires a minimal amount of team members and designs. From what we learned, the recommended numbers are:

  • At least 3 product designers should participate. If your team includes less than that, it means that the entire team should be part of it. If you have a large design team with more than 10 product designers, we suggest including designers from a single product area.
  • At least 10 design components should be covered with guidelines. To make sure the design team uses the Guidelines, it's better to have a critical mass of components that are covered with content guidelines. These components should be the most frequently used, to maximize the chances of being used by team members.

Step 3 - Create a universal guideline

After you defined the pilot's success, it's time to create your content guidelines in the UX Writing Assistant. This step (together with the next one) doesn't require the entire team onboarded yet, so you can complete by yourself.

Guidelines can be created at two main scopes: Universal, and Component. Universal guidelines will be automatically loaded for each text rewrite by any of your team members. Component guidelines can be linked to specific main components in Figma and automatically loaded on all of their instances, across design files.

First, you should collect all guidelines and rules that should be considered when generating content for every text element in your product. Then, you should include everything in a single Universal guidelines:

  1. Open the assistant plugin in Figma.
  2. Go to the Style tab.
  3. Click Create.
  4. Fill in the guideline's properties. You can use this help guide for this.
  5. Turn on the Universal toggle under the Scope section.
  6. Click Save to create this guideline and link it to the Universal scope.

Don't forget to test it on a few text elements before moving on. Select a few different copy elements from different design mockups and see that it works. If you're not happy with the results, go back to the guideline and improve it by rephrasing the custom instructions or modifying the predefined instructions.

Step 4 - Create component guidelines

If there is a UX writer on the team, this is usually their part. If you have an existing content style guideline, you can definitely use it as a source for your guidelines in Frontitude.

Naming guidelines

We recommend using a forward slash convention to name guidelines. It aligns well with design system component and can be organized pretty easily. You can use two different approaches for naming:

  1. Design-driven naming. Guideline names include design system components, like Modal / Title, Toast / Error, Input / Placeholder, or Button / Primary. Each of these guidelines will be usually linked to a component in a one-to-one relation.
  1. Content-driven naming. Guideline names include the content type, like Message / Error, Message / Information, Button / CTA, or General / Legal. Each of these guidelines will be usually reused across multiple design components in a many-to-one relation.

After you figured out how you'd like to name your guidelines, let's see how to actually create them using the UX Writing Assistant:

  1. Open the assistant plugin in Figma.
  2. Go to the Style tab.
  3. Click Create.
  4. Fill in the guideline's properties. You can use this help guide for completing this step.

A minimum of 10 guidelines will significantly increase the chances of the pilot's success.

Step 5 - Link guidelines with design system components

Once you have a critical mass of guidelines for the pilot, you can start linking them to design system components. For this, you'll need edit access to your design system file in Figma.

To link guidelines to main components:

  1. Open the assistant plugin in Figma.
  2. Go to Style tab.
  3. Select a text in a Figma main component which you'd like to link a guideline to.
  4. Open the relevant guideline.
  5. Click Link on the top-right corner.
  6. Repeat steps 3-5 for each and every text in main components that you'd like to cover with guidelines. Make sure that you cover all relevant components variants.

Linking guidelines to main components doesn't change or affect the design system file in any way. This process leaves no footprint on your design system.
In most cases, the design system manager will have to be involved in this process, so make sure they're brought in as early as possible.

Step 6 - Onboard your team

Once you have created guidelines and connected them to the universal scope and your design system, it's time to invite team members to use them. Invited team members will get these guidelines automatically loaded as part of the Rewrite feature, according to their scope.

To invite team members:

  1. Go to Settings tab (the settings icon on the right of the navigation bar).
  2. Under the Team section, click + Invite.
  3. Insert your team members' emails, separated by commas.
  4. Click Send invitation.
  5. After your invited team members click the link in the invitation, they will be added to your team account in the assistant plugin and will be able to start writing together!

Step 7 - Running the pilot

Once guidelines are set up and all team members are added to your team account, we recommend you to follow the following:

  • Pilots usually need around 2 weeks to yield concrete results.
  • While the pilot runs, we recommend maintaining a document with your team's feedback, just to make sure no feedback falls through the cracks. It will help you at the pilot evaluation phase.
  • Share our contact information with your team, so we can guide them on the go and remove any roadblocks along the way. We're available at support@frontitude.com or through the website chat.

Step 8 - Pilot conclusion and next steps

After the pilot runs at least for 2 weeks, it's time to collect all the feedback that was given through the trial period and see how it affected your team and delivery. At this point, we recommend you to:

  1. Clean and compile the given feedback.
  2. Interview participants and ask them how working with the assistant affected their work.
  3. Schedule a call with the Frontitude team for getting usage statistics, answering open questions, and thinking together about the next steps.

Contact us at support@frontitude.com or via our website chat for more information about running pilots and other topics!
Copied!