UX @ Red Gate

March 12, 2014
by Pete Hotchkin
1 Comment

Remote design collaboration

About a year ago I damaged my shoulder and needed surgery on it. Unfortunately that meant that I couldn’t get into the office, a 50 mile drive away. It was at this point that I started working remotely and ever since I have worked at least 2 days out of the office. There are lots of blog posts out there on the pros and cons of working remotely, personally I love it and whilst it doesn’t work for everyone it certainly fits in with the way I like to work.

One of the big things that I have heard mentioned again working remotely is the lack of collaboration that is possible when it comes to design work. I’ve been experimenting recently with different ways to overcome this and the breakthrough came when I was working on a new feature for SQL Monitor with one of my colleagues on the UX team. I had been working from his wireframes to get to a mock up that we could hand to the developers to build however it was felt that it wasn’t quite hitting the mark. The traditional method would been to have to either huddle around a computer, trying to change the design whilst keeping a conversation going or to send emails backwards and forwards.

The computer huddle

As I said, this is the traditional way that I have seen collaboration done. There are generally 2 big problems I find with this approach:
  1. Trying to iterate a design on screen whilst keeping a conversation going about whether the change is the right one or not means you can often end up moving things and forgetting why halfway through the change.
  2. Other people can often jump into the conversation halfway through. Whilst it can be great to have the teams input, it can often slow down a design if they don’t know the constraints that have been discussed before.

The email conversation

At one point in the past email was touted to be the fix for all communication problems and to a large extent it has done that however one of the biggest problems that it still faces is that some of the meaning is lost. I don’t think this is down to the fact that it uses the medium of text however more down to the fact that people put too much into an email. When you try and fit multiple points of feedback into a single email it is easy to mix one point up with another. This is further exasperated when you are looking at a flow of screens, as we were, because you cant be positive you are both looking at the same thing when going through the email.

The solution

I needed a hybid that would some how integrate the two approaches and this is when I realised that working remotely can actually help. I had already started a discussion using Skype‘s text chat so it made sense to keep going with that. From there I needed to show my colleague the changes I was making so I fired up join.me, a great screen sharing application as it doesn’t require the viewer to download anything, they can just view it within the browser.

Why does this combination work so well? It allows both sides to think about what they want to say before its committed to the chat box. It also allows time for the designer to make a change without getting more input before the change is complete. Having the real time interaction meant that the conversation was always relevant and we could try out options as quickly as if we were sat next to each other.

The result was that we managed to get a design sorted within about 20 minutes where as any other methods would have inevitably taken at least twice that long. Once we were happy with it, we talked it through with the rest of the team and explained our decisions. Doing it at this point, rather than halfway through the design discussion allowed us to explain the thought process as a whole and get buy in much quicker than previously.

As I work more remotely I am continually trying to find better ways of making it work. I would love to hear if you are working remotely, ways you are making design work. I haven’t tried it yet but my next investigation is going to be into use tools such as the invision app. It looks like they are doing great work in facilitating this type of distributed design work.

February 5, 2014
by Filippa
0 comments

Lessons learned running a remote diary study

User research through a diary study was a new experience for us. We always want to get first hand feedback from our users, and had hoped to do more site visits so that we could sit and watch people use out tools in their day-to-day jobs. There are 3 main problems with site visits:
  1. They are time consuming; it takes at least half a day out of the office to get feedback from one user.
  2. Often we don’t get to see the user in their work environment, we get whisked off to a meeting room to have a chat that could have been had over the phone.
  3. Lots of Red Gate customers are outside of the UK – which is expensive!
We wanted to find out what everyday annoyances our users had with SQL Prompt; our productivity plug-in for for SQL Server Management Studio. The sort of annoyances that aren’t significant enough to generate angry emails and support calls to Red Gate, but are enough to make you sigh every time you hit them.

Why choose a diary study?

Currently, the team working on SQL Prompt are using Uservoice to decide what to work on next; the most popular requests are prioritized. This is great for exposing features that customers care about, but not for finding out the small things that affect the day-to-day experience of using SQL Prompt. A diary study allowed us to monitor users for a week, we asked them to report daily on niggles or unexpected behavior in SQL Prompt.

What did we learn?

We’re still in the process of running the study but it’s been going well. We’ve collected a lot of useful data about how SQL Prompt is being used and issues that are annoying users. There are a few things we’ve learned along the way which we’d definitely take into account next time we run a diary study:

Set expectations for everyone

  • Make sure that the participants know the aim of the study beforehand; give them a license to provide criticism otherwise you can end up with lots of praise with very little to take away and work on.
  • Tell participants up front how much time you expect them to spend on a diary per day; we chose 30 minutes which gave us about the right amount of detail from the diaries.
  • We offered an incentive once users had agreed to take part in the study, and let all participants know that this would be forfeit if they dropped out.

Iterate, don’t cram everything into one week

  • For the first week we only ran the study with 3 “friendly” users; this allowed us to identify some issues with the study and iterate on our approach for the participants in the following weeks.
  • At the start of the study we had users filling in Google forms, we quickly changed this to shared Google docs to allow participants to include screen shots or other media in their diary entries.
  • We introduced a new question into the diary after the test run; finding out examples of SQL Prompt prompting something incorrectly – this gave us solid examples to take back to the development team to make the fix.
  • Noticing that Wednesday was the day that participants began to drop out, we changed the question format of the diary each day to keep them engaged.

Don’t bite off more than you can chew

  • We found 10 diary study participants in a week a struggle to organize, a more manageable number would be between 5-8.
  • One week is enough to collect valuable data, and enough to keep the attention of the participants. Any longer and you run the risk of a high drop out rate.
  • Analyzing diary feedback at the end of each day meant that we kept on top of all of the data we were receiving.

Tweet and respond

  • Having a Twitter account to prod participants during the diary study works well, it’s also a great way to tell everyone about the fixes we made to SQL Prompt during the study.
  • Fixing at least one annoyance per participant shows them that they really are making a huge difference to the product, and that their time spent on the study is worthwhile.
  • Tweeting about fixes made, means that everyone will see what we are doing with the feedback we get, and encourage more people to take part in future diary studies.
We gained a lot out of this diary study, and would recommend it as a great research tool to really understand how the product fits in with the users day-to-day duties, providing you have time to set aside for it. It really does need a lot of time spent analyzing the data and getting the diary studies up and running, but the results are worth it!

December 18, 2013
by Marine Barbaroux
0 comments

5 presents for UX geeks suitable for small and big pockets.

As we are approaching Xmas so quickly, I have asked around the people in our UX team what would be their ideal present in the field. The outcome is the list below, you can use for your late presents if you want to please a UX geek!

 1 – A lifetime licence of the Adobe’s  creative cloud

Most of the people in the UX field will have a licence for an Adobe product, but this could be the way for them to extend their horizon with tools they would like to play with, but can’t justify just now. OK, a lifetime is maybe a bit too much but you can do 6 months?

2 – The Paperback Collection One Pocket Guide from “Five Simple Steps”

pockets guides from 5 simple steps Five Simple Steps have released a ton of  well written, targeted and focused handy little guides. Now they have paperback versions too! Luckily, if it is too late to get it shipped,  you can always download the digital edition J

3 – Photoshop fridge magnets

Photoshop GUI magnets Just for a bit of a fun… I am sure we all love those to hold our photos on the fridge! Also, if your geek is interested in photography, photojojo is a great site to remember.

4 – Proper GUI magnets

If you are more into interaction design the magnets from http://www.guimagnets.com can actually be good fun, and eventually being useful at work too, to quickly sketch out ideas on a whiteboard!

5 – Life in 5 seconds

It’s a really cool book that describes famous stories, films and events in an ultra simplistic visual way. Look inside to see ET and Alice in Wonderland… Cool, and fun, don’t you think?    

November 29, 2013
by Stephen Chambers
1 Comment

My Experience Working in Product Support

I’ve had a bit of a rude awakening over the last few weeks. I’ve had to start handling support tickets for the product I’m working on. Product support?! I’m in the UX team! I DO NOT get my hands dirty. Ever.

It has been a bit of a culture shock. You know it’s having an impact when you have a dream involving two very scary tattooed blokes knocking on your door asking why you haven’t answered the support ticket for their client. That’s unfortunately a very true story.

Thinking back through my previous projects, it dawned on me that I had never really engaged with the company product support team. It’s not all one way of course, I’ve never been a point of contact for them either.

This can be explained, to an extent, by the different channels through which we have contact with users. There’s a dedicated support email address and support forums that I’m not attached to. It’s certainly not through any conscious effort to avoid the support team! I even like 1 or 2 of them. Sort of.

The take-home message of this post being: if you are involved in a UX role, you should spend a week working in product support.

Here are the reasons why, lessons learned and what the benefits can be:

Increased channels for understanding and accessing a greater breadth of your audience
  • I’ve massively underestimated the different levels and range of expertise of people who use our software. I always imagined that it would be a typical bell shaped curve when it came to plotting the expertise of the users of our tools. The type of feedback can be fundamentally different from that gained via more standard channels and cause you to challenge your assumptions.
  • It’s a great way of fostering relationships with users and finding out rich information as part of the user research process. It can also provide you with a robust and valid pool of people to gather feedback from when evaluating the success of design iterations and updates.
  • Things which didn’t come up in our usability testing or feedback mechanisms were being revealed over time through patterns in the support tickets. Small changes can lead to a significant improvement. This is well known of course, but they can be so subtle that they pass unnoticed through other forms of engagement.

Help us decide where the onus should be on current and future work 

  • The answers to support requests are often provided in the documentation. However, a number of people prefer to email support to ask the question and have a domain expert walk them through it. It can be because of the high risk associated with getting it wrong. This will happen even when the time taken to email and wait for a response will be much costlier in terms of time and to their productivity. There must be room for improving these particular touch points.
  • It has given me the ability to spot weaknesses or gaps in the design of the UI, documentation and website messaging. It was also able to guide me on what content should be written next, the critical points to cover and its priority.


Better integration between the product support team and user experience:

  • The communication channels between our support and UX team could be improved. Having the right software is required to enable this to happen effectively. A common platform to manage the communication and assign responsibility is a fundamental requirement.
  • There’s now the potential for automating what has always been manual processes. One of the most common support tickets is a user requesting an extension to the trial period due to them not having had enough time to evaluate the product thoroughly. Support have dealt with extending trials for years through a manual process. We’ve now implemented an automatic extension in my current project. When a user opens the tool and sees that the 14-day period has expired, they can get an automatic extension in exchange for some feedback submitted within the tool. It’s completely automated and reduces the workload on the product support team and something that we could potentially to roll out across our entire product line.

Conclusion: I think it can be summarised as: get your ass down to the shop floor and see it from a completely different point of view. You might be surprised by what you find.

November 29, 2013
by Marine Barbaroux
1 Comment

An alternative way to do customer interviews: the revelation of the JTBD framework

How to conduct a guided interview with the Job to be done framework

How to conduct a guided interview with the Job to be done framework – credits: http://www.flickr.com/photos/flibble/

I recently discovered the JTBD framework at Business of Software: what I learnt made me swear that I’ll use it from now on in every customer interview I need to do in order to understand their underlying needs and support our product pipeline. It is *that* brilliant. It’s like a targeted, systematic guided interview process, easy to understand and to use. You should use it too.

Better than focus groups

Having been involved in User Research for a while, I have been moaning for years about focus groups and how they can often mislead research by creating a wrong view of the market. If fact, the first time I was involved with one of these studies was as a design student, designing a new ‘form factor’ for a telephone. A manufacturer was looking at “refreshing the phone industry” which was up until then, quite grey and beige. They asked a set of users what colours they would like and how much they would pay for it. People suggested colours such as yellow, reds, blues, and so on. Later, when the session was finished, participants were thanked for their time with a free telephone and given a choice of whichever colour they’d like. There were the greens, and blues and the yellow available to them, but EVERYONE picked up a neutral grey (the risk-less option during those days). The conclusion was, as we know: don’t ask people what they want, but observe what they do.

You’ll get the idea in 4 min:

In contrast, the concept of the Job to Be Done has proven very useful to gather customer insights on the reasons why people purchase items and what influences their decisions. This is critical to making the right choices in successful product development or marketing.The concept was developed by Clayton Christensen (professor at Harvard, author of the “innovator’s dilemma”) and turned into a framework by Chris Spiek and Bob Moesta, original contributors to Clayton’s research. The best and quickest way to get familiar with the idea, is to spend 4 minutes now listening to Clayton talking about how and why customers of a fast food restaurant “hired” milkshakes before 8 am. http://www.youtube.com/watch?v=s9nbTB33hbg.

What’s the framework like?

It is important to note the framework is designed to understand the motivations of people who have already bought something. It is not designed to find out what would motivate a prospect to buy something in the future – in the same way it’s not possible to ask people what they do because you’re better off observing them. If you interview enough people, you’ll see some patterns emerging that will allow you to make hypotheses on how to improve your tool or landing page to attract more customers. Actually, there are two frameworks based on the underlying psychology behind any purchase process:

The force diagram.

Force diagram from the the JTBD framework. Captured for you by Red Gate UX It’s based on the fact that, left alone, people wouldn’t change anything in their current state, and they need things to make them tip over to become a customer:
  1. they need a good reason to change their behaviour(that includes buying something). This could be a problem of some sort (eg. their car is broken and it is more expensive to repair it than to change it) or a hope for a better life (driving with an open roof car would be sooo much better)
  2. they need to overcome two fears before they can proceed:
  • The uncertainty about the choice they have to make (eg. will life really be better with the new car? Can I justify it?)
  • Change the the habits of the present (eg. What will I do with my current car? The weather is never nice enough to drive without the roof)

The timeline

The timeline from the JTBD framework This is based on the fact that the purchasing process starts way before the purchase actually happens (for the reasons highlighted above) and there is always a sequence of actions that lead to the action of purchasing. Understanding those triggers is like rewinding time. Those two tools should be used to guide interviews and help you understand your audience. Be careful, though: for it to be really valuable, you need to interview real customers (ie. people who actually bought your product, not those just thinking about it) because until they’ve done it, you won’t be able to tell if they are realistically going to do so. This would ruin your understanding of the last trigger. The trick to making them valuable is to help the person to travel back and forth in time, and get them into a state of mind where they can remember and share every detail of their journey. For this you need to:
  • Introduce yourself and break the ice before you start the interview (like in any user test). Start by saying you’ll spend 30 minutes to understand how they came to buy [Insert product name here], that there is no right of wrong answer, and that we’ll ask questions to put them in context.
  • Start with what is known (eg: the time of purchase) and get them to tell their story from there, going back and forth in the narration so you understand it all. Use sentences like: “Can you tell me when and where you bought [Insert product name here]?” “Was it the first time you thought about buying something similar?”
  • Use anchors in your language to help people recall what happened. Try and ask them about concrete stuff, like what the weather was like, what they were wearing on that day, etc. It might look irrelevant, but it’ll help to put them in context so they can tell you their story, and almost forget about your product: exactly what you want!
If you want some guidance on how to conduct an interview, you can listen to this interview, conducted in Cambridge, last summer during a SWITCH workshop organised at Red Gate. It shows what’s at play when someone needs to buy a portable phone, and it’s fascinating.

When the interviews are done, what’s next?

In theory, after a few interviews, you should start seeing patterns emerging that you can base some hypotheses on. For instance,
  • most of the people coming to your website did so after visiting another website,
  • most of them were trying to achieve something precise under time pressure,
  • most of them share a similar profile,
  • people couldn’t purchase your tool unless they had the approval from their boss,
  • or something similar.
From those hypotheses, you can infer new marketing messages (for example how much of a time saver it is to use your tool), or new material (for example, a crib sheet for someone’s boss) or even new features (for example the reporting tool that makes the boss happy)!

To conclude:

In essence, the Job To Be Done framework is a set of tools designed to conduct guided interviews in a systematic way, with the intent to understand the purchase process that every human being is confronted with when making a purchasing decision. From these qualitative, research interviews you can spot some patterns that should highlight product improvements or business insights. It is a bit tricky to start with, because you need to avoid biasing your questions, but it looks like it becomes easier with a bit of practice. If you have conducted interviews like this, I’d love to read your comments. If you haven’t, I’ve designed an interviewer’s note sheet for you to download to get you started…  I hope it’s useful to you and good luck! Let me know how it goes too!  

October 11, 2013
by Marine Barbaroux
2 Comments

Lesson taken from Mind the Product #1 : Contextual Enquiries for the win!

Mind the product sketchnotes Undersstand your users

About 10 days ago, I attended the Mind the Product 2013 conference in London, and I was amazed by the quality of the speakers there. I was also impressed by the number of time “user experience” was mentioned at what was definitely a product management-focused event.

I left each talk with something I thought was worth considering as a way to improve our customer experience at Red Gate–some quick wins, some more difficult to implement. So I thought I’d share the ideas here, to open up a conversation, kick off some actions and monitor our progress. I am not sure how long the series will be yet, but I’ll attempt to cover each talk.

Understanding your users.

This was the title of Kelly Goto’s, (author of Web Redesign 2.0: Workflow that Works) talk.

To be frank, looking at the talk description, I thought I wouldn’t learn anything new: at Red Gate, we’d like to think we already know our users and their problem(s) reasonably well. We’ve worked for them for 14 years now (we’ll celebrate the company’s birthday next week), we often use the same tools they do, we usability test with users before any product is released, and we talk to them regularly via programs such as Friends of Red Gate (or FoRG) and site visits.

And yet, Kelly promised we could do better with something we all know about: contextual enquiry. She demonstrated that in order to make meaningful products, you need to understand your customers *well*. By that she means understand their behaviours more than their demographics (the traditional way marketers segment their audience), and that we need to understand what they do instead of what they aspire to do . The distinction is important, because the latter is generally what you get from user groups or surveys, both among the most popular research methods.

As UX practitioner, I know very well the benefit of “contextual enquiries”—but in my experience, I’ve found them rather difficult to conduct in Red Gate because:

- It is a reasonably time-consuming activity for the UX practitioner and your customers

- It is easy to get lost in too much data gathering if you are not focused in your research

- It is easy to bias your research if you are not well trained for it.

- The findings do not always suggest clear and immediate design decisions, so they are less popular within the development teams.

- It isn’t easy to see our customers at their desks or in a server room. When they meet a “product manager” they tend to host us in a meeting room, and it is awkward to ask them to do differently, especially if their boss is invited too!

- Along the same lines, recording audio of a meeting is usually fine, but it is harder to ask for people to let us take pictures, or film them.

- The reporting of the data gathered is quite onerous (write up of all the discussion) and not always sexy.

However, in an only one minute clip, Kelly demonstrated how valuable this work is. In sixty seconds, she conveyed the different ranges of customers their client had, their pain points with their product, and the conditions in which they were using the product. This was very powerful. So much so that she says many businesses and their marketing departments are using the technique: it is not a dark-age ethnographical practice anymore…

…And then, I thought about how we often use traditional personas, and how often we produce long research reports. And I wondered if we could complement (if not replace) them with clips like this, that are easy to share and to remember.

I can see many advantages to this:

- Avoiding bias is easier, since a video is just showing external realities (although I know we can create strong biases with editing video too).

- It is easier to share and consume with people outside our team, such as product management, development and marketing.

- It is easier to assess how typical this person is by asking your sales people how often they talk to someone similar.

- A movie is a much more memorable portrayal of a customer.

Of course, I know editing video will take us some time, and my intuition is that it is harder to film people working in their company than end consumers in their home… But is it true? Have we tried yet?

How ace would that be? And if it does end up being difficult, why not try out a tool like dscout, an adaptation of the diary research technique?

I am hoping we can try something like this here in the next few months, and I’ll report here. If someone out there has conducted contextual enquiries in a B2B environment, I’d love to hear about your experience to help me out!

October 2, 2013
by Richard A. Muscat
0 comments

Top 10 tips for getting a design job

I previously wrote about how to get a graduate position in UX or design. That post came out of two things: the fact that we were hiring graduates at the time, and that I was asked quite regularly at conferences and events what candidates should send us to demonstrate their suitability.

Now we’re recruiting again–but this time, we’re looking for senior designers.

As a consequence, over the past few weeks I’ve reviewed a ton of CVs, portfolios and assessments. Sadly, almost none of them have made it through to interview. So I thought I’d write down my top 10 tips for successfully getting yourself noticed and interviewed.

(Caveat: obviously this is very much based on what we at Red Gate happen to be looking for, and my own personal opinion, but I think some of these things are transferable to other companies and jobs. I’ll leave it up to you to figure out what applies to your own particular circumstances.)

The DON’Ts

#1: Don’t plagiarize others

You would be surprised, as I constantly am, at how much schoolboy copying there is going on in the world of CV and cover letter writing. The worst I’ve seen recently was a word-for-word rip off of this famous job application to 37 Signals. Most people aren’t so extreme (thankfully), but just be aware that if you’ve found a source of ‘inspiration’ it’s very likely we’ve seen it too! The main thing we look for in a designer is originality so by all means be inspired – but try to make it your own.

#2: Don’t plagiarize yourself

Don’t re-use your cover letters. If you’ve found a new vacancy to apply for, fire up a blank new Word document. Cover letters (or emails) make or break your application and as recruiters we read tons of them. Don’t copy yourself because we can tell and you just come across as lazy.

#3: Don’t send a CV

Don’t get me wrong, CVs are useful and in fact we require them. But given the choice between somebody with an impressive CV and somebody with an impressive portfolio, guess who I’ll pick? Your CV should almost be an afterthought. If you’re an experienced designer you should be sending me a covering letter/email with a list of links to stuff you’ve created or worked on and conclude with an “Oh by the way, my CV is attached.” (Also, please see tip #1 about not copying that sentence verbatim.)

#4: Don’t get cute with your CV

I’ve seen portrait and landscape CVs. I’ve seen ones organised around a timeline, ones pretending to be a conversation, ones full of catchy icons, ones using clever typography, ones looking like a poster and ones full of photos or illustrations. They mostly all suck. A CV is an exercise in information design and should be presented in a way that allows me to easily skim it. If you make sure it’s neat, is in a readable font (and font size), and is 1-2 pages long you’re way ahead of the competition.

#5: Don’t say you want to change the world, etc etc

If you actually *have* changed the world by your work, then by all means tell me about it. But please don’t tell me that you’re a self-starting team player motivated by desire to change the world by working for a world-class organisation, etc etc etc. Most companies will hire designers based on demonstrable skills, not pie-in-the-sky aspirations.

The DOs

#6: Be humble and honest

Humility and honesty don’t have to mean underselling yourself. You should be proud of your achievements and we want you to tell us about them. But don’t overdo it. Go ahead and big yourself up and boast about your work–but do it elegantly. Its a fine line, and often a sign that you’re crossing it is the (over)use of superlatives. If you find that you’ve written about your work and described it as ‘awesome’ or ‘amazing’ or ‘groundbreaking’ consider re-writing that phrase to tell us about how you felt doing that work and then just show us what you produced. Your work should be able to speak for itself.

#7: Apply user centred design thinking

Put yourself in the shoes of the person reading your application. What’s motivating them? How much time do they have to read your letter? What will pique their interest? If you’ve not recruited people yourself, find somebody who has and do a bit of research. Use your user centred design skills you have to give it your best shot.

#8: Actively seek feedback

The corollary to tip #7 is to ask for feedback about what you’re sending a prospective employer before you send it. It can be hard asking for critical feedback on your CV and job application letters, because they can be quite personal things. But try to do it all the same. If you have a partner or spouse, definitely ask them; if you have a fellow designer you trust, even better. They’ll tell you things your partner can’t (or won’t!).

#9: Write good words

Designers suck at writing words. Just try to get better at it. Re-read and wordsmith your application obsessively. Don’t use fancy words just for the hell of it. And with every re-read, try to make it simpler and shorter.

#10: Make your stuff into a PDF

If you’re sending documents, make them PDFs. They render so much better than Word documents.

Don’t forget to check out our current vacancies and if you liked this post, follow me on Twitter.

September 20, 2013
by Meghan
0 comments

UX in the Real World: the C-pump

“Hey, I’ll write a semi-regular post series on user experience conundrums I see in everyday life,” the incredibly naïve UX blog owner thought to herself. “It’ll be lighthearted, and funny! Everyone likes casual discussions of usability!”

Readers, I come to you a battle-scarred veteran of a war raging throughout Red Gate. The introduction of this item into our working lives has caused arguments over every social media network we have available to us. Working relationships are being tested; friendships are being broken; hands are being washed. And it’s all over this:

Look on my dispensers, ye mighty, and despair.

Yes: it’s a soap dispenser. But not just any soap dispenser: it’s the Joseph Joseph C-pump, designed as a more hygienic approach to soap dispensing. A recent refurbishment of our work bathrooms has resulted in these springing up like little plastic wildflowers. This picture gives you a better idea of how it works in action:

Most photos of it, incidentally, show it with a hand in the photo to illustrate how it should be used.  And that change to soap deployment method seems to be its selling point: touching the dispenser with the back of your hand means you spread fewer germs around. The problem is, of course, that it’s a drastically different way of getting your soap than what everyone is used to, which means a sizable minority of our company hates it with the fire of a thousand suns.

A thousand endless, burning suns.

But internet campaigns aside, there is actually an interesting conversation to be had about this dispenser. From a usability standpoint, there are definitely a few advantages: it makes it harder to accidentally dispense soap onto the counter, it cuts down on the amount of germs on the dispenser, it is pleasingly quirky. Where it fails, though, is in affordance—the term Donald Norman introduced in his classic The Design of Everyday Things—meaning how a design encourages its own particular use. If you look at something like an elevator button, or a long narrow handle running the width of a door, the way it looks encourages you to use it a certain way: to push the button, to pull the handle. The C-pump, on the other hand, is not only asking you to use it in a way unlike any soap dispenser you’ve used in the past, but to use it in a way—pushing with the back of your hand—that isn’t a natural movement. The reason most pictures of the dispenser have a hand in the photo is because, at first glance (or third, or fourth, if you listen to many Red Gaters), it’s not obvious how it’s supposed to be used.

Is that an insurmountable design flaw? Possibly not—it’s different, but it’s not impossible, and the adjustment period seems to be a short one. What I’ve found more interesting is seeing the number of people who have started using the C-pump like a regular dispenser, pushing down on the thin plastic at the top as if it’s a regular nozzle. Hygeine and innovative design be damned: somehow, affordance will find a way.

September 2, 2013
by Richard A. Muscat
2 Comments

Childishness, UX Maturity and Growing Up

A couple of months ago, much to my shock, I found myself in agreement with Pete Hotchkin, a design colleague of mine, in a discussion with the rest of the UX team. This was such a momentous event that I decided to blog about it. And no, this anecdote isn’t where the “childishness” in the title is coming from — it comes from the discussion we were having about the idea of UX maturity and how we would rate our own team.

The Questions

Late last year, the Leadership Team at Red Gate embarked on a process of fleshing out Red Gate’s long-term vision and objectives; the company has been steadily expanding, and so they agreed that we couldn’t just assume that everyone was on the same page and had the same understanding of our goals anymore. Inspired by their example, our UX team’s fearless leader, Marine, thought it would be an appropriate time for us to do some similar thinking about how well user experience is integrated into Red Gate and its goals, and what we’d like to aspire to for the future.

We found Rich Buttiglieri’s model of UX Maturity particularly helpful as a way to give us a way to grade ourselves. In a nutshell, it places UX Maturity on a 6-point scale: “0,” the lowest, means UX is wholly unrecognised in the company, while “5,” the highest, indicates that the organisation is UX-driven and UX is a core part of company strategy. The 4 shades of grey in between represent varying degrees of company investment that you can read about in more detail on this deck (if you’re looking for the shortest explanation, skip to slide 7).

The Results

Marine asked each member of the UX and Leadership teams to rank Red Gate’s valuation of user experience on the scale and submit our rankings to her. When the results were in, senior managers had put Red Gate firmly at 4, which Buttiglieri describes as “well integrated with overall product development cycle,” while most UX team members had ranked us somewhere between 3 and 4, which is described as having a well defined UX process, but not as systematic as it could/should be.

My own initial assessment had been to place us between 3 and 4, but on reflection I found such a high level of agreement to be somewhat suspicious (what can I say, I’m a contrarian). I decided to dig deeper by copying the bullet points from Buttiglieri’s Stage 4 slide onto a spreadsheet and colour-coding them:
  • green if I thought we’d achieved this consistently over the past 6 months company-wide.
  • orange if we achieved them inconsistently
  • red if we had never achieved them
I reluctantly had to conclude that they were all red except for one: “Cultural buy-in.” I repeated the process with the bullet points from Stage 3; this time I rated us as mostly orange, with a couple outliers on either end. Doing the same for Stage 2 resulted in almost all green ratings.

I came to two conclusions. First, and most importantly, my colouring skills were in fine nick. Second: in reality, or at least my subjective judgement thereof, we were closer to a 2/2.5 than a 4. It was at this point that I emailed my thoughts to the rest of the UX team and received Pete’s shocking +1 in reply. This was followed by more discussion largely in support of my view—including by the Leadership Team, who later on with Marine’s facilitation revised their own assessment to “almost 3.”

So What Happened?

Red Gate is known, both in and outside the company, as caring tremendously about great design. The concept of “Ingeniusly Simple Software” is central to everything we do. So why, then, did we end up rating ourselves so badly on a scale designed to show how much a company cares about good design and user experience?

Here’s what I think happened, and what anyone should take into account when trying to use this or any other UX maturity model to measure how UX is valued and implemented within an organisation:
  1. A “model” of any sort is unlikely to map directly and perfectly onto your circumstances; there will be biases, generalisations and missing contexts. Within Red Gate, for example, there is high cultural buy-in for the value of UX. From CEO to devs, everyone strongly believes that having a UX designer on a project makes a remarkable difference to the final product quality. This sort of UX empathy wasn’t an explicit bullet point on this model, which I think led us to feel that it was impossible for us to otherwise be so low on the scale. Recommendation: Whenever you pick a model, remember that it’s gleaned from someone else’s research across a range of different organisations. As such, it is a sort of “average” – sometimes you’ll be below that average and sometimes above. Try to be critical of the model as well as yourself!
  2. Over the past few years we’ve migrated to a model where one or two UX designers are embedded in a project team. I strongly suspect that if we measured our UX maturity on a per-project basis we would have a much wider distribution of results, as well as higher ratings for the individual teams. Recommendations: When measuring UX Maturity, be clear upfront whether you’re measuring the organisation holistically or the quality of individual designers and projects.
  3. Don’t underestimate how hard it is for you to be honestly critical of your own work/team/product/company. Recommendation: Don’t confuse being happy with your job with having little to no room for improvement.
  4. Be very wary of “groupthink”. Recommendation: The main symptom of groupthink is a quick and painless consensus. If you see this happening, play devil’s advocate (constructively!) to see if any alternate viewpoints come up.

What’s Next?

We agreed that this model isn’t a perfect fit for how UX fits into Red Gate; the fact that the cultural atmosphere isn’t a part of the evaluation, as well as the fact that we’re trying to apply a universal rating to several sets of project teams rather than a single UX team, leaves us with a score that on paper at least looks alarming! The other benchmarks, however, are still useful ways of measuring our progress as we develop, and so we feel that continuing to include our rating is a valuable part of the conversation around Red Gate’s UX. Both the UX Team and the Leadership Team have made a deliberate and committed decision that as a company, we want to have Buttiglieri’s Stage 4 as a medium-term goal, and we’re currently working on what that will actually look like for us as a company and concrete steps to get there.

Do you think you can help us? We’re currently hiring both a User Experience Designer and a Visual UI Designer, and if you’d like to play a part in taking us to the next level of UX maturity, we’d love to hear from you!

If you liked this post follow me on Twitter for more.

August 27, 2013
by Meghan
0 comments

Red Gate Delivery: a Q&A

As a lead-up to UX Cambridge, this week we’ll be putting up a series of posts about what it’s like to be part of the UX team at Red Gate. And what do you know, we’re currently hiring for two UX positions. Today we’re featuring a Q&A with our Delivery division, which is where our new hires will most likely be located. If you’re intrigued, stay tuned to the blog and, as always, feel free to get in touch!

1. What projects are you currently working on?

Delivery is a really exciting place to be right now. Our bigger-picture goal is to link our individual tools into a streamlined, cohesive workflow; on a project level this means we’re doing everything from updating our older products to use newer technologies (for example, moving towards HTML5) to overhauling our UIs to putting together two teams focused entirely on improving user experience. I’ll talk about a few of our projects to give some specifics.

SQL Source Control: Source Control is a key part of the Delivery cycle, and we’re aiming to turn it into a mature product that bigger customers can rely on. We currently have 10 dev/testers working on the team, and we’re looking to balance working on some tough technical challenges for new features versus delivering some crowdpleasing features our users have been clamouring for. Technology-wise, we’re exploring tooling for new source control systems like git and hg, and we recently released an HTML5 interface to improve the evaluation experience.

Deployment Manager: Deployment Manager is a relatively new project, but it’s the next logical piece that connects the other portions of our Delivery cycle. It’s in its relative infancy, but we’re devoting a chunk of our resources to it; we currently have 6 dev/testers on it. The team has released every two weeks since November, and we’re looking to keep that pace up. It’s an ASP.NET MVC project, and we’re particularly interested in getting some experienced frontend developers on board as well.

Customer Joy: Pretty much what it says on the tin, this project is all about improving the customer experience. It’s a small team at the moment, but we’re hoping to deliver a mix of quick wins, minor feature updates, and bug fixes, driven very much by customer demand. This team is in close communication with sales and support in order to figure out which features and bug fixes will please the highest number of our users, but otherwise it’s quite an independent team.

These aren’t the only projects we’re working on in Delivery, but they give a good overview of where Delivery is headed and the kinds of projects we’ll be continuing to work on in the future.

2. How significant are these projects to Red Gate?

These are all VERY significant projects. About a year ago Delivery’s focus as a division moved to integrating all of our products into one incredibly big, incredibly useful workflow; these tools are used by hundreds of thousands of users around the world, and their development is critical to Red Gate as a business. This also means the work involves everything from improving longstanding products to working on very new areas, so there are a lot of different areas and technologies to work in.

3. How are teams structured on projects? How do team members work together?

The teams are a cross-functional mixture of a few devs, a few testers, a UX team member, a tech comms person, a product marketing manager, a project manager and a product manager. They sit together and collaborate closely; everything is done as a team. The team areas end up plastered with designs/post-its/testimonials/usage graphs.

As far as the UX team member specifically, each UX member is embedded in a team. The UX member is integral to the team and typically leads design efforts, works with users, conducts research, and more! UX is done as collaboratively as possible and all teams regularly have sketching sessions and run usability sessions.

4. When someone joins a team, what will they be doing? What will their first couple of months at Red Gate be like?

Induction schedules at Red Gate are usually tailored to the individual joining, but there are a few general objectives that just about every new hire will get. The first couple of weeks are usually more scheduled than normal, as we like to make sure you’re introduced to your project team, the rest of the UX team, and that you get a grounding in the other major functions within the company. It’s also company policy that for your first week, you’re sent home by 5:00 P.M. at the very latest!

By week three, you should be getting into some actual project work. Many new hires will start with a couple of shorter-term projects during their first three months—one recent example of this was a project on rebranding and improving an acquisition to ensure its next release was recognisably Red Gate, and up to Red Gate’s UX standards. This involved working with the Agency, our marketing/creative department, to create a rebranding brief; performing an expert review of the tool; conducting usability sessions to identify and prioritise usability problems; producing some designs for UI improvements, and presenting them to the project team. Future projects will probably look totally different, but the general idea is to give a new hire a project that’s tailored to their skills and interests, that will involve working with the rest of their team, and that has very clear progress and development goals.

By the end of your first three months, you should be integrated fully into your project team, have completed a few smaller-scale projects, and be an active member of the UX team!

5. And lastly: what’s it like working in Delivery?

Obviously it’s awesome working in Delivery! Things move pretty quickly which means the job is pretty varied – an average day might include running a UX session with a customer to show them a new feature, mocking up some new designs for a prototype, calling customers and doing some research about who they are and how they work, pairing with a developer who’s implementing some hifi UI tweaks, and more.

We’re responsible for a huge number of tools which until now have collectively been just a bundle of unconnected tools – our challenge ahead lies in tying these tools together into a cohesive Delivery story. We’re also looking at moving away from desktop apps and winforms towards web and HTML5, making our UIs more streamlined and beautiful. Above all we’re all about the user (we’ve got two teams working on Customer Joy!) and understanding their problems and doing what we can to solve them is what we’re most passionate about.