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.
27
1
123
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.
I was able to establish a goal framework and a set of questions that would lead my design and ideation phase.
Beautiful
third-party developers
Ownable
create content
Scalable
for internal teams
CONSTRAINTS
- 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.
- Lack of resources Early on we lost our engineering resources due to the COVID-19 pandemic, so for the first 6 months we soldiered on without guidance from engineering. Our original estimate for this project was 6 months, but it ended up taking 10 months which wasn't ideal for our stakeholders.
MEASURING SUCCESS
- 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.
phase 1
phase 2
phase 3
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
Design was at the top of the list of pain points for our research participants. Confusion surrounding how to structure a page, what kind of button to use, and what the best practices were for adhering to Adobe's design system were mentioned multiple times. We needed to not only define what the new website needed in terms of a design system, but take a holistic look at the information architecture and how to best structure the website to not only serve our internal actors, but our third-party devs.
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).
We set out to make the modular content system a comprehensive set of resources and repeatable parts: content blocks, variants, compositions and templates that can be used to create pages within the developer website.
Template-based design
I never envisioned template-based designs for the MCS. At the beginning, I pushed for a traditional design system approach— I wanted our content authors to have the freedom of creation, so the developer website could be a reflection of them. As we began rolling out different pieces of the system, I quickly realized that we may have given a bit too much freedom. I was being pinged on slack with questions about how to put together marketing pages, what component to use in what spot, etc. Our users needed clearer guidelines.
I went back to the drawing board, this time focusing my efforts on the information architecture of the website. I recruited PMs, stakeholders, and some key content authors to help in a card sorting exercise to better understand which pages could be templatized.
Based on our workshop, we narrowed it down to two main template categories: Discovery and Documentation
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?
The path to publishing for teams was more or less nonexistent. Most of the time, product managers would make a Jira ticket that would then get put into a queue of more than 100 requests for things as simple as a misspelled word. It wasn't surprising that teams had decided to roll their own solutions using third-party tools such as Gitbook or Swagger. Unfortunately, the result was a fragmented ecosystem of APIs and services.
Working closely with the engineering team, we began brainstorming ways to integrate the Modular Content System and subsequent templates into a CMS.
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.
Pros:
- 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
Cons:
- 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
The feedback we received was that product teams were still feeling blocked— PMs, marketers and technical stakeholders were unable to contribute content.
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:
- Branding
- Mockups and imagery
- Content strategy
- How to write better documentation
- Having a single "source of truth" for assets, resources and design
branding and imagery
I partnered with the Adobe Brand team to create Cloud-specific imagery for teams to used. Based on which cloud they were in, they could use a variety of images and icons in their documentation and pages. We also set up a slack channel and Google form where teams could request custom illustrations or get feedback on images and mockups from the brand team.
CONTENT STRATEGY
I partnered with the Content Strategy team and the Open Source team to help create voice and tone guidelines for marketing copy and best practices for writing quality documentation.
extensive documentation
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.
Although this project had a rocky start (sighhh COVID) I was incredibly pleased with how it was received not only by content authors, but the third-party developer community as well. Two months after launch, we had some exciting statistics that validated the effort put into improving the publishing platform:
43
5%
3
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.