We’re Stewards, Not Owners: User Experience and Open Source

At WooCommerce, I design experiences that store builders, merchants, and shoppers use. There are many teams within our division, and many of the experiences we design cross multiple teams, and even cross multiple divisions.

To add another layer of complexity, the products we design and build are open source. This means that beyond the end users of the product and teams who focus on creating these experiences, there’s an ecosystem of store builders and extension developers who influence how the products are built.

Not only can we not assume to have complete knowledge of user needs, but we also can’t assume knowledge of the needs of other teams and stakeholders, or the builders who rely on these products for their own businesses.

To solve the gnarly challenges of designing for open source software, cross-team and community collaboration is key. In this post, I’ll share the results of a workshop I facilitated at the Woo Division Meetup in Vienna, Austria, and highlight the wonderful synergies happening throughout Automattic.

Perils of team silos

In my previous life as a consultant for enterprise companies like Experian, IBM, and Ericsson, my first step on each project was to draw an org diagram of the key stakeholders and those who needed to have awareness of our work. This helped our teams to understand who to involve in any of the bigger project decisions, and to make sure to tap into all existing institutional knowledge.

In an attempt to avoid silos, we strove to gain understanding and endorsement of the early stage work and launch our collaboration with all relevant teams. Why did we begin by reaching out to all relevant stakeholders instead of just starting the work ourselves and seeking approval later? What’s so bad about silos? 

Here are just some of the problems that silos create: 

• A project team may not know whether other teams have already tried what they’re doing; as a result, the team could repeat the work of another team, learning in the same way, and potentially failing in the same way—a waste of time and energy, from the organization’s perspective. Or a siloed team might succeed in the same way as the previous team, but take four times as long to complete the job as they would have with awareness of the historical work.
• When working on a redesign of any legacy area of WooCommerce admin, there’s a minefield of extensibility points to consider. When we’re creating designs for a platform that can be infinitely extended, we don’t know what we don’t know. Without feedback and buy-in from the community of Woo developers, new design initiatives can easily fail.

The perils add up to lots of wasted time. Besides the loss of time, why else is this important?

Everyone’s work impacts the customer experience.

Conway’s law states that organizations create software which reflects their internal organization. With many teams working in silos across an organization, this creates many conflicting experiences that impact the user experience.

At an open source company, the ecosystem of developers who create our extensions add to  the image of our organization. The software that exists is a reflection of the entire open source ecosystem that the company relies on.

Beyond relying on leadership to align the structure of the organization with the needs of the software being developed, there are opportunities for everyone to shape cross-team communication and collaboration to achieve project success.

Project Success

During a cross-team workshop at the Woo Division Meetup—a workshop involving a lovely group of Woo designers, Engineers, Happiness, and Marketing folk, we generated ideas to overcome the challenges silos present.

We used an example hypothetical project to guide the discussion—a unified Woo reporting dashboard—which includes useful data points from a wide range of sources including Woo core Analytics, Payments, and Marketing extensions.

Especially for larger projects like this, the main themes that crystallized in our workshop were upfront planning, collaboration, and clarity of communication at each stage of a project.

Here are some ideas to experiment with in your projects.

In the beginning of a project, create an (internal) kickoff meeting.

• Early on in a project, it’s useful to identify potential stakeholders within the company that may be interested in the outcomes of your project. Create an end-to-end map with all responsibilities, activities, and needs from other teams. This prepares the project for success by starting with collaboration instead of trying to bolt it on later.

• In this kickoff meeting, you can identify dependencies, build in time for creating new components, align design and development requirements, negotiate timelines with other teams, and, most importantly, clarify outcomes for success. Throughout the meeting, return to those outcomes to make sure everything you’re considering tracks with and contributes to those desired outcomes. 

• The kickoff meeting is also the time to think about your adoption plan. First, determine who’ll benefit the most from the new feature and how it fits into their workflows, then define what success looks like for the adoption of the new feature – this could be in terms of user engagement, increased usage, or other metrics. At project launch, monitor and evaluate the success of the adoption plan.

• It’s also quite useful to create a cross-team guild of interested parties that might have input into the design and development of this new feature or update.

During a project, working alongside the community is key.

• In an open source project, strive to design out in the open as much as possible. When new designs are finalized internally, create a usability test, gather quick data to validate the new designs, and provide a baseline for any feedback that might roll in. (Or iterate if the test doesn’t perform well.)

• Create a feedback loop and be prepared to iterate based on what you learn. Getting valuable community input is only the first step. There should be time built into the roadmap to incorporate any relevant ideas into future project phases.

• Regularly communicate the “whys.” A public roadmap is cool, but understanding why each feature is on the roadmap—if it’s based on solving real needs that users and builders are dealing with, will create even more buy-in and support.

• Another idea that you see WordPress core doing really well, is to create a newsletter for regular sharing of progress updates out to the community.

To prepare for project launch, create guides, clear documentation, and helpful resources for users.

• Get a technical writer, happiness ambassador, and marketing friends assigned to the project early on. There are a multitude of benefits for doing this!

• Clear documentation can encourage adoption of the new feature, as more users are likely to try it out and continue to use it if they feel confident that they can do so effectively. This documentation can also encourage contribution, if potential contributors understand how the feature works and how to make changes to it.

• All of this communication can also reduce support requests and increase trust. Users may feel more confident that the feature is well-designed and well-maintained, and it could attract more partnership and collaboration.

Here are the slides we used to guide the discussion.

All of these ideas are just the tip of the iceberg, and I hope a takeaway from the workshop was to challenge ourselves (even if it’s uncomfortable or spicy) and put something brand new out there to improve our projects.

In closing, your team doesn’t know everything.

It’s easy to get into the habit of feeling ownership of your particular area. For example, I work on a team that builds payments experiences, and I might start to feel responsible for knowing every feature or experience that’s needed for users. I might start to feel I know this better than other teams at the organization.

However, everyone in the organization and larger open source ecosystem owns the user experience just as much as we do, and no one owns it more than the users themselves.

Like The Fellowship, we’re a set of totally different beings united by a common goal: a unified user experience. Rather than a series of experiences with different owners, we can be similarly aligned by a common objective.

It takes hard work and a growth mindset to truly listen to these internal and external voices, to be more of a steward for the experience. I’m still in the process of learning, and I hope this can be a useful guide for others.