SEnior content developer - DynAmics 365 Field Service (2017-present)
I plan, write, develop, and maintain content and manage contributions for Dynamics 365 Field Service and its larger components, like Resource Scheduling Optimization, Universal Resource Scheduling, and Connected Field Service. Each of these solutions are tailored to support organizations who deliver onsite service to customer locations.
Field Service is a pretty big application, with lots of features, functionality, and extensibility - this all adds up for a single content person. So instead of tackling it alone, I engage a team of between 10 and 15 program managers (the number fluctuates as people move around) to be active contributors to documentation. This has meant providing training and materials around docs contribution, such as Github onboarding and editorial process, markdown tools, and hands-on help when things inevitably, sometimes, break.
Working with and maintaining strong partnerships with the product team is my biggest priority; by working together and building trust through these working relationships, we’re ensuring our content is accurate and actionable...and that we’re able to notice and react quickly if it’s a bit off.
Managing contributors...
Let’s be honest - no matter where you are in your career, sometimes contributing content is intimidating. This is why I put a strong emphasis and focus on building trust with my product team; the less worried they are that their contributions are perfectly written, the more likely they are to feel comfortable submitting contributions.
All content written by our Field Service contributors comes through me, and I work with all the product team and our copy editors to make sure docs quality is up to our docset’s standards. Sometimes this means doing the heavy lifting on a barebones draft; other times, it means a quick readthrough and approving a pull request.
...and editing their contributions
With many our customers using Field Service implementations of varying complexity, it is critical that we provide a clear vision of product development so they know what to expect with upcoming releases and can plan accordingly.
One of our key objectives in Docs is to have all new features and functionality documented by the time the features release. As a content partner, I work with the PM team to develop and document upcoming releases (two major waves per year, and smaller ongoing monthly releases). Once upcoming features are described and planned, we build out our release backlog to track the features in the release, developing schedules and deadlines for the full public documentation.
Release planning + Readiness
When initially assigned to the Dynamics 365 Field Service doc set, I inherited a haphazard information architecture focused on grouping content by user personas (admins, “makers,” “partners,” and a few other roles). Much of my early work on this documentation set focused on two key areas:
- Content auditing (what do we have, what needs to go, and what are we missing?)
- Card sorting with PMs and partners to determine the most logical organizing principles behind our app, Field Service.
This research and collaboration resulted in a completely overhauled information architecture of our documentation that more closely mirrored the organizing principles behind the app. Gone were the days that our readers must first self-identify before finding their content; our documentation now matched our product, which is key in unifying experiences for our customers no matter where they interact with us. See our information architecture here (the left-hand table-of- contents-like navigation).
As our product grows and shifts, I maintain and adapt our information architecture so that it stays accurate and up-to-date.