We’re stewards, not owners: User experience and open source

I work at a relatively large organization. There are many divisions and teams, and products within the larger product. At this organization, I design for people using these products.

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, merchants and shoppers, there’s an ecosystem of store builders and extension developers who influence how the products are built.

Not only can we not assume knowledge of user needs, but we also can’t assume knowledge of the needs of these developers. We’re stewards, not owners of the experience. This relates to actual design work, but also designing within an organization.

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 may 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.

In my experience as a consultant for large enterprise companies like Experian, IBM, and Ericsson, the first thing I did was draw an org diagram of who are the key stakeholders and who needs 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.

Perils of team silos

My first project at WooCommerce was a huge failure. When I started back in mid-2019, our focus was on order management. Specifically expanding and improving upon the order status system. After 6 months of design work, a technical research spike concluded that these changes would have catastrophic effects on the platform and the project was killed.

What happened there? First of all, I wasn’t comfortable using my previous experience as a guide as I was navigating this new organization. (That’s on me, and for another post.) Most importantly, we didn’t socialize the early stage work and start collaboration early enough with engineering.

Other unfortunate circumstances that can happen as a result of team silos.

  • An entire project team not knowing whether other teams have already tried what they’re doing, or potentially already designed or built it.
  • A division repeating the work of another division, learning in the same way, potentially failing in the same way. Or succeeding in the same way but taking 4 times as long as they could have with awareness of the historical work.

Overall, lots of wasted time. Besides the loss of roadmap time and people hours, why else is this important?

Each team’s work impacts the customer experience

Conways law states that organizations create software that 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 that create our extensions also create the image of our organization. The software that exists today is a reflection of the entire open source ecosystem that the company relies on.

This is a tough problem to solve without a top down product led approach to software. Some ways to improve the fragmentation include the following.

  • Encouraging open dialogue and collaboration among teams, actively discouraging signs of territoriality.
  • Starting to intertwine narratives between products.
  • Leadership can regularly create opportunities for cross-team collaboration in the form of workshops, making connections, and demos.
  • Bring the whole team into the ideation phase. I love hearing engineers talking about the ideas they proposed during brainstorming sessions.
  • Building in APIs or other means for teams to take advantage of your work. This also means sometimes sacrificing ease of development for focusing on the goal of larger cohesion.
  • Implementation of a design system with a dedicated design systems team.
  • Lastly, everyone could think of our product as a holistic service. We need a holistic vision of the product, thinking of it as a connected experience rather than a series of experiences with different owners. It’s like how we have a belief in democracy, it just needs to be ingrained in our psyche.

All of these ideas are just the tip of the iceberg. I’m facilitating a workshop at our upcoming division meetup on this topic, and I’m so looking forward to hearing everyone’s thoughts.

Solving for the right thing

Curse of knowledge

After 15 years of working as a designer, I can sometimes use my gut instinct to say what I think is best for users. However, I can never assume that I have all the knowledge of what users really need. Most of the time my experience actually takes me further away from that clarity. This is the curse of knowledge, and a trap for product development.

UX theater

Here’s another trap that I see designers falling into. There’s an experienced leadership team who specifies a particular solution. As designers, we want to do our due diligence to “test” this solution, so we do a round of research to validate the existing idea.

Do you see the issue here? We don’t know the problem, nor do we understand if the problem is important enough to be solved. We also don’t know if this particular solution is the best way to solve said (unknown) problem.

I’ve seen teams try to back into the problem to solve, after starting to build a solution. Once a feature is being built, we say, “Here’s why we’re building this.” Designers try to validate the time they’re spending on it by creating the problem to solve out of thin air.

This problem of “UX Theater” is articulated well in this article by Jesse James Garrett, co-founder of Adaptive Path. Organizations can easily use UX testing alongside their confirmation bias to falsely prove the need for certain features.

Much research and investigation needs to be done to understand the why, to be able to articulate the why to internal project teams, stakeholders, and the community, and to understand all risks and dependencies.

How much research?

Just enough. Just enough to not fall into the trap of only validating existing ideas. Just enough to find out what do people actually need.

Open source presents an even greater challenge in this regard. We truly are the facilitators of a project that the community shares. This means listening to the community, but understanding that the loudest voices shouldn’t necessarily have more influence than others.

We don’t have anyone with the title “research” at my company. When you’re working in a lean research environment such as this, the most important part of research is establishing your goals, hypotheses, and who to talk to. Getting the right people to talk to, i.e. quality is more important than the quantity of research.

It takes time, and that’s ok

It may be anxiety-provoking to not be churning out features at a steady clip. The risks of churning out features far outweigh the rewards, however. Moving fast on unvalidated ideas that users don’t need leads to wasted time and reverted code. If the feature is left in the product with no measurements for success, it’s like a potentially useless appendage taking up space and adding clutter to the UI.

There’s great power in grounding business decisions in real human needs. Products develop faster, are better quality, and the whole team is more fulfilled because they understand the Why behind what they’re building.

Some possible activities to discover needs and craft your Why.

  • Hire research experts and give them free rein to do their thing. One of the most inspiring talks I’ve seen was Indi Young at An Event Apart in San Francisco. She is the OG researcher, and her book Mental Models: Aligning Design Strategy with Human Behavior is the foremost authority on this topic. I wish everyone would read this book as the methodology truly gets to the heart of defining the problem to solve.
  • Encourage research best practices for self serve models within the organization. If research conducted within the organization is ineffective, there will continue to be no business reason for it.
  • Show what might happen if you don’t spend the time defining the problem. Conduct a pre-mortem for the kickoff of large projects and let everyone in the project team share their thoughts on how the project might fail. Harvard Business Review recommends taking time for this step in the process to mitigate risk of failure.
  • Any of the activities contained in the IDEO design kit. My favorites include the Journey Map and the Five Whys.

Those are a few thoughts on how begin aligning user needs with the business strategy, but this work needs to happen alongside integrating more UX metrics and user-centered KPI’s into the organizations’ objectives.

Designing an open system

In the past 4 years, I’ve learned what it’s like to be a designer at an open source software company. I’ve learned to consider extensibility with every design decision, which means asking the question “How will our network of extension developers take advantage of the new experience?”

In recent years we designed WooCommerce Home with three extensibility points: The Inbox for informational messages, a Task list for the sole purpose of extension developers (including our WooCommerce-owned extensions) being able to surface important notices for merchants in the admin, as well as another area for store management links.

This is the new Javascript layer of the product so there were very few extensions already integrating with the new UI, but design decisions were made with them in mind.

When working on a redesign of any legacy area of WooCommerce admin, there’s a literal minefield of extensibility points to consider.

When you don’t even know what you don’t know

There are times when we know what we don’t know. Then there are times like this, when we’re creating designs for a platform that can be extended with little regulation, when we literally don’t know what we don’t know.

Here are some ideas for making this process easier, and making the case for a redesign more palatable.

  • Run an audit of every extension that could possibly plug into this area, and create journey maps to illustrate how the UI is adapted for their specific purpose.
  • Connect with extension devs to learn their needs and pain points, alongside the builders and merchants who we tend to place more focus on.
  • Keep a running list of most popular extensions and always incorporate their needs into design decisions.

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 in the process of learning and find it helpful to organize my thoughts on this topic. I hope this can be a useful guide for others.

Published by Elizabeth Pizzuti

Design, art, and cats mostly

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.