Service design: higher quality work

Summary:

Newly promoted to design manager and responsible for how our team of 6 UX designers runs our work, I needed to find ways to make our historically frustrated internal stakeholders happier, help designers reach their best potential, and prove that our team can kick out high quality work on time using best practices.

My role

I manage 6 UX designers on the Buyer Experience team. Our team’s product is our customers’ experience from landing at atlassian.com, helping customers recognize matches between their problems and needs, through setting up a trial, making a purchase, and then managing their billing and account details.

The current state of the experience needs a lot of love, but this is the exciting opportunity for the team — there’s a mountain of small and obvious things that can be done to make a positive impact on the experience!

Our team owns the buyer journey

 

Organizational context

Our team operates in some ways like an agency within Atlassian’s marketing and design organizations—we have about a dozen product marketing teams distinct from us who set each of Atlassian’s products’ (Confluence, Bitbucket, Jira, and so on) overall marketing strategy. While we execute on our own initiatives related to the purchasing funnel (agnostic to single products), we also execute projects to support individual product marketing teams’ goals.

Around the time I started my new role, a new Head of Buyer Experience was hired who transformed our backlog and prioritization process, resolving a lot of organizational pain.

Formerly, the team operated with a messy and painful work process that didn’t allow the team to make much visible impact on our disjointed product experience and tended to created constant tension and unhappiness with our stakeholders on the product marketing teams. Under our new leadership, though, we unified the 12+ teams’ backlogs so our team could focus on doing the most impactful projects to build a better holistic experience and hopefully repair relationships with our stakeholder partners.

Before our Head of Buyer Experience started, we had multiple backlogs that contained our work.

We operated in a constant firedrill mentality, which made it difficult to get work done effectively.

Our Head of Buyer of Experience moved the organization to a unified and prioritized backlog.

This allowed our design team to better manage stakeholder expectations and consider a holistic experience approach.

I inherited an existing designer on the team, a designer from a team we merged with, and hired 4 new designers. Now I had a team of 6 designers worth bragging about—all 6 are high-performing and represent a diversity of backgrounds, personalities, and strengths—and we had an exciting stack of experience problems to solve.


Problems to be solved

Despite a fresh team and backlog process, we had lingering organizational pain:

  1. Our internal stakeholders, especially product marketing teams, didn’t have a lot of faith in delivery from our team
    Based on their prior experience with our team and designers on our sibling marketing design team, they were used to inconsistent quality and and many missed deadlines with no clear explanation.

  2. Our design process was pretty wild west.
    Designers weren’t sure what to expect when it came to engaging with internal stakeholders on projects for other teams, and they weren’t totally clear what was expected from them. This led to inconsistency in the completeness and quality of the design work.

As manager of our design team, it was my responsibility to help us resolve these problems. I approached this much like I’d approach a design problem.

 Early whiteboard brainstorming around our design team’s hopes and values

Early whiteboard brainstorming around our design team’s hopes and values

 

Listening Tour and insights

I started with a listening tour, taking notes on pain points I discovered.

Venues for discovery

  • Asking questions in our leadership meetings

  • 1:1 meetings with product marketing team members, leads and devs on our team, designers on my team, and designers on our sibling design team

  • Soliciting anonymous feedback in my performance review (even though I was newly in this role) from leads of other teams I knew were unhappy with their engagement with our team

  • Sprint retro meetings

  • Reviewing designers’ project documents on Confluence

Paint points identified:

  1. Deadlines missed

    • Designers weren’t always clear what the deadlines were.
      Sometimes they didn’t think to ask, sometimes they got different answers depending on which project stakeholder or lead they asked.

    • Designers were assigned other projects when they were already working on something and there wasn’t always a clear put-and-take conversation with the right people. While we had a unified backlog for projects, it was based on dev estimates; the new system hadn’t yet figured out how to accommodate for the related design projects.

  2. Stakeholders and team weren’t often aligned on the goal

    • A project goal may have been stated in the kickoff that the designer interpreted and wrote down, but then it changed, usually requiring rework. Sometimes no one remembered if it actually changed or if they just misinterpreted each other from the kickoff.

    • Conversations about the meaning of success shifted depending on the conversation or review, so designers felt like they were designing in circles without any clear sense of why they were making one trade-off over another. “Do I emphasize this thing or this thing? What do I cut when things get to crowded? How do we know what to focus on in the mobile version where we need to be even more precious with real estate? When we prioritize all of the things, we prioritize none of the things.”

    • Stakeholders often arrived to a kickoff with a specific solution in mind, not the problem to be solved or what defined success. This resulted in designers feeling like they had to dance around how to say no to the solution if it didn’t feel like the right one for the (unstated) goal. They sometimes executed on what they felt was the wrong solution, and yet didn’t have a clear or aligned idea of the goal of the project either.

  3. Designers often weren’t checking in with devs early enough

    • Turns out most of the time they tried, but they didn’t know who the dev on their project was until or after hand-off.

    • Sometimes if they asked the right person, they could find out.

    • Sometimes they asked but were told a dev wasn’t assigned yet. When I asked our dev manager about this, he was incensed — “We always know who the dev is on a project, if you ever don’t know, just ask me!”

  4. Designers designed something way out of scope and then had to back track and redesign something smaller (see also missed deadlines)

    • Sometimes they were never told any scope or dev time boundaries, so they just designed what they felt was the best possible solution.

      • More experienced designers knew better and asked about scope up-front, but even then didn’t always get a clear answer.

      • Less experienced designers didn’t know any better and proceeded with optimism, assuming anything they made would be built, then were frustrated to learn at hand-off that they had to make compromises.

    • The team wasn’t always aligned on what defined scope — was there a hard deadline like an event or release? Did we have the flexibility to discuss the trade-offs of expanding scope for more time?

  5. The design output quality, completeness, and good practice was inconsistent between designers and projects

    • Sometimes they included mobile, sometime they forgot or procrastinated until the last moment.

    • Sometimes they did a competitive assessment, sometimes they didn’t.

    • Some designs got handed off before they’d been reviewed by any other designers or teams (like brand, or teams that had an overlapping experience) who needed to weigh in. They’d be partially through development before someone found out about about the project and revisions had to be made.

    • Designers didn’t consistently think about localization or accessibility.

    • Sometimes they included error states, sometimes they had to be reminded by a dev, which could result in some rework and delays.

    • Sometimes they iterated, sometimes they went with their first or second idea.

  6. It was hard to link all the related content and analysis in one place

    • Pre-analysis, background, content writing in progress, and related pages all existed on our Confluence wiki somewhere, but it could be hard to find them

  7. Project leads and stakeholders didn’t understand why many projects took so long

    • Sometimes they weren’t familiar with the steps involved in a good practice design process.

    • Sometimes they didn’t realize designers were working on other projects at the same time or had other projects to finish before they could start.

  8. Designers often didn’t know what they would be working on a given quarter

    • Despite the fact that our backlog was now planned out per quarter, our design projects weren’t roadmapped by our product owners. This made it difficult to have productive put-and-take conversations.
      e.g. “I know we want Anthony to start now on project X, but we committed to finishing Y first. Should we try to get a different designer on it, prioritize one project over the other, or start X while Y is finishing, letting Y extend a bit longer?”

    • Designers were anxious about not knowing what was in their future. They felt like they finished projects and then didn’t know what they’d be working on until the first day of the next project.

    • Not having any roadmap or overview of work in progress also made it a challenge to know when their work was overlapping with another designer’s work who they should consult.

Solution Design 1: Design Project documentation template

Gathering information

I noticed that that the more thoroughly a designer documented their design progress and team decisions on Confluence, the more smoothly their project seemed to go.

I started with an review of the types of things more successful designers were capturing, and I asked designers in our team chat room and 1:1’s which items they were documenting that proved most useful and which were not so useful.

First iteration

From there I created a first version of the template. I reviewed it with my team and bounced it off leads.

After incorporating my collected feedback, I rolled out a pilot version meant to fulfill three purposes:

  1. Project information intake criteria.
    Act as a forcing-function for conversation at the kickoff meetings to help designers get all the info and team alignment they needed to start successfully. When they weren’t able to get answers they needed on their own, I could help unblock them by pointing other leads to their page to get answers they needed.

  2. Project hand-off criteria.
    Encourage good design process and practice. Prompts reminding designers to iterate early, remember mobile from the start, get other teams to review their work, etc.

  3. Create some consistency in our process so that designers and stakeholders could better know what a process that leads to quality looks like.

Pain points addressed:

  1. Deadlines missed
    A clear deadline was agreed upon and documented. The scope section could also drive a discussion with the team around if deadlines were immovable or if trade-offs of extending the timeline were up for discussion (see sections 8 and 19, annotated).

  2. Stakeholders and team weren’t often aligned on the goal
    Stakeholders and designers could use sections 1-6 to frame a discussion around and agree upon goals. These could be documented together to ensure alignment. When stakeholders arrived to a kickoff with a solution in mind, that could still be taken into account as a potential idea to address goals, but the kickoff discussion would focus on the goals.

  3. Designers often weren’t checking in with devs early enough
    If designers weren’t told who their dev was, section 13 was a trigger to ask. If they were told a dev hadn’t been assigned, I could message my our dev manager, send him this page, and ask how to fill in that field.

  4. Designers designed something way out of scope and then had to back track and redesign something smaller
    Sections 8, 19, and 24 were meant to trigger a discussion about project scope boundaries — allocated dev time, due dates, and anything else that could help contain an MVP. Section 33 helped designers make sure they gathered all the answers they needed in the kickoff (note WPL refers to the Web Pattern Library).

  5. The design output quality, completeness, and good practice was inconsistent between designers and projects
    Designers now had a structured outline (sections 25-34) for the expected process and checklists to self-audit and make sure they weren’t forgetting important steps (note “sparring” in section 34 is Atlassian’s word for design review).

  6. It was hard to link all the related content and analysis in one place
    Sections 7 and 21-23 helped the team gather relevant links to useful content.

  7. Project leads and stakeholders didn’t understand why many projects took so long
    As projects progressed, this page was a visible build of the designer’s progress over time so they could see how much work and thinking was being done (especially through the iteration sections and links to usability testing). It was also a space for stakeholders to leave notes related to works in progress and designers to collect feedback informally outside of meetings.

Notes:

  • I was worried about the risk of adding unnecessary documentation overhead, so I tried to remove anything without a clear purpose.

  • I also wanted the template to be scalable for different sized efforts, so I made an effort to be explicitly flexible in the prompts about the fidelity of elements of process like competitive assessments, user flows, etc. depending on the project size and needs.

  • Existing documentation pages were a bit overwhelming, so I tried to encourage collapsing older iterations and explorations and highlight key alignment information at the time.

Rolling out pilot and socializing

I rolled this template out to only my team for a a pilot quarter (ending this October). We’ll iterate based on our learnings and then socialize and roll out to our sibling team of designers to use or adjust to their purposes.

In the pilot I’ve been watching to see if designers felt slowed down by an obligation to document, which sections they used, and which they tended to skip (and why), and if there’s anything designers are adding to their documentation that could be useful on the template. I’m also watching to see if the template is actually solving the pain points listed above as intended or if we need to try other approaches.

Example snippets from the template in use:

Solution 2: Trello board of the BXP Design Team’s work

For paint points 7 (Project leads and stakeholders didn’t understand why many projects took so long. ) and 8 (Designers often didn’t know what they would be working on a given quarter), I created a basic Trello board where I track all the work from the backlog and other places that I know will be hitting our team.

With this board, designers can get a rough idea of what they will likely work on next and what their colleagues are working on.

It’s additionally helpful for stakeholders and product owners for transparency into where our team’s effort is spent. When there is overlapping work requested, visualizing what the team is working on helps us see our capacity and have a productive conversation about timeline trade-offs and priorities of projects. This way we don’t have designers working all weekend or delivering late because we’ve overloaded their capacity.

Afterword

After just 3 months, our team is already looking more buttoned-up in our process and I’m really proud of everyone’s thinking and output quality overall.

Also, small joy, but I was especially excited to see paper sketches included in iterations—it’s something I’ve been encouraging because it leads to more iterations and quicker broader explorations. Now that other designers see these designers are doing it, I hope it will encourage them too!

 

I’m noticing fewer painful misalignments between designers and stakeholders — like, almost none! Even better, I’ve been overhearing discussions between my team’s designers and other designers who are still having these problems. The designer from my team will show them our template and then coach them on how to set up a problem statement, goals, and hypothesis. :) :) :) :) :)

Finally, I no longer need to prompt designers to make sure they’re checking in with a copywriter, reviewing with the brand team, including mobile, and so on. Before the template, I had at least 3 basic notes like this for every designer every week, but this quarter, when I ask, they’re almost always already on it!

Things I want to keep working on:

  • I could better quantify and get a more unbiased read on the success by sending out a survey to help us measure stakeholder perception and satisfaction. I wish I would have sent one out before rolling out the template to get a baseline, but at least we can track our progress over the next quarter.

  • We need to work on writing better hypotheses. Some of them get way too complicated, some of them are too flimsy, some could be more specific. I’ve asked if my manager, Head of Design for our go-to-market experiences, will review our hypotheses with us and offer some coaching.

  • Stakeholders and leads still have the perception that our team is slow. I was hoping that this template would help leads understand better what goes into a design task and help designers get a better sense of driving to a deadline with urgency, but it sounds like we’ll need to untangle that problem via other approaches.



← Back to portfolio home