If you are a developer building anything using Adobe technology, you have likely used the Adobe Developer Console at some point in your process. Whether you’re creating an Adobe XD plugin and distributing it, getting API keys, or setting up the ability to call events, the Developer Console is the place to go to get everything you need.
When the Developer Ecosystem team set out to reimagine the Developer Console experience, its experience designers were tasked with creating a new look and feel for it. The goal was to create an experience that would allow room to grow for Adobe’s extensibility ecosystem while providing a great experience for end users — the developers creating apps, integrations, plugins, or extensions with Adobe solutions.
Collaboration is vital to a redesign’s success
From the very beginning, our design team closely collaborated with both the product manager and engineering team for the Developer Console to realize their goal. This collaboration allowed us to understand the business needs and technology constraints from the beginning and helped other teams understand the users and their needs.
The developer console serves a lot of internal product teams and these teams were our main stakeholders for the redesign project. To make sure we were serving them properly, one of the key components of our initial research phase was to conduct stakeholder interviews. We wanted to hear in their own words how developers used the Console and which pain points needed to be addressed for them. This also gave us an opportunity to learn how these teams wanted to grow their extensibility ecosystems in the future. We quickly saw patterns emerging between teams that allowed us to focus on solutions that could work for everyone.
From Carmen Sutter, the group product manager for Adobe I/O Developer Ecosystem:
One of the tricky things about building cross-functional and cross-solution products, is how to create a consistent experience for your end users, while incorporating requirements and feedback from dozens of stakeholders. From the start, we worked closely with our internal stakeholders and made sure they were a part of this journey by inviting feedback, discourse and sharing the rationale for the decisions we landed on.
Through these interviews, we were able to gain an understanding of who our users are and their processes, where our stakeholder teams want to go in the future, and the internal goals and constraints we needed to meet. From what we learned, the design team worked closely with product management to create a set of design principles, vetting them with engineering and stakeholders before locking them down. We used these design principles throughout the process as a guiding light for any new features, functionality, or design decisions made.
Let’s take a closer look at each design principle and some examples of how they are brought to life in the redesign.
1. Set me up for success.
Help me, the developer, throughout my experience. The Developer Console should understand who I am and the context I am in during my journey. Help me understand the implications of the decisions I am making. Make the defaults helpful and the experience intuitive.
The key to designing tools for developers is understanding the different types of developers that are using the Console and their overall processes. We needed to provide context and guidance for newer developers, while allowing more experienced developers a faster workflow.
This can be seen in the helpful guidance areas throughout the experience.
These areas provide contextual help based on the page the developer is on, but can also be closed to minimize content and maximize workflow.
2. Be flexible and cohesive.
The Developer Console supports a number of different use cases that vary widely across personas and Adobe products. The experience needs to scale from the simple needs of individual developers to the more complex needs of enterprise organizations without losing consistency.
The previous I/O Console had limitations on growing its functionality. We set out to design a new tool that has plenty of room to grow while providing an easy and cohesive experience for developers. One of the top examples is the introduction of projects.
With the I/O Console, developers were limited in what they could create at once. In the new Developer Console, a project is a container for all the pieces the developer might need to create an app, plugin, or integration. Multiple APIs, Event registrations, and other services can all be connected together in the same project.
3. Do it here.
Reduce the number of tasks that take a developer out of the context of the Developer Console. Provide tooling and resources within the experience that help developers throughout their journey, from experimenting with a service to getting insights and analytics on their creation.
One of the common pain points we heard from external developers and internal stakeholders was the amount of times they would have to leave the I/O Console to perform a task, then come back to complete it. From research, we know that context-switching and forcing the developer to leave the main surface to perform dependent actions can lead to a reduction in overall engagement. The redesign implemented several new functionalities that allow the developer to complete tasks within the Developer Console.
One of the top goals for the redesign was to get the developer to the code as quickly as possible. After all, the Developer Console is just a tool in the overall journey to creating.
4. Take care of our own.
Support our internal product teams and the varying needs they have, from onboarding services to the Developer Console to understanding their developers’ journeys. Provide teams with better internal experiences, APIs and services, and tooling to facilitate their goal of creating a thriving developer ecosystem.
The Developer Console serves many teams within Adobe. We worked closely with these internal teams from the beginning to make sure we fully understood each of their goals, as well as the needs of their developers. The redesign has introduced new ways individual teams can surface the information and resources they know their developers will need, when they need them. The redesign was also built to be API-first, allowing internal teams to perform Console functionality outside of the UI.
In future updates, we’ll be looking to introduce even more flexibility for product teams to provide the right tools and resources for their developers within the console.
The Developer Console redesign is the first step to fulfilling the design principles above. The experience design team, product management, and engineering teams continue to work together to build a better experience for external developers, who are working hard to build great things with Adobe technology. We all look forward to hearing your feedback on the new Developer Console!