{"id":4156,"date":"2019-04-08T08:42:22","date_gmt":"2019-04-08T12:42:22","guid":{"rendered":"https:\/\/blog.mozilla.org\/ux\/?p=4156"},"modified":"2019-04-12T19:16:42","modified_gmt":"2019-04-12T23:16:42","slug":"paying-down-enterprise-content-debt-part-3","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/ux\/2019\/04\/paying-down-enterprise-content-debt-part-3\/","title":{"rendered":"Paying Down Enterprise Content Debt: Part 3"},"content":{"rendered":"

\"Gray<\/a> \"Gray<\/a> \"Purple<\/p>\n

Summary: <\/strong>This series outlines the process to diagnose, treat, and manage enterprise content debt, using Firefox add-ons as a case study. In this third and final piece, I describe the deliverables we created to support a new content model.<\/p>\n

 <\/p>\n

Content guidelines for the \u201cauthor experience\u201d<\/h2>\n

\u201cJust as basic UX principles tell us to help users achieve tasks without frustration or confusion, author experience design focuses on the tasks and goals that CMS users need to meet\u2014and seeks to make it efficient, intuitive, and even pleasurable for them to do so.\u201d \u2014Sara Wachter-Boettcher, Content Everywhere<\/em><\/p><\/blockquote>\n

 <\/p>\n

A content model<\/a> is a useful tool for organizations to structure, future-proof, and clean up their content. But that content model is only brought to life when content authors populate the fields you have designed with actual content. And the quality of that content is dependent in part on how the content system supports those authors in their endeavor.<\/p>\n

We had discovered through user research<\/a> that developers create extensions for a great variety of reasons\u2014including as a side hobby or for personal enjoyment. They may not have the time, incentive, or expertise to produce high-quality, discoverable content to market their extensions, and they shouldn\u2019t be expected to. But, we can<\/i> make it easier for them to do so with more actionable guidelines, tools, and governance.<\/p>\n

An initial review of the content submission flow revealed that the guidelines for developers needed to evolve. Specifically, we needed to give developers clearer requirements, explain why <\/i>each content field mattered and where that content showed up, and provide them with examples. On top of that, we needed to give them writing exercises and tips when they hit a dead end.<\/p>\n

So, to support our developer authors in creating our ideal content state, I drafted detailed content guidelines that walked extension developers through the process of creating each content element.<\/p>\n

\"Screenshot

Draft content guidelines for extension elements, mocked up in a rough Google Site for purposes of feedback and testing.<\/p><\/div>\n

\u00a0<\/i><\/strong><\/p>\n

Once a draft was created, we tested it with Mozilla extension developer, Dietrich Ayala<\/a>. Dietrich appreciated the new guidelines, and more importantly, they helped him create better content.<\/p>\n

 <\/p>\n

\"Screenshot

Sample of previous Product Page content<\/p><\/div>\n

 <\/p>\n

\"Screenshot

Sample of revised Product Page content<\/p><\/div>\n

 <\/p>\n

\"New

Sample of revised Product Page content: New screenshots to illustrate how extension works<\/p><\/div>\n

We also conducted interviews with a cohort of developers in a related project <\/a>\u00a0to redesign the extensions submission flow (i.e., the place in which developers create or upload their content). As part of that process, we solicited feedback from 13 developers about the new guidelines:<\/p>\n