How the UX Team Works at Marley Spoon

Foundations

Foundations for consistent vision, direction, and decision-making:

• UX team principles
• Product principles
• Design system(s)
• Content framework

Foundations for working effectively:

• Continuous discovery activities and sources
• Dual track agile for defined process of collaboration with product & development
• Key Experience Indicators for meaningful feedback and understanding of the impact of our work
• Sourcing pipelines for user research activities
• Templates for recurring processes like research
• Tools to provide visibility into activities and capacity

Foundations for internal team culture:

• Team meetings and rituals
• A safe space for experimentation, sharing, and open feedback
• Inclusive processes and tools

Foundations for broader cultural impact:

• Workshops
• Popcorn time / Regular exposure to user research
• Sharing our stories through writing
• Transparency into how we work

Foundations for individual growth:

• Individual career objectives
• Annual learning days
• Learning labs

Principles

Outcomes, not output. We’re focused on meeting business and user goals, not creating features.

Problem-focused. We focus on solving business problems, not implementing features. When we start a project, the path or artifacts we’ll create may not be clear—but the problem must be.

Cross-functional teams. Our best work is created when we’re collaborating across disciplines on a continuous basis, from problem framing to shipping.

Continuous discovery. In UX, we depend on a deep understanding of our users and their needs. We strive to continuously learn about our users, their needs, and their challenges through planned and ongoing research activities and ongoing metrics like KEIs.

Externalize work. We need to get our work out of our screens and into the shared environment. By doing this, we’ll be able to share our activities, engage our colleagues in our work, and create transparency within the larger company.

Making > Analysis. The sooner we get a prototype in front of our team and users, the sooner we can validate our ideas. Data helps us to spark ideas and to validate our work.

Permission to fail. The design process gives us room to experiment, and to fail—it’s the easiest way to learn, fast. We create a safe environment for experimentation—through both our culture and our working process.

Small batch size. “Lean manufacturing” calls for low inventory and high quality. Along these same lines, we focus our energy only those activities that meaningfully move the team—and company—forward.

Shared understanding. We will build confidence and support from each other, our team members, and the broader organization by always creating a shared understanding of what we’re doing and why.

Dual Track Agile

Since we work closely with the product and development teams, we need to structure our working processes so that we’re able to commit to the complete design process as an independent UX design team. Design is usually explorative and can lead to unexpected outcomes, which can jeopardize tightly-planned agile sprints. Dual-track agile is a strategy for working effectively alongside agile product teams without falling into the trap of “ticket-based design.”

Dual track agile establishes Discovery and Delivery tracks. The UX design team works across both of these tracks.

The Discovery track encompasses the broader design process, involving research, ideation, prototyping, and iteration. When projects reach the end of a cycle on the Discovery track, the outcomes and artifacts allow implementation to begin.

The Delivery track encompasses ongoing two-week agile sprints. Since design requires continuous improvement, we’ll never be “done” at the end of a cycle in Discovery. We have to collaborate closely throughout development to refine and course-correct.

The UX design team maintains its own workflow on the Discovery track, and is involved in other team’s workflows on the Delivery track.

Continuous Discovery

We need to be continuously learning about our users, their problems, and their needs. Research activities should be ongoing and help us build a better understanding of the user experience on a daily basis. To do this, we have several sources:

KEIs. Key Experience Indicators act as a scorecard for the user experience in relation to user goals and outcomes. We’re building out a baseline for KEIs across our digital platforms, and we also identify new KEIs on a project-by-project basis.

UX insights repository. We have a database for UX insights, which captures qualitative feedback from users in Customer Care interactions, user interviews, and other sources of qualitative data. The qualitative feedback we collect in this database is reviewed on a regular basis by the UX design team, PMs, and other members of the broader organization to identify insights, themes, and opportunities. Our repository also helps us transform qualitative feedback into quantifiable data.

Project-based research insights. Whenever we conduct user research through usability studies or interviews, we have an opportunity to learn more about our users and their experience. We always invite the broader organization to join us in our research activities as observers in our sessions.

Insights from other research activities. We have a fantastic CX research team that’s constantly working to uncover new insights into the customer experience. From time to time, the CI team may identify and share issues in the customer experience.

The ideas we generate from continuous discovery are used as a source when creating new pitches, and for choosing which pitches will be tackled in upcoming cycles.

Projects

Our work is organized into projects, which are either small or large projects.

Small projects are smaller things, tweaks, or easy outcomes that can be done in anywhere from a day to a couple of weeks. These can include projects based on iterative testing to internally-driven initiatives, such as writing for the Marley Spoon Design blog. We typically have a good idea of what we will end up creating or what we will need to do along the way.

Large projects are big features or initiatives that will probably take 4-6 weeks (or longer) to get done. Large projects typically call for the complete human-centred design process, including user research and testing. We often start large projects without a complete understanding of the problem space, process, or outcomes.

All projects are initiated with a Pitch.

Cycles

Everyone needs a rhythm to their work. Sometimes, this rhythm is project-based (such as working as an agency, where large-scale projects kick off and end in the course of months or years). Other times, it’s sprint-based (such as in agile development teams).

Our UX design team works in cycles with a defined length. This introduces a sense of rhythm to our work, prevents scope creep, and improves our ability to decide what we’re working on in a regular interval.

A cycle contains a mix of small and large projects, each with a defined cross-functional project team.

These cycles have specific, unchanging start and end dates, which creates more predictable timelines and milestones. When projects begin to seem unachievable within a cycle, it’s a sign the team needs to refine scope until it feels comfortable achieving it within the cycle.

Cycles can align with 2-week development team sprints, particularly as they relate to large projects, but it’s not necessary.

Each cycle is named (e.g. “Cilantro”) to create a more distinct and tangible period of time. All cross-functional team members work on the same cycle at the same time, but not necessarily on the same projects.

We have 1-2 weeks between cycles to “cool down,” which could include “bug fixes,” writing and sharing what we worked on, and figuring out what to do in the next cycle.

Pitches

Ideas for UX projects come from everywhere. Some come from people on the design team. Some come from other departments when they identify a new business problem. Others come from insights and opportunities that arise from continuous discovery.

Choosing what we work on is a challenge in its own, but crucial for maintaining momentum, managing our time and resources, and delivering a real business impact.

We use pitches to capture ideas and help us decide what projects we’ll tackle in each cycle.

A pitch is similar to a creative brief, but not quite. The idea is the same: to capture context, problems, and generally propose what we should do about it. Pitches can be for any size of project, whether large or small.

Pitches help us create a collaborative working relationship between the UX / design team and the broader organization.

Anyone can write a pitch, and people can work together to create a pitch. We have a backlog on Clubhouse where anyone can write up an idea and share it, and where anyone else can take a look and has a chance to consider and respond to the idea.

This approach gives us a couple of benefits:

Consideration rather than reaction. When ideas arise in meetings or in Slack, we’re obligated to react to the idea, rather than mulling it over and providing a thoughtful response. When we share a pitch for feedback, it gives everyone the chance to consider it and make their voice heard.

The project story. Pitches capture the essence of a project in a single location in a way that anyone can refer to at any time if they need to catch up on a project, understand why the project was carried out, or even how to pitch a new idea in the future.

Pitches form our backlog. Not all of them will be acted on right away, or even ever, but some of them will be chosen to make it into the next cycle.

Choosing Pitches and Preparing for Cycles

After pitches have been considered and discussed by the design team in collaboration with other stakeholders, we choose pitches that will be tackled in the upcoming cycle. This is an art, not a science: we’ll make decisions based on existing data and analytics around pressing business and user needs, potential impact, clarity of purpose, and internal resources and capacity.

When a pitch is chosen for a cycle, it’ll need a team. The project team will be responsible for figuring out how they’ll approach the project. Not all members of the team may actually work on the project on a regular basis or across the entire project (for example, developers may not spend much time in the initial problem definition and design exploration phases).

Before each cycle begins, the UX design team will write a simple update to share the plan publicly with the broader company. After each cycle is over, the UX design team will write a simple account of the outcomes of the cycle, and share it publicly with the broader company. This gives our work transparency and visualizes the impact of our activities.

Between each cycle, we have project-team-based retros, and we reflect and adjust both our working processes and plans for upcoming cycles as a result.

Design Workflow

We use the design thinking process in our work in UX. Most large projects follow a general process of:

Discovery & Problem Definition → Prototype → Test & Iterate → Delivery Backlog

Discovery & Problem Definition. During this phase, the team needs to clearly frame the design challenge, KPIs & KEIs, and establish a tentative project plan and milestones. Research may be needed before this can be done.

Prototyping. The faster we can get to a prototype, the faster we can understand if our ideas work in reality like they work in our heads, and validate whether they solve the problems they’re intended to solve in a way that provides meaningful value to the business.

Testing & iteration. To test our ideas, we need to put them in front of users as soon as possible and see what happens.

Delivery Backlog. A UX project may largely conclude within a sprint with handoff for development, but no project is complete until it ships. While the project team must collaborate throughout the project, the balance of activity may shift between designers and developers from beginning to end. As a project shifts into delivery, designers need to be available and actively participating in review, QA, and refinement. We avoid waterfall-style handoffs.

Teams

Team members are those who are actively working on a project.

Each UX project has 2-5 people on the team (3 people is ideal), made up of 1 UX designer, 1-2 developers, and 1-2 other members (which could include folks from Culinary, CC / CI, or PMs). These individuals may not be working together on the project on a regular basis, but they’ll be actively part of it.

Each project needs to identify “RACI” individuals as it starts: those who are Responsible, Accountable, Consulted, and Informed during the course of the project. The Responsible individuals need to be on the project team, for they’re responsible for carrying it out. The Accountable individuals can be on the team, but not always. Of course, sometimes the Responsible and Accountable individual is the same person, which is fine. Most stakeholders are either consulted or informed, but aren’t on the project team.

For teams to be both responsible and accountable for delivering on a project, they must be empowered to make decisions. To be able to make decisions quickly and keep projects moving, we must embrace our core cultural values—in particular, “We give autonomy. Know your responsibilities, and take ownership,” and “Disagree and commit.” Within the team, we need consensus. From our external stakeholders, we need commitment.