top of page

Creating a Modern Voice for Developer Content

Project type: Content design and organizational transformation
Role: Voice for Developers lead
Focus: Developer content, customer research, writing standards, training, change management, and content quality
Timeline: 2012-2014

Office Voice Project developer content voice and tone dashboards

OPPORTUNITY

Office developer content was technically accurate, but it was often formal, dense, and difficult to scan. Customer feedback repeatedly asked for plain English, shorter explanations, clearer examples, and faster answers. At the same time, teams were publishing across multiple platforms with limited insight into customer intent, search behavior, and whether people could find what they needed.

The challenge was not simply to adjust word choice. Microsoft needed a more modern approach to technical content that combined customer intent, usability, findability, concise writing, empathy, SEO, and ongoing measurement.

Role

I led the Voice for Developers workstream as part of a broader Office-wide Discovery and Voice initiative. I represented the developer documentation organization on the cross-functional leadership team and helped translate a general content-voice strategy into something that worked for highly technical audiences.

I led the developer pilot, created examples and training materials, recruited early adopters, worked with writers and editors, and helped drive the change from an initial experiment into a broader organizational practice. I also presented the approach to other Microsoft developer-content teams and supported the next phase of the program, including continuing education, peer review, alignment with broader Microsoft voice guidance, and measurement.

APPROACH

We treated voice as part of the entire content-development process, not as a final editorial pass. Writers began by identifying the customer’s intent, understanding the task they were trying to complete, and examining available feedback and search data. They then reworked content to make the main answer easier to find, easier to scan, and more direct.

The core principles included focusing on customer intent, using active voice, cutting unnecessary words, choosing everyday language where appropriate, preserving necessary technical terminology, improving titles and headings for search, and acknowledging the reader’s situation without becoming overly casual.

The rollout used before-and-after examples, pilot content, one-on-one coaching, workshops, peer discussion, training waves, and reusable checklists. An early pilot involved 12 writers and editors creating 31 examples, which were then used to support wider adoption across the organization.

It was a substantial effort across multiple teams over several months. I sometimes wonder how different the work would have been with today’s generative AI tools. We might have been able to start with a prompt as simple as, “Rewrite this in the style and voice of Microsoft Office,” then focus our energy on reviewing, refining, and teaching the judgment behind the result.

Research and Evidence

The effort was grounded in customer research rather than personal writing preferences.

A study with 1,600 participants compared formal, empathetic, and intentionally overdone versions of the same content. The more empathetic version performed better across areas such as ease of understanding, usefulness, friendliness, credibility, clarity, and perceived depth. Importantly, the preference extended to developers and IT professionals, helping address the belief that technical audiences preferred dense or highly formal writing.

The research also showed that clearer content could feel more complete even when it was substantially shorter. That evidence became an important tool for gaining support and overcoming resistance to the change.

RESULTS

The initiative established a shared set of modern voice principles for Office developer content and created a practical model for applying them. Writers and editors had clearer guidance, concrete examples, training, and a repeatable way to review technical content through the customer’s eyes.

The work also moved the organization toward a broader content model that connected planning, writing, measurement, and optimization. Voice became less about making content sound friendlier and more about making technical guidance useful, findable, concise, and easier to act on.

The program expanded beyond the initial pilot, influenced training across the Office content organization, and was shared with other Microsoft developer-documentation teams.

LESSONS LEARNED

This project reinforced that content standards do not create change on their own. People need evidence, examples, opportunities to practice, feedback from peers, and a clear connection between the new behavior and customer outcomes.

It also showed that technical accuracy and approachable writing are not opposing goals. Clearer content can remain precise while reducing friction for both new and experienced developers.

Finally, the work demonstrated that meaningful content transformation requires both craft and change leadership. Improving individual articles mattered, but the larger impact came from creating a system that helped an entire organization plan, write, review, and measure content differently.

bottom of page