Figma Carbon coverage plugin design exploration I

[RichKummer]

Figma design exploration

We defined two overarching flows for the Figma linting plugin:

1. The designer runs the plugin to display an Figma component in the canvas with a snapshot and breakdown of Carbon compliance.
2. The designer runs a plugin that acts as an assistant when checking Carbon compliance, moving from one issue/violation to the next.

Tasks

Preview Give feedback

1. Design exploration of report and assistant flows
2. Review in Carbon design critique
3. Connect with Terry Bleizeffer to refine rating/grading/percentage
4. Research and breakdown similar experiences (Frase.io, Accessibility checker, etc.)

User navigates to Figma page and runs the plugin The non-compliant elements are highlighted with the red border and a Figma component is displayed with results

[RichKummer]

Feedback from Design crit 06/11/24

• Michael G: check out the Accessibiity checker Chrome plugin for a similar experience.
• Frase.io is also a similar experience which provides an SEO score and breakdown for product or marketing copy.
• Design Lint is an open source plugin that also acts a design linting tool.
• Using the center-circle icon might be more familiar to Figma users, who might see it when interacting with color tokens.
• Connect with Liz Barker and Terry B since this is similar to DUX reviews. They did some wide-ranging work to determine how best to present a grade/percent/breakdown for DUX scores.
• Could we use AI to improve the score? Imagining an experience where you can click "resolve" on an issue and have the Figma file update for a better score.

[RichKummer]

D&UX Discussion with Terry Bleizeffer

06/18/24

D&UX discussion

1. D&UX had many changes over the years when it came to scoring and how to communicate that score.
2. Today, a product with an absence of problems is a “B”. Needs to be extraordinary for an “A”, but no one gets an “A”.
3. Originally it was “pass/fail”. Failure meant you couldn’t release, but really no one could stop from release.
4. Added simple letter grades later. Didn’t really have standards, then moved to whole grades (no + or minus), then added those back in because reviewers requested it.
5. People complained that a B was “bad”. The D&UX team tried labeling a “B” as “good” which helped address the feelings designers/devs had.
6. D&UX adopted numeric scores (0-100), but it made it worse. For D&UX, getting a 30/100 was not bad, but people reacted.
7. Considered getting rid of a grade and just a number was considered but people did not want to lose the number and would have had an emotional reaction.
8. Now the D&UX team has all three: a grade, label, and number. Feels a bit like a chimera.
9. If the D&UX team had started today it wouldn’t be three separate pieces of rankings.
10. One takeaway: don’t be afraid of designers having an emotional reaction to the plugin.
11. You want them to have an emotional reqaction and you want them to care if it’s low.
12. They will be upset if it’s low and not meaningful.
13. For D&UX, it someone thinks their product scored low, we can point them to the clear standards. Have a conversation after finding themes and working through it. Focus on concrete steps to up their score and product.

Carbon coverage plugin discussion

1. With the Carbon checker, we have a blank slate.
2. No one knows what the “score” is supposed to be.
3. Will we expand to Carbon PALs eventually?
4. If we skip the overall snapshot, and dive into nuance, designers may not be happy with that.
5. There’s also no comparison point initially. The Carbon team won’t even know what will be a “normal” score for a while. We’d have to guess until we get data.
6. We should capture data to get a sense of how it’s being used.
7. We could show the IBM average in Figma files, similar to what the dashboard does for D&UX team.
8. Terry does like the percentage option.
9. When the D&UX team scored originally, it was a 0-3 score. But when you showed to people, they reacted poorly. They didn’t know what a 2.7 meant. Getting a 1.2 – what does that mean?
10. Terry didn’t feel that adding a percentage wouldn’t add value for D&UX, but it might be useful here.
11. Pages in Figma will vary with lots of different screen numbers (exploration mess vs cleaned up file). It might get hairy for pages with a lot of screens or work.
12. We may want to tell users to “bundle” the screens you want to test on one page for better results.
13. When they were creating a D&UX score, they were thinking of allowing the user to flag certain things as “not an issue”.
14. Could be useful to keep with the percentage. To “clear” something manually that’s not an issue.
15. If we could track what percentage of user-hidden flagged items, we could see what are the false positives that are coming up. Or maybe it indicates PAL components in usage.
16. Maybe we don’t give the percentage on release, but instead show a breakdown.
17. THEN use the data we collect to formulate the right way to display that data.
18. Terry really liked this idea to avoid the cumulative changes to D&UX scoring that teams then didn’t want to lose.
19. Should focus on bucketing the listed items - color, type, etc.
20. People will go through one at a time to fix. Color first, type tokens.
21. It’s not really a visual design change to update from a hex to a color token. The design itself wouldn’t change (usually).
22. This is what it’s supposed to be, rather than using a totally custom component.
23. “Linting” is really not the word choice for designers. They probably won’t know what a “Linting” tool is.
24. Not an important term of designers to learn.
25. Remember there’s no right answer for scoring.
26. Pros and cons to each.
27. You’re going to get strong, conflicting opinions on what is right for them.
28. D&UX couldn’t get rid of letter grades because people reacted.