Design groups at Redgate — How has it been so far?

Neil Turner
Mar 25 · 8 min read
Image for post
Image for post
Callum and Elena from the SQL Monitor design group in full workshop mode

As the lead product designer within the SQL Monitor design group (the other design group being DB DevOps) I’d like to share how things have been going so far. I’ll cover some of the benefits of this new approach, the challenges we’ve encountered and outline what’s next for the group. Before I do that, let’s look at why the design groups were formed at Redgate in the first place.

Why introduce design groups?

Image for post
Image for post
The Mighty Morphin Power Rangers — a classic example of synergy in action!

Redgate has for a long time had product designers embedded within product teams. This embedded or de-centralised approach has lots of benefits, but also a few downsides. Whilst it means that designers will invariably work very closely with development teams, they tend to work much less frequently with other designers. Believe me, life as the only designer in a product team can be a lonely one.

Embedded designers can not only be isolated, they have to singlehandedly juggle all the demands of a team, and less experienced designers can struggle to receive the support they need to learn and grow. With embedded designers working semi-independently user experiences can become fragmented and user research is driven by the needs of a single team, rather than the wider organisation. There are also inefficiencies as efforts are inevitably duplicated. For example, rather than utilising existing design patterns, components and user journeys, new ones are often created.

As we increasingly move to designing for enterprise customers, to designing solutions, rather than individual tools, it’s clear that having embedded designers isn’t right for every team. By introducing small design groups (see diagram below) that can work across multiple development teams we want to unleash the synergy that comes from collaboration and teamwork, whilst continuing to work extremely closely with development teams.

Image for post
Image for post
The Design group model at Redgate

As Matt Godfrey, head of design at Redgate outlined in his Designing for the Enterprise post last year:

“In the groups model, we’re attempting to break the silos and are experimenting with abstracting designers to create a team that operates across the entire solution. Their focus is strongly around collaboration and collectively supporting the teams that comprise the solution; identifying where they can have the greatest impact and designing a more holistic customer experience.”

How has it been so far?

As a design group we had our first retrospective a few weeks ago. We discussed what we felt went well, what we would like to change and ideas for things to try out. The good news is that the team were over whelming positive. When everyone was asked to rate their level of satisfaction from 1 to 5, with 5 being the best team in the world, and 1 being unhappy and dissatisfied, it was a case of 4 out of 5 all round (well, there’s always room for improvement).

What’s working well?

All of our products will require research and design work for the now, along with work to help shape the future of that product. It’s already clear that a group is better placed to do that. Unlike a single designer having to continually juggle the two, a group can have parallel streams of work. The here and now can be worked on, at the same time as the future.

Lastly, and perhaps most importantly it’s clear that a design group provides a better framework for day-to-day collaboration and interaction, such as working on a design as a pair, or reviewing a design as a group. It’s no surprise that better collaboration typically leads to better designs. Indeed, when InVision looked at what were the ingredients are for a successful design team, unsurprisingly working day-to-day with other designers was high on the list. As they put it:

“What we almost never saw in this cohort of successful companies? A single designer on a team outnumbered by engineers.”

What has been challenging?

No longer being truly embedded within development teams has inevitably led to some small bottlenecks and an increased need to co-ordinate. We don’t want development teams being blocked because designs haven’t been created, but then teams don’t always need a design to progress their work. We’re working to better upskill developers across the SQL Monitor teams so that they’re able to take on more of the low-level UI design work (with designers playing a support role). We’ll also shortly be experimenting with a dual track approach (more about this later) so that we can better focus our efforts on the more critical design and research work.

Finally, it’s been a real challenge to support multiple development teams at the same time. To help address this we’ve set-up a weekly planning meeting, a Github project board to share the design group’s backlog and work in progress, and have scheduled our own stand-up to be after the teams so that we can discuss the priorities for the day once we know what the teams will be working on.

What’s next?

Research sprint

Dual-track approach

Image for post
Image for post
The dual-track approach by Jeff Patton

This allows ideas to be rapidly researched and concepted prior to a team taking them into a sprint. It helps to avoid the design bottleneck problem, whereby development teams are blocked through a lack of designs, and helps to ensure that we’re not only building things right, but that we’re building the right thing in the first place.

When an idea is picked up (such as from the product roadmap) we’ll look at how critical design is for that idea to be a success (i.e. how much design effort is required) and how much we know about it (i.e. how much research effort is required). For example, a new configuration feature is unlikely to require a lot of design work, whereas a key user journey will.

Image for post
Image for post
Ideas will be assessed to determine the level of design and research effort required

The criticality of design to the success of an idea, together with how much is known will drive the approach taken (see above), and ultimately the amount of design and research effort we think we need to throw at it.

We’re planning to review ideas on a quarterly to monthly basis to help determine the approach to take. A dual-track approach will be another first for Redgate. I’ll be sure to keep you posted as to how we get on. If you want to find out more about taking a dual-track approach I recommend reading Jeff Patton’s Dual Track Development is not Dual Track blog post.

Image credits

Dual-track development by Jeff Patton

Ingeniously Simple

How Redgate build ingeniously simple products, from…

Neil Turner

Written by

Former techy turned UX Jedi. Checkout out my blog (UX for the Masses) for more about me.

Ingeniously Simple

How Redgate build ingeniously simple products, from inception to delivery.

Neil Turner

Written by

Former techy turned UX Jedi. Checkout out my blog (UX for the Masses) for more about me.

Ingeniously Simple

How Redgate build ingeniously simple products, from inception to delivery.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store