I was brought on to Mural to lead the design of the developer’s experience to discover, learn, test, and deploy plugins, apps, and webhooks using the newly developed Mural Public APIs. To launch, we focused on apps. Mural had never approached a developer user persona before, nor had any workflows to support this new set of jobs and interactions between the developer, admins and general users who would eventually discover, enable and use the tools shared by the developers.

How the form started. All cap labels, little to no hierarchy, overwhelm of content.

The team

A designer of one, I worked hand in hand with the product manager and lead staff engineer. The team included an additional five engineers who I also collaborated with to release each section of the new product. Mural is a completely remote company so we did everything remotely both async and in real time. Using our own product to compile notes and feedback, Slack, Loom to send quick video messages, and Figma comments; we were able to continuously collaborate.

User needs

The engineering team had put a basic form in place as a starting point for testing with select design partners. While the form got the basic information required to connect an app, it was not a seamless or intuitive experience. We had a lot of questions that needed to be answered:

Are the requirements to connect an app understood?
What does a developer need to build an app with Mural Public API?
What is the purpose behind a developer creating an app for Mural?
How does a developer troubleshoot?
Who is the developer creating these apps? Are they freelance, in-house, are they the decision maker or the doer?

We had a limited budget for research, and while Mural had a research team, we were not a priority of their backlog. I therefore lead research while elevating the temporary form in to a walkable flow, breaking down focuses so we could better know our users while also releasing minor improvements.

Personas

To narrow my research the team came together to identify what kind of developers we were focused on. I lead a few activities so that no one voice lead the conversation but senior through junior team members could be heard. We identified four personas for our team to consider:

In-house developer - This was our main user. Due to our enterprise customers' needs we had already seen a demand from these customers to connect bespoke tools to analyze data derived from collaboration activities. This developer was not the decision maker, however they could be the investigator that would advise the decision maker if it was worth the continued investment in Mural due to their needs.
Freelance developer - A secondary persona. Due to the nature of the app market and the fiduciary opportunity for developers to build a name for themselves by building public apps for use. This developer had a range of experience from student to expert who may have already sold a few products on Apple or Google marketplaces. This developer needed examples of client needs and opportunities to innovate in the white board field.
Admin - A required persona to allow app sharing across an organization. This user could also be the decision maker who tasks the in-house developer to investigate the opportunity to connect apps for team use.
Knowledge worker - The end user of the developer’s app. They need to be able to discover, enable, and use the app under their credentials.

Admins and knowledge workers were users already depicted by Mural’s research team. My prerogative was to uncover and identify the in-house and freelance developers and their JTBD (jobs to be done.)

Research

I broke research up into a few segments based on the questions listed above. Starting with market research I compiled the following:

App management standards
Open source studies of developer positions, jobs, and corresponding behaviors
Developer learning and support tools

The findings from this investigation taught me a few basic requirements to support a developer:

Provide in depth documentation. Beyond regurgitating the form fields and rewordign the instructions, developers need small tutorials to understand the definition and requirements within the code to pass. There is no consistency across products on how to build an app. Therefore, no matter the seniority of the developer it’s important to break down all code requirements, even if they feel like basic protocols to the in-house team.
Allow movement between resources. A developer is never looking at one resource. They usually have a few windows open to complete one task, especially if it’s new to them. Confining a developer and making it hard to find all the resources they might need will quickly result in the developer giving up and advising higher ups that the process is too expensive to proceed.
Make it easy. The more intuitive the flow and straight forward the language the faster the developer can get their job done. Provide video tutorials, sample apps, community forums and ways to test and validate their code.

Adjusting for failure

Due to the findings, validated with conversations with design partners, it was clear that the minimar release would have left our users in a lurch. I made a case for design scope increasing from modifying the form to defining the end to end experience from marketing, API documentation, testing, to sharing and making public. Without this end to end roadmap we would lose developers and potentially business relationships. This scope increase would not change delivery timelines, but would add backlog priorities for continued release from Beta to GA.

Ideation

My next step was to take these learnings into form. Starting with sketches and journey maps I charted out the functional necessities with human centered interactions. We already had a bare bones functional form but bare bones was actually harder for the user. Therefore, in my ideation I approached the question - how can we do this simply while innovating the way we communicate necessary steps?

Technical roadblock & innovation

In addition to the broken workflow, we had a backend issue that was blocking us from the most important step in the process - sharing. I worked together with the lead engineer to unpack permissions across the product and define required authorizations to allow secure sharing across subscriptions types. Workspaces were defined in the backend differently for enterprise, business, teams+, and free plans. This would require our team to create four different architectures to accommodate this backend structure.

The way most app management systems were designed, the developer would identify the type of account and the permissions. However, since we wanted a developer to be able to share apps widely and not be constrained by the different plan types we ran into a roadblock where we wouldn’t be able to identify the type of plan the app would be shared to. This also made things more complicated for the developer themselves.

Instead we turned away from industry patterns and looked at sharing models for more common platforms, such as YouTube, Vimeo, and Patreon. This removed all of our backend blockers for quick release as well as simplifying the experience for the developer. The decision was then put on the admin who was the user who had both the power and knowledge of where to enable the app and therefore permissions would be auto defined based on the parameters set by the admin and the plan their organization was under.

Solution

The team devised timed releases to get out prioritized needs to beta testers leading up to a full GA release. Starting with documentation updates so that the beta testers could create basic apps in the time it took the team to update the app management space and sharing capabilities. To finalize the discover-try-buy experience we worked with the Marketing team to release a landing page for developers on Mural’s primary site. The flow allowed a developer to start from any point and navigate through the entire flow based on their unique working practices.