What I learned while designing an ecosystem

Lucy Denton is a UX designer for Atlassian based in Sydney, Australia. Her role is within the Atlassian Ecosystem, which means she helps out with creation of third-party add ons and integrations for Atlassian products. Before her talk on developers developing empathy at UX New Zealand 2017, Lucy shared some tips for designing an ecosystem.

Software products are rarely used in isolation of each other. As a company, it’s not enough to have a single great product in the market. Today I can send a friend my Google Maps location from a Facebook message, add tasks to my personal to-do list from my email, sync my Sketch files with my InVision prototypes… it all just flows, no matter what ‘product’ I’m in. As designers, we have to consider our users’ day-to-day workflows outside the immediate products we work on.

I’m a UX designer in Atlassian’s ecosystem team. Our ecosystem is a marketplace of apps that end users can install in our products. These could be integrations with external products, such as PagerDuty — a product used for incident management in operations teams. Apps could also be extensions of the existing product functionality — for example, timesheet functionality in Jira, Atlassian’s project management tool.

Apps are mostly built by external third-parties, and are sold on our Marketplace. I’ve been working in the ecosystem for almost three years, and it’s challenging from a design perspective for a number of reasons. For example, when integrating two products, should the user be in the context of product A or B? How do different design patterns and branding come into play? How will users recognize information and actions? When something goes wrong, where do users go for support? When we have multiple apps installed, how do they scale? These are some of the things that used to (and sometimes still do) keep me up at night.

Here are some lessons I’ve learnt about ecosystem design over the past few years working on the platform and with the people who make Atlassian apps.

Keep it simple, keep it focused

The goal of building integrations is not to embed entire products within another product, or build features for the sake of features. Sounds obvious, I know, but sometimes these things need to be said.

When creating integrations we have to consider the user’s workflow when using the two products together. Not just ‘how people are using InVision’ or ‘how people are using Jira’. But rather what are users trying to achieve when using InVision — a digital prototyping tool — and Jira together? For example, the use case here is a designer picks up an issue and creates an InVision prototype to convey their work to the developers. They then attach the prototype to the issue and developers refer to it during development. So then we should only give our users what they need to achieve those goals. Any additional features from the secondary product brought into the parent product will only confuse and distract users. InVision created an app to streamline the process for designers to attach prototypes to issues, and for developers to view and work from prototypes within the tool they are familiar with, Jira.

Remain contextually relevant within the parent product. Think about the hierarchy of information in the parent product and when the user would be interacting with the secondary product or functionality. For example, consider a PagerDuty (operations management tool) integration with Jira. Jira has a global level (all projects), a project level (all issues within that project), and an issue level (relating to individual tasks or users). Some people would put an integration with PagerDuty at the global level, because PagerDuty is important. It’s a product like Jira is a product, so it deserves to be at the same hierarchical level. However it makes more sense for the user to interact with PagerDuty at the Jira issue level, as a common use case is for teams to create Jira issues for PagerDuty incidents and link the two. Therefore it would make sense for the integration to be a part of the issue view experience.

Adding “random” features is another trap that’s easy to fall into. A colleague was building a screen recording add-on for Jira for a ShipIt (Atlassian’s internal 24 hour hackathon). The idea being you might be filing a bug and want to attach a recording of the bug’s behavior. The add-on was on the issue view, and consisted of a big blue primary “start recording” button and a secondary link to attach a recording. This seems fine, but if we think about it, it’s very unlikely that the user would want to start the recording from Jira. They’re more likely to find a bug, record it, then head to Jira to create a ticket, add details of the bug and attach the recording. Overcoming this meant a simple change in the primary call to action. We optimised the design for attaching recordings from a popular web screen recording tool.

Provide meaningful actions

Apps bring information into our products. Generally, people need to use this information to do something, probably make decisions. We encourage app builders to provide the user with context relevant actions to enable them to ‘close the loop’ on information being brought into the products. Actions like “acknowledge this incident” from within Stride (Atlassian’s new team communication tool) are perfect. Actions like “change my PagerDuty profile picture” don’t count as ‘closing the loop’ and probably don’t help users achieve the goals I mentioned above.

Actions must also remain contextually relevant within the parent product. Consider where actions currently sit within the parent product, and where the app’s actions belong. In some cases in Atlassian products we call out standard actions, such as edit page, create new page, watch page, etc. Then we have a “more actions” menu for those secondary actions, page history, export to PDF.

When building or designing an app, your app is probably at the front of your mind. People often try to call out the app’s actions, and make them primary and prominent on the screen. However, then we end up with actions like “see Confluence page viewing analytics” next to “edit page”, whereas that actually probably belongs in the “more actions” menu. The hierarchy ends up not making sense, and it makes it hard to recall or guess where actions and information are located.

Be harmonious with the parent product

We recommend that all apps for Atlassian products follow the Atlassian visual and interactive design language, which is very well documented in our Atlassian Design Guidelines. This means third-party apps should use our button styling, fonts, colors, our UI components and defined patterns. Why? When a user is interacting with these apps they are in the context of the parent product (Jira, Confluence, etc) and they already have expectations around how these products should work.

Using the secondary product’s own UI components or branding could cause conflicts. I was working with a company building a Jira integration. Their branding was all orange, and they used orange primary buttons in their own products. When building their integration they also used an orange button for the primary action. But what does an orange button mean to a user in Jira? We use similarly colored yellowy-orange buttons as a warning when a user is about to perform an irreversible or potentially destructive action, such as deleting a Jira project. So for a Jira user an orange button has negative connotations, and the user’s immediate reaction is hesitation and caution.

But what about branding? Branding is important. From the parent product’s perspective we want customers to recognize the products they love, and we want customers to contact the app company for support as Atlassian can’t always fix problems with the app. We recommend apps use things like logos, watermarks and UI copy to represent their brand within our products without creating a jarring visual experience.

Be specific about where external parties can put stuff

Developers use our APIs to integrate their apps into our products. If the API could affect the front end or user experience it’s preferable to have a designer involved in the API development. There is an opportunity to be specific about where and what can be put in the parent product by technically restricting what people can do. This gives us the opportunity to create consistent patterns and use cases that third party app developers can leverage. This allows an overall more cohesive marketplace offering. For Atlassian, this was the case with the Hipchat and Stride APIs.

We optimized the design for a feed of information from a third party — this made most sense with a real time communication tool. We created different variations for recommended design patterns, depending on common use cases, and provided the front end code for third parties to use. 

The Jira and Confluence APIs were before my time at Atlassian, and now developers have more technical freedom. However we have guidelines that define what types of content belong where in the products, and recommendations for the interaction patterns developers should implement. Below is a graphic showing the guidelines for apps integrating with the Jira issue view.

Of course, these are just guidelines and in reality developers are free to use the platform how they wish. There is a tradeoff between making the platform more customizable which can lead to more powerful apps, and restricting what people can do with your products.

So, here’s my shortlist. These are the top things I’ve learnt designing an ecosystem:

• Consider the user’s workflow when using the two products or features together. Try to get out of the headspace of designing individual products, and think more about designing workflows.
• Remain contextually relevant and visually harmonious with the parent product. Remember the user is thinking and acting in terms of how they expect the product they’re in to work. Branding is important for ownership.
• Give users a meaningful way to respond to information you’ve brought into the parent product.
• Create detailed guidelines for external parties around what content belongs where in your products, and design patterns and visual styles they should follow.

Happy ecosystem designing!

Want to hear more? Come to UX New Zealand!

If you’d like to hear what Lucy has to say about developers developing empathy, plus a bunch of other cool UX-related talks, head along to UX New Zealand 2017 hosted by Optimal Workshop. The conference runs from 11-13 October including a day of fantastic workshops, and you can get your tickets here.