From Open Source to Open Design our Journey Building our First Ever Docker Desktop Extension

When we think about open systems, it’s usually in the context of tech tools and stacks coming from open source software. Yet, every tool that developers love to use also needs a great design team behind it to make sure it has an intuitive and delightful developer experience.

Our team at Slim.AI was recently chosen as a Docker Extension Launch Partner and given the task of creating one of the first-ever Docker Desktop Extensions. Designing for the developer’s local environment allowed me to explore the core value design brings to the developer experience, and to build an open design framework that contributes meaningfully back to the design community––which oftentimes, sadly, is a more closed ecosystem than open source software development. This enabled me to bring the open values of the Docker community into the design community.

First, here’s some context on who we are and the task at hand: At Slim.AI we’re trying to make it easier and faster for developers to build secure containerized apps. Of course, Docker is a natural partner on this journey, as they introduced containers to developers and the world, and our popular open-source project DockerSlim relies on Docker to build containers. So, it’s no surprise that we were very excited to be one of the very first partners in the Docker ecosystem to introduce a Slim.AI Docker Desktop extension.

With the unveiling taking place at DockerCon, we had just about six weeks to concept, design, code, and user test a Docker Desktop extension for the newly minted Extensions marketplace. Here is our journey through the extension build process to building what this first extension looked like, and some insights into building an open design system that the community can use to build their own Extensions faster.

Design to Enhance and Not Hinder Projects

With the tight time frame, we had to quickly understand how we channel the resources of a small but effective team — two engineers, one designer (that’s me) and a product manager — to deliver an MVP that was useful enough to our users as a first iteration but not over-designed and over-engineered.

One of the very first things that became apparent to me, as the designer in this process, was the role I would play in the project’s success. Design is a double-edged sword. While it can bring immense value to projects, other times it can also serve as an obstacle when the design team is not focused on what's key to rolling out a first and good enough iteration. A good designer will bring enough expertise to enhance the project, and be flexible enough when necessary to not jeopardize the delivery, particularly within tight deadlines.

With this in mind, it was clear to me that where I could contribute most meaningfully would be in the visual design, as the UX of the Slim Developer Platform is already well-defined. This would be an exercise in translating our UX as closely as possible within the constraints of the third-party requirements and guidelines for working with the Docker Desktop app.

Working with Third-Party Requirements & UI

One of the primary considerations involved when defining our design requirements for our extension was the Docker Desktop design guidelines and style guide we were asked to follow when building our extension. One example of design requirements dictated within the Docker guidelines was around accessibility, and the requirement to be able support both light and dark mode.

We began with a very short discovery and research phase to create a rudimentary proof-of-concept (PoC) so that our developers could start building. As an early-stage startup, we tend to work quickly and in parallel, and I was designing the interface at the same time as our product and engineering teams concepted which features to include. It was in true agile fashion.

With the guidelines in hand, we came to the conclusion that this would provide us a really great opportunity to take a much more utilitarian approach to our design elements. By having our constraints dictated by an external entity — in this case, the experienced and thoughtful design team of Docker Desktop — we needed to be very cognizant of how we translate our UX into a completely different design system.

We immediately understood that we could not just copy and paste our existing design into Docker Desktop. For starters, our core features on the Slim.AI platform are built for a SaaS context, built for web with a design system of their own. Our SaaS’s design is built on icons and imagery, allowing users to gain an intuitive understanding of our features in a cloud-based SaaS context. Plugging this into a local development context with a very different product design would require a much different user experience and journey.

[comparison of design for Slim dev platform vs. design for docker desktop]

Since we were designing for developers “at work” on their laptops and desktops, we had a greenfield opportunity to focus on the utility and function of the features we want to include in our extension, rather than the flashier design of a web product.

We started by defining which of the many different features in the Slim platform are our most important for local development, as we wouldn’t be able to repackage the entire Slim experience into one extension. The next task was to figure out the best way to integrate these core features into a different design system where their utility would be at the center—very clear and well-defined. We opted for a clean, text-based visual approach to deliver the best experience.

Going Open with Design

The Docker team provided a style guide and best practices for Extensions, but left it to Extension partners to design their features the best way possible. Being my first time designing within the Docker Desktop ecosystem, I didn’t know which components and elements would be available to leverage.

While its common to find community-driven design toolkits for more established extension communities (Chrome extensions, for example), the Docker Extension system was too early days for these to exist. With design often being perceived as a black box, I realized this could be an excellent opportunity to bring our open source DNA into the design community.

As a designer, I believe in creating excellent design systems and component libraries that are really easy to use. This empowers engineers to be more autonomous and leverage these to create rapid PoCs. This helps build a strong and open design culture while also empowering engineers to innovate.

To be clear, my community contribution isn’t endorsed by Docker or the Extensions program, though I do appreciate the highly constructive feedback provided by the Docker Design team.

By creating an open design system and sharing it with the Figma community, I hope to enable and inspire those looking to build their own Docker Desktop extension by providing a UI kit with responsive elements and components. I figured this could serve as a useful contribution to the community, but even I was really surprised to see this pulled by more than 100 designers in the community over the next few weeks.

Stay tuned, as the Docker design team will be releasing their own official design system for Docker Desktop Extensions. I’m excited to see that, and to see how a community of Extension builders and designers can help each other create great developer experiences.

[Screenshot of UI Kit and Link to Figma]

From Design to Implementation

After we finished with the design side, we quickly had to deliver an MVP so we could test it out and get feedback.

While we were able to reuse a lot of the design and engineering primitives from our SaaS, the technical and design implications of Docker Desktop offered an opportunity to rethink some of our interaction models. For example, when working inside the Slim.AI extension in Docker Desktop, a user is able to interact with local images that are not necessarily linked to a remote registry such as Docker Hub, Amazon Elastic Container Registry, or Google Container Registry. This introduced some interesting changes in what data we could display per each image. Digests of images are not available for images that have been created locally, and this single piece of data is used widely in many locations across our SaaS, often serving as a “primary key” for referencing images.

Because the development loop can be so much tighter on a developer’s desktop as opposed to a web portal, the extension environment can greatly reduce the amount of time an application developer has to wait to scan containers for analysis or compare images build over build. While public container analysis and container management are primary uses of our SaaS, local processes like optimizing and debugging local containers are critical for desktop.

We had to really put ourselves in the shoes of local developers and find new interaction models that clearly communicating the potential value of a flow to a first time user. And these local interaction patterns open the door to new innovations that we’re excited about exploring in future releases.

Tips and Considerations when Building Your Own Docker Extension

As we went into this project, we weren’t sure how it would turn out, but we can honestly say that we were pleasantly surprised by the outcome from this ambitious design and coding sprint, and early user testers have responded well to our MVP.

Below are some of the things we learned in the process, and we’d recommend those looking to quickly build their own Docker Desktop extension consider before getting started.

• You can’t have it all. The most important lesson we learned was that you can’t just embed an entire product or platform into another platform and expect it to translate well, and provide the same experience.
• Keep it simple. If you’re planning on creating a Docker Extension, you’ll need to first do some research and define the key features from your product that provide the greatest value, while simplifying the experience so it works well within the target platform and ecosystem. In this case it’s the Docker Desktop, but this is true when embedding your functionality into another platform.
• Optimize the local experience. You need to consider the existing and known workflows in your product, as well as those on the developer’s desks. Make sure that if existing workflows are not completely intuitive when being used locally by developers, rethink how they can quickly understand the value of the different features, and rapidly get started within the Extension’s experience and workflow.
• It takes a community. One thing to remember is the resources you have in the process, and to leverage them early and often. This is where I’d like to give a shout out to the really supportive and helpful Docker design team. It’s no easy undertaking to have to define guidelines and a style guide to work with a diversity of different platforms and tools, and also have to support the different design teams working on these projects (all within tight deadlines). They really did an excellent job of being both very responsive, as well as providing actionable design and usability feedback.
• No need to reinvent the wheel. When possible, leverage assets contributed by others who have done it before you, particularly on tight deadlines. When you find yourself in a position to contribute back by being the first in uncharted territory, be sure to pay it forward and contribute back.

We hope you found this helpful, and are as excited as we are about the launch of the Docker Desktop extensions marketplace. Our next challenge will be to get real user feedback and constantly improve the user experience of Slim’s extension within Docker Desktop.

Have feedback for us? Want to share your Extension with us? Drop into our Discord and say hi.