I started working as a designer on the Spectrum design system team in 2017, and watched it grow from a handful of designers with very little adoption to a large team of designers and engineers, a robust system, and about 70% adoption across all Adobe products.
To help further that adoption rate, in winter 2019 I began consulting with different product teams across Adobe to help them integrate Spectrum into their products as seamlessly as possible.
The Developer Ecosystem team approached our team to help update their website and developer documentation, adobe.io, Adobe's developer product suite that consists of over 50 products, services and APIs.
As a I began digging into stakeholder interviews and talking to the product teams, what I uncovered was not only did the website need a facelift, there was a larger, systemic issue about how content was getting onto the site. Team after team expressed frustration in lack of design and engineering resources to even make the tiniest updates to their page on adobe.io and corresponding documentation.
I went to the PM and showed him my findings, and he agreed we needed to take bigger action to address this issue.
How might we improve the third-party developer experience by applying a design systems approach to content creation?
Research + Validation
I recruited participants to interview within Adobe Developer Ecosystem org, a mix of content authors, developers, product managers, marketers, etc. to dig deeper into their experience with the Adobe developer website. My high-level goals were to uncover user sentiment surrounding publishing on the platform, and how well they felt the website supported their product goals. Key insights from these interviews included:
- Design and development were blockers to publishing. Many participants felt that getting anything up on the website was next to impossible, and therefore rolling their own separate solutions, such as using Gitbooks for documentation of their product, was much faster than waiting for the adobe.io team.
- Complaints from third-party developers about lack of community, no support, and the website feeling "useless" It was difficult to find what you needed — another reason teams were seeking other solutions outside of the website.
- Small teams with no resources struggled with designing and writing quality content about their APIs and services. They felt disconnected from the community.
What we discovered is that the pain points of our content authors were directly impacting our third-party users, which was in turn impacting the business goals of Adobe Developer Ecosystem.
The key goal was clear: to better serve our third-party developers, we needed to address the needs of our internal stakeholders. The last phase of our research was a survey, where I asked participants to rate what they needed help with the most.
for internal teams
- Lack of trust With over 50 product teams in the Adobe Developer Ecosystem, there were only 26 teams using the website to showcase their APIs, services, and documentation. The trust in the website team to give them what they need had dwindled over the years, and there had been a lot of empty promises made because of budget cuts and other constraints. We had our work cut out for us to reestablish that trust and confidence.
- 75% of product teams using the developer site as their main hub for showcasing docs and products. This was the most important metric for us.
- Positive community feedback from third-party developers Adobe has a huge dev community, and redesigning the website experience with them in mind was important.
What does the system need?
For an in-depth look on details of the design decisions behind many pieces in this system, please view my case study on redesigning developer docs
Auditing the current website experience
Using Adobe's Spectrum design system as our jumping off point, I began by auditing the components and design patterns on the current website. I wanted to get a feel for how many custom components I needed to make, and how many I could borrow from Spectrum.
The case for a content-first design system
During my discovery, I found that many of the repeatable patterns were heavily content-based and context oriented, as opposed to the very generalized pieces provided by Spectrum.
Along with our content strategist, we began brainstorming how to best approach the creation of new patterns. After brainstorming different iterations in a workshop, we landed on a modular, content-first approach, which we called the Modular Content System (MCS).
THE Modular content system
After defining the pieces of the MCS and subsequent templates, I began giving workshops to product teams where I fielded questions and walked through step-by-step how MCS works:
what is the best way to publish?
iteration one: adobe flavored markdown
Our first iteration of CMS aimed to give as much customization as possible, we wanted to keep the doors of creativity open. We also made the assumption that most of our users would be developer-savvy, and opted for markdown and JSON to write content.
- Lots of opportunity to customize the MCS
- Easy integration into dev environments
- Rolled out by our team, so we had complete control over releases and features
- Clunky and confusing taxonomy
- Point of entry was high, you had to have knowledge of Markdown, JSON, and some dev expertise to write and publish content
- No way of previewing work until publishing
ITERATION TWO: HELIX, A VISUAL CMS
Based on feedback, we knew we needed a CMS that was easy to learn and gave better visual clues so a wider variety of content authors could use it. Fortunately, Adobe had an internal team that was working on a CMS called Helix. Helix integrated with Google docs and used simple tables and formatting that felt familiar to our content authors.
Goal based publishing paths
Early in our beta testing for Helix, we noticed that despite workshops and documentation, many content authors were choosing the wrong templates or components when crafting a page.
To remedy this, we made categories of our templates based on goals and/or identities such as "I am a technical writer" or "I want to update marketing copy for my product" and then provide the recommended templates.
What do content authors need to be successful?
One of the biggest success metrics for this project was getting teams onboarded back onto the developer website. Setting our content authors up for success was key for this to happen. Many teams I talked with felt they lacked quality resources for content creation, which is a big reason for outsourcing outside of Adobe.
Content authors said they wanted help with:
- Mockups and imagery
- Content strategy
- How to write better documentation
- Having a single "source of truth" for assets, resources and design
branding and imagery
The final step was documenting everything we had created. It was a large effort, but the end result was a comprehensive website that included all of the components and templates from MCS, how to get set up with our CMS, and resources and guidelines for making quality content.
helping teams onboard
The ethos behind the MCS was also adopted by some other design teams working cross-platform at Adobe, and I was brought in to consult on best practices and share our learnings with them.
- Meet your users where they're at I went into this project thinking like a designer, and framed a lot of my assumptions around that point of view. I had to take a step back and recognize that a majority of our content authors weren't designers, and cared more about getting their product out the door than making things look nice. Taking more initiative with templates and guided paths to publishing helped me support my users.
- Design systems have high business impact for more than just designers. It was great to see a design system scale to this level, and impact an audience that weren't just designers. Systems thinking played a huge role in unblocking and giving product teams freedom to push further and faster.
- Don't be afraid to push The original brief of this project was a redesign using our existing design system. I had the option to play it safe, do what was asked of me, and deliver something quickly. But I couldn't ignore the giant holes I saw in the publishing process making our product teams miserable. I stepped up and pushed towards a vision, not quite knowing if it would work out. In the end it did, and I'm grateful for the support I had from my design team to go with my gut.