DesignOps - Small team starter guide

• Intro
• What we mean by ‘DesignOps'
• Clarify your organisational model
• Define a process that’s fit for purpose
• Standardise your tooling
• Build your sources of truth
• Nurture transparency
• Conclusion

If you ever find yourself saying “Oh sh*t, now our team’s so big we’d better start thinking about DesignOps…” you’re likely going to find yourself at the start of an uphill struggle to retroactively define and embed standards and processes that could and should have been defined some time ago.

So, what’s a ‘small team’? We’d suggest anything from 2-8 Product Designers is a small team, because between these ranges, it’s still possible to ‘wing it’ in regards to DesignOps. Small teams often don’t have the luxury of dedicated DesignOps roles, and therefore DesignOps must be integrated into existing roles in the team. Just because you don’t have the budget for a dedicated DesignOps function though, it doesn’t mean DesignOps isn’t for you. If you're a Design Leader who’s yet to define DesignOps standards for your team, now’s the time to start, and this article is a jumping off point for beginning that journey, based on our experiences of working with small(ish) design teams.

As a Design Leader you've no doubt heard of DesignOps (which is why you’re here reading this), and even if you're unsure of exactly what ‘DesignOps’ is, in all likelihood you’re already doing it in some capacity. In fact, I’m going to put it out there that as a Design Leader of a small team, you owe it to the people you’re leading to define and implement effective DesignOps, to supercharge that team and enable those designers to do their best work.

So what is DesignOps exactly? There are dozens of great definitions of DesignOps out there, but here’s our take on it.

That’s a fancy way of saying that it’s a set of clearly defined ways of working that reduce friction and enable your team to focus on ‘doing design’, with clarity on how to ‘do design’. This safeguards designers from being pulled in a dozen different directions each day, trying to solve problems that should already have defined solutions.

We all wear a lot of different hats in our day-to-day life as a designer, and while that isn’t likely to change any time soon, without effective standards and processes around us, we can end up wearing too many hats, leaving us without enough space to focus on the big things - like delivering great design work. DesignOps is a way to minimise the number of hats our team members need to put on each day.

This article explores five key areas that we recommend small teams focus on in order to build solid foundations and start seeing the benefits of DesignOps:

1. Clarify your organisational model
2. Define a design process that’s fit for purpose
3. Standardise your tooling
4. Build your sources of truth
5. Nurture transparency

Disclaimer – As with most ways of working, there’s rarely a one-size-fits-all approach. We don’t have all the answers, no one does. This is a collection of guidance and best practices based on our direct experience in this space.

At a high level, an organisational model is a structure for how your design team collaborates with other disciplines, and how reporting is managed. The best organisational model for you will depend on factors such as the size of your team, the capabilities within your team, and how product focused your organisation aspires to be.

There’s no one-size fits all organisational model that’s perfect for every team, but NN/g has created a really comprehensive guide to different organisational models for design teams, which outlines the pros and cons of the three most common models.

Centralised

This is the traditional ‘Studio’ style approach to organising a design team, with designers reporting into a Design Leader. Designers are dropped into different Product teams as and when design is needed.

• Key Benefits: The benefits for this model are that transparency is high amongst team members, and that designer’s get to work on the widest variety of work.
• Key Challenges: The challenges of this model is that Design ends up being separate from Product making it difficult to integrate a UX mindset into Product Teams, and preventing designers from getting fully immersed into specific Products, thus limiting the opportunity to gain deeper understanding of the Product’s vision.

Decentralised

This approach embeds designers long term into Product Teams, establishing Design as a capability within Product. In this model, Designers report directly into the Product Team.

• Key Benefits: Being embedded long-term in Product Teams enables Designers to build a deeper knowledge and understanding of the specific product, vision, and strategy.
• Key Challenges: This approach naturally reduces the opportunities for Designers to collaborate with their peers, resulting in silos as each Designer focuses their time on their respective Product Team. Without centralised Design Leadership, this approach is the most challenging for establishing effective DesignOps.

Hybrid

The clue’s in the name, this is essentially a mix of decentralised and centralised models, with designers embedded longterm into squads, reporting into the Squad day-to-day, and a Design Leader as their primary line manager.

• Key Benefits: All the benefits of the Decentralised model, albeit with greater opportunities for a Design Leader to ensure healthy transparency and shared ways of working across Product Teams (DesignOps), while Product Leaders focus on the day-to-day Product focused design work. You can also consider integrating specific centralised design capabilities for disciplines such as Service Design, which can be deployed tactically across Product Teams.
• Key Challenges: Clear delineation of accountability between Design Leaders and Product Leaders are necessary to prevent confusion and potential conflicts of interest.

💡 Pro tip

When choosing the right operational mode for your team, consider the different capabilities within the team, and how each of those capabilities can most effectively collaborate with product teams. In our experience the Hybrid model offers the greatest opportunity to establish design as a capability within Product teams, while enabling Design Leaders to shape and lead DesignOps. For smaller design teams operating in organisations with a large number of product teams, you may be limited to a centralised model until your design team grows large enough to adopt a Decentralised or Hybrid model.

What does your end-to-end design process look like? Do you have a clearly documented process that the whole team can see, or does it live in your head in some abstract form that only you can explain? A well defined end-to-end design process helps your team understand what stage their work is at, where it should have been before reaching that stage, and the direction it should be heading in. If everybody in your organisation isn’t clear on the stages of the design process, it can create friction with stakeholders and collaborators who don’t know how or when they can or should support design activities, or expect to see the outputs of design work.

A common challenge we see when supporting smaller teams is that they either don’t have a clearly defined design process, or they’ve created their own, which usually ends up being a clunky, linear, waterfall Franken-process. For small Product teams, our advice is simple; you don’t need to reinvent the wheel. There are plenty of proven methodologies out there already such as Design Thinking, User Centred Design, and Lean UX, so find the one that’s the right fit for your needs and take it for a spin.

💡 Pro tip

The right process is the one that’s best suited to the way your team prefers to work and the problems they’re trying to solve. At Futurice we recommend Design Thinking, which in a nutshell is a simple, non-linear, user-centred approach to solving ill defined problems. The non-linear nature of design thinking enables teams to work through the stages sequentially, or repeat them and circle back to previous stages to iterate based on new learnings. It's a solid approach to ensure that your team has identified the right problems to solve, and thoroughly validated the most effective solutions to those problems. You’ll most commonly find Design Thinking presented as a 5-6 step sequence, or as a double diamond, with each essentially being different ways to visualise the same methodology.

This seems like a pretty straightforward thing to define, but there’s more to standardising your tooling than simply ensuring that the whole team is using the same tools. You should of course begin by aligning on a core toolset that your whole team will use consistently across workflows, the value of which is ensuring compatibility of design assets, and reducing complexity and business costs.

However, as your small team starts to grow, the bigger consideration here is, how those team members are using their tools. This is all about reducing complexity to increase day-to-day efficiency; Your goal should be ensuring that anyone, designer or otherwise, can jump into a design file and find their way around with minimum initial support, or without a facilitator. For the majority of client engagements, our core design toolset is Figma and Miro, so here are some best practices to consider for standardising these tools:

Figma

• Consistent structure for pages, including a cover page, usage guide, UX flows, a sandbox page, and local components
• Clear examples of consistent naming conventions for files, pages, frames / artboards, components
• An example of how to lay out and structure UX flows within pages, e.g. a consistent way to group specific sets of frames

Miro

• Make boards clear, clean and self-explanatory, so that anyone visiting them can make sense of the information and activities shown without needing support (or with minimum support for more complex activities)
• Plan how to organise a Miro board, and artboards within it according to what you are trying to achieve
• A well-structured board should be easy to access, navigate and understand with minimum initial support, or without a facilitator
• Clearly separate artboards/sections and keep each focused on one core activity
• Organise boards into projects (Miro Projects)

💡Pro tip

Whatever your day-to-day Product Design tools are, to ensure the greatest level of consistency and efficiency in your team’s work, you must agree upon and document some standards that everyone can align to. To do this, we recommend bringing your team together to discuss and capture how they prefer to use their design tools, before documenting these standards in your team’s wiki tool.

Adjacent to your standardised tooling, standardisation and centralisation of your shared design assets and documentation is one of the most impactful ways to free your team up to focus on ‘doing design’.

Centralising your design assets

The majority of design teams we work with these days are either in the process of developing a Design System or planning to get one off the group ASAP. Establishing a single source of truth for the design elements shared by your team and the products they support, is essential for reducing complexity and inefficiency across design activities, and for freeing up designers to focus on ‘doing design’. An effective design library is a cross-functional resource, co-created by designers and engineers to ensure that both practices are benefiting from it in the fullest sense.

Building a Design Library is a big task, but luckily for you, Futurice recently published an extensive guide to our approach to helping teams plan and build their first Design Library, which you can read here.

Documenting your ways of working

Having well defined ways of working is great, but these standards need a place to live, where everybody in your team can easily find them. At Futurice, we’ve found that a team wiki is the most effective way to document design ways of working. A well structured team wiki can be a beneficial resource for long serving team members to check standards and practices, as well as for helping to onboard new starters. Things to include in your wiki:

• Design Principles
• Team member profiles
• Design organisational model guidance
• Design process diagrams and guidance
• Design system onboarding
• Tooling and guidance
• Definition of Done for design

Tracking DesignOps

Building and scaling effective DesignOps standards, much like building effective digital products, is an ongoing, iterative process, and therefore teams need a way to track their DesignOps workflow and initiatives. Creating a dedicated DesignOps backlog and tracking it through a kanban board, can really help yourself and your team to track and prioritise your DesignOps initiatives. Things to consider when setting up DesignOps backlog include:

• Defining a review process for initiatives, e.g. such as when and how to request peer reviews.
• Standardising the way you write tasks/stories, e.g. including acceptance criteria on tasks/stories to help ascertain when a task is ‘done’.
• Creating Epics or tags to categorise different DesignOps initiatives, e.g. Recruitment, Ways of Working, Design System.

You can treat your DesignOps backlog the same as any other product backlog, writing clear, detailed tasks or stories, and regulatory coming together as a team to review the priority and progress of these initiatives.

💡 Pro tip

Try to think of your team wiki as a hub, or a ‘go-to’ place for your design team to seek answers about their design standards and ways of working, ensuring that your wiki guidance links out to your other tools, such as your design system and DesignOps backlog. This approach ensures that every team member knows where to go first if they’re not sure how to do something, or where to find something.

Transparency and openness are some of the best markers of decent design culture, and a key purpose of DesignOps is embedding these values in your team’s ways of working.

A lot of the time Designers simply aren’t sure when to seek feedback from the wider Design Team, especially when they’re getting a lot of feedback from their individual Product Team peers. As such it’s the responsibility of Design Leaders to create appropriate opportunities for the team to raise transparency.

Being embedded longterm in a single Product team is the best way to properly integrate UX with Agile delivery teams, and ensure that Designers gain the deepest understanding of the product they’re accountable for. However, with this setup there’s less opportunity for designers to keep up to speed with what their peers are doing, and contribute to broader design culture within the organisation. Here are some simple and effective practices to consider for improving transparency and embedding a feedback culture in your team:

Asynchronous YTBs

A really simple way to raise visibility across the team, especially when following a hybrid model, is to ask everyone to share their YTBs (Yesterday, Today, Blockers) each day on your asynchronous comms tool. If you’re unfamiliar with YTBs, they usually look a little something like this:

Y - What I worked on yesterday… T - What I’ll work on today… B - Anything that’s blocking my progress and I need help with…

Ask each team member to share their YTB each morning in a Design Team channel, (or if you’re using Slack, set up an automated daily reminder) ensuring that they’re reading their team mate’s YTBs, and looking out for any blockers they might be able to help with. This also gives team members an opportunity to see if their team mates are working on anything that may impact their own work.

Team sharing sessions

A great way to finish the working week is to bring the team together to share updates on the interesting work they’ve done that week. This gives the design team another opportunity to inspect each other’s work, ask questions and seek peer feedback. A simple format for these sessions is to give each team member 5-10 mins to do a weekly focused YTB, e.g. what they worked on this week, what they’ll be focusing on next week, and any support needs they might have.

DesignOps backlog refinement

Much like your product backlog, your DesignOps backlog needs regular refinement to prevent it from getting too shabby. Regularly bringing the whole Design team together to inspect and adapt your DesignOps backlog is another great way to embed transparency and get designers discussing, defining and prioritising initiatives. Discussion is the key to getting the most out of these sessions, you should aim to encourage healthy debate on the initiatives that are being defined by the team, to ensure that you’re capturing a broad array of viewpoints to inform your team’s standards.

Every couple of weeks is often a good cadence for these backlog grooming sessions, but as always, find a cadence that works for your team and approach to DesignOps.

💡 Pro tip

This is an area that’s often a challenge for Decentralised Product Design Teams, but it’s a problem that can rear its head in any organisational model. Creating formalised, recurring sessions for the team to come together and share their work and ideas is a great starting point but for a feedback culture to really take root, Design Leaders need to help their team get accustomed to self-initiated transparency. Encouraging designers to invite their colleagues to impromptu review and sparring sessions, and building communities of practice for different design topics can greatly improve knowledge sharing and transparency across the team.

DesignOps is a big, expansive topic, with a great deal more considerations than we can cover in this starter guide, but the five areas we have covered here are the ones that we most often see absent in small design teams, and which subsequently have the largest impact on the ability of those teams effectively and efficiently manage their day-to-day design duties. Regardless of where you are in your journey as a design team, it’s never too late to start establishing standards to safeguard your growing design practice.

Recommended reading

• Pattern Library Playbook: Get set up for success - Futurice
• DesignOps 101 - NN/g
• Where Should UX Report? - NN/g