A taste of Down Tools week 2021

Neil Turner
Sep 6 · 9 min read

Down Tools week is a long-standing tradition at Redgate. Every year Redgaters get the chance to down their digital tools (hence the name), join a new team and spend a week working on something a little different. It’s an opportunity to meet some new Redgaters, to learn some new skills and to have a go at tackling an interesting challenge, all in just 5 days.

This year I was captain of Team Fish (more about the name later). We set ourselves the challenge of exploring how to make it easier for users to get started with Redgate products. Read on to find out how we approached this challenge, some key lessons for those undertaking a similar 5-day exercise, and why on earth we called ourselves team Fish.

Teaching our users to fish

Give someone a fish and you feed them for a day; teach them to fish and you feed them for a lifetime.

Although we aim for ingeniously simple tools at Redgate, there is no getting away from the fact our tools can be quite complex. After all, they are used for inherently complex tasks, such as diagnosing database issues and classifying sensitive data. Onboarding new users is therefore a perennial challenge, one that we have traditionally tackled by giving our users fish. Not real fish (obviously), but learning resources in the form of training videos, webinars, articles and documentation to help them get started. We wanted to see if instead of giving them fish, we could teach our users to fish (hence the team name, although maybe team fishing would have been a better choice). We wanted to see if we could help users to learn our products by providing them with interactive product tutorials. We defined our problem statement as:

We have observed that it can be difficult for users to start using Redgate products. This is important because users won’t get value out of our products if they don’t know how to use them.

How might we enable first-time users to learn our products in less time than present?

Our approach

As the saying goes, Rome wasn’t built in a day, or even a week (although as Brian Clough famously quipped — “They say Rome wasn’t built in a day, but I wasn’t on that particular job”). Fortunately, we were not looking to build Rome, or even a working interactive product tutorial in a week, we were looking to find out if this was an idea that could work and therefore decided to take a design sprint approach.

We decided to spend the start of the week understanding the problem and generating ideas, the middle of the week building prototypes to test these ideas and then the end of the week getting feedback from Redgate customers. Our week therefore looked something like this:

We took a design sprint inspired approach

It’s also worth noting that whilst Down Tools week is usually carried out at Redgate HQ (in Cambridge, UK), with Covid restrictions still in place this was to be a remote Down Tools Week.

Members of Team Fish on one of many Zoom calls

Day 0 — Kick-off

As anyone who has carried out a design sprint will tell you, 5 days is really not a lot of time. We didn’t want to waste the first few valuable days deciding how to work as a team, what to focus on and agreeing a plan of attack. Therefore, the week before Down Tools Week we got together to do just that. We had a kick-off to agree the scope of the week, to formulate our approach and to discuss what everyone wanted to get out of the week.

We captured hopes, fears and working preferences as part of the pre-week kick off

We also wanted to choose a Redgate product to focus on. Whilst we felt that an interactive product tutorial could be utilised across our products, we needed a suitable candidate for testing the concept on. In the end we chose SQL Data Catalog, Redgate’s tool for identifying and classifying sensitive data (shown below). This is because it has a web UI (this was important as most tools for building tutorials are designed for web, rather than desktop applications) and is complex enough to make onboarding users a sufficient challenge.

SQL Data Catalog was chosen for the interactive product tutorial proof of concept

Day 1 — Understanding the problem

Before diving into writing code or creating prototypes we wanted to understand what we already knew about the problem, and look at how others have gone about tackling it. Having already collated some insights prior to the week we got together to create a user journey map of the current getting started experience for SQL Data Catalog (shown below)

A user journey map was used to capture steps, pain points and opportunities to improve the getting started experience

User journey maps (sometimes called experience maps) are a great way to capture the steps, pain points and opportunities that exist within a particular user journey. We took a pre-existing persona outlining a typical SQL Data Catalog user and mapped out their current getting started experience.

After the user journey mapping exercise the team split up to look for inspiration. We wanted to see how other products tackle onboarding new users, and not just other technical products but a wide range of digital products, from mobile apps to video games.

We populated an inspiration board with examples of different onboarding strategies

Day 2 — Generating ideas

Whilst the first day was focused on what happens now, day 2 was focused on what could happen in the future. We started by mapping what the getting started experience could look like for users if interactive product tutorials were available.

We mapped the to-be user journey to capture what the getting started experience could look like

With a to-be user journey in place some of the engineers in the team could start looking at commercial and Open-source frameworks that could be utilised for building product tutorials. We narrowed the chose to three possible candidates:

1. Intro.js — A lightweight library for creating step by step customer onboarding tutorials.

2. Pendo product walkthroughs — A commercial tool for building interactive product walkthroughs.

3. Intercom product tours — A commercial tool for building interactive product tours.

In the end we chose Intro.js. This is because it’s lightweight (certainly when compared to Pendo or Intercom) and is already used in some of our other products.

Day 3 — Prototyping

We had two key deadlines for the week. Firstly, we had scheduled some 30 minute sessions with Redgate customers on the afternoon of day 4. That was deadline number one. Secondly, we had a show and tell at the end of the week for which we wanted a working demo. That was deadline number two. Therefore we had a day and a half to prototype something to test the concept with customers and 2 days to create a basic proof of concept for the demo. Better get cracking.

We decided to use Figma to create a high-fidelity prototype for testing the concept with customers. This is because Figma allows for real-time collaboration, is cross platform (we had a mixture of Windows and Mac users in the team) and because a library of UI components for Honeycomb, Redgate’s design system was readily available.

Figma was used to create a high-fidelity prototype for testing the concept with customers

Whilst half the team made a start on the high-fidelity prototype using Figma, the other half of the team started coding a proof-of-concept tutorial using a SQL Data Catalog development environment and Intro.js.

The proof-of-concept tutorial, built using Intro.js

Day 4 — Testing with users

As they say, the proof of the pudding is in the eating. It doesn’t matter if the team thinks that interactive product tutorials are a brilliant idea if users are going to get little value out of them. We therefore wanted to test the concept with Redgate customers and whilst doing so also better understand their general strategies for learning new products.

We had already lined up four Redgate customers to speak to (utilising the awesome Calendly to allow customers to self-select their session time), along with a Redgater who was not familiar with SQL Data Catalog. Having planned the research sessions as a team we took it in turns to run them (using Zoom), with the rest of the team capturing insights on a MURAL board. This was a great way to share the workload and to ensure that the whole team could learn from our customers.

We ran 4 sessions with Redgate customers to test the interactive product tutorials concept
The whole team captured insights during the research sessions

The sessions revealed some key design considerations that we’d need to factor in, such as making it clearer that some steps required interacting with the page (rather than hitting ‘Next’). Most importantly the feedback suggested that the concept was a good one and that users are likely to find interactive product tutorials useful.

Day 5 — Show time

At the end of Down Tools week teams have to put together a short presentation showcasing their work. With such an action-packed week it was a real challenge to cover everything we wanted to in the 8 mins we had available.

We agreed the key sections for the presentation and having chosen one of the many excellent PowerPoint templates from SlidesCarnival took a divide a conquer approach to creating the slide deck.

We created a show and tell video at the end of the week to showcase the week’s work

With the showcase presentation completed we sat back to see what the other Down Tools week teams had been up to.

Key lessons

Down tools week was certainly fast and frenetic, but also very rewarding. Here are some key lessons for anyone attempting a similar 5-day challenge:

Divide and conquer tasks

Take a divide and conquer approach to tasks where possible. For tasks that didn’t require the whole team (such as building the prototypes) we split up into pairs or groups. Catch ups at the start, middle and end of the day ensured that the team co-ordinated activities.

Take regular breaks

Have regular breaks during meetings and workshops. Working remotely, we found that working for more than 45 minutes without a break was mentally (and physically) very taxing for team members.

Set-up development environments beforehand

In hindsight we should have set up development environments prior to the week. This would have freed up more time for developing the proof of concept (rather than battling with the SQL Data Catalog dev environment).

Run a proof of concept

Creating a prototype and proof of concept enabled us to not only test the concept with customers, but also find out how easy it would be to implement that concept. It also highlighted that you must choose your framework wisely. It soon became apparent that Intro.js was not a good fit for what we were looking to do with our interactive product tutorial and that we should re-evaluate our choice of framework.

Line up customer sessions

Lining up customer sessions prior to the week not only reduced the need for recruitment admin during the week, it also gave the team an important deadline to aim for. We knew that we had to have something to test with customers by the afternoon of day 4.

Take a design sprint approach

Taking a design sprint approach to the challenge proved to be very effective. Rather than blindly coding our idea (hack-a-thon style) it meant that we focused our efforts on doing just enough to test the concept, and just enough to find out what it would take to build the concept.

Sounds good?

If Down Tools week sounds like the sort of thing you’d love to do then why not take a look at the Redgate careers section. We are always on the look out for potential new Redgaters. Maybe next year you’ll be writing a blog post about your own experience during Down Tools week!

Image credits

Photo by natsuki on Unsplash

Ingeniously Simple

How Redgate build ingeniously simple products, from…