Bringing UX content into a product design framework

AMBOSS 

Ways of working / methodology

content-first

©20px.com

Amboss is an innovative medical knowledge platform students can use to prepare for exams, and medical professionals can reference in clinical practice. As Senior Content Designer, I was not only responsible for delivering project work but also weaving the craft into the wider product design and development cycles and ways of working together.

One of the most important workflow optimisations came into effect as a result of my initiative to merge content design into the wider product design framework. With the support of the Director of Product Design, product managers, design leads, engineering leads, and the editorial content team outside of product, I took charge in updating current product design ways of working with content-first methodologies that worked with the company structure, and addressed workarounds to bandwidth restrictions.

The challenge

Like many UX writers and content designers out there, I was outnumbered in my team (by a modest 13-to-1 ratio by my last year with them). This was like being handed a ticking time bomb for exponential content debt and scalability issues.

After about a year under a first iteration that was hastily put together by myself and one lead designer, the learnings (and politics) required to get traction on any changes of practice were there.

So I got together with the Product Design Team leads, the Director of Design (my boss) and started a project to create a lasting framework for UX content design within our product design ways of working.

Screen Shot 2022-03-03 at 10.58.13 2

The insight

Once I was given the green light to make this undertaking an official project, I worked with the lead designers to first gather information on what were the shortcomings of the current process amongst ourselves in the team, among, product managers, engineers, and medical editorial staff.

This came in the form of group sessions where I asked these specific groups to highlight their understanding of the current process, where they encounter difficulty, and what could be improved from their perspective. Important to note, it was also another occasion to discuss the understanding of what exactly content design is and what to expect from me/it.

The results of these discussions and brainstorming painted a clear picture: the current process did well to keep everyone conscious of the work required for UX content, but the tiering of project scope and corresponding handling was still too abstract and distant, so they simply relied on the product designer to bring their questions or concerns to me once they felt it was urgent enough.

Which was usually too late. And also, prone to delays since localization was not taken into consideration and I usually had to deliver designs for both German and English versions in addition to organizing the localization itself.

The fellowship

001_HR_0924_COVER-3.indd

If there was one thing from the discussions with different product stakeholders that everyone agreed on it was that they simply felt they needed more of me. Or at the very least, more tools for them to feel less dependent on me for basic consistency checks and overall quality.

What was I to do with this input (and my own desire) to hire more UX content talent despite a hiring freeze? 

Look to my content friends in-house of course. Having cultivated my own content guild to facilitate cross-company alignment of language and messaging, I saw an opportunity to grow the discipline internally with colleagues from other company domains who were already wanting to deepen their UX writing skills.

Localization would also be alerted and looped in at the same time the need for UX content would surface. By negotiating bandwidth allotment for the basic UX writing tasks they would receive, content design would gain more presence and weight.

Consulting with both non-product content creators of both English and German markets, I was able to strike a compromise in terms of how much of their bandwidth was required and most importantly, what their tasks entailed. Having this set quite clearly also helped make it easier for product teams to decide where to direct the UX content needs.

The result

Consulting with non-product content creators of both English and German markets, I struck a compromise in terms of how much of their bandwidth was required and most importantly, what their tasks entailed. Having the criteria clear and concisely communicated helped make it easier for product teams to decide where to direct the UX content needs. 

It was a win-win solution: not only did this add professional value to these colleagues already hungry to learn more UX writing skills, but it provided a perfectly scalable and flexible framework for the craft to grow in a visible and traceable way, with simple language, visual documentation, and the use of productivity tools like Asana.

We were able to break down the workflow into 3 diagrams for 3 different audiences:

  • Overview-level (being the simplest) for non-product collaborators or senior management
  • Mid-level for product teams
  • Detail-level for product designers, content collaborators, and design leadership

Just in the following 6 months, product teams estimated that they were spending at least 20% less time dealing with UX content related topics. What that translates into dollars is only my guess. What that translates to in terms of efficiency and growth is a lot more time to focus on designing the best product experiences possible.