UX @ Red Gate

August 13, 2014
by Marine Barbaroux
7 Comments

UX katas – Heuristic evaluation.

Heuristic Evaluation Kata in action at Red Gate. The “extended” UX team sharpening their swords…

At Red Gate, our software engineers run regular  “code katas”, workshops where developers practise their coding skills on simple problems, then discuss the experience afterwards as a learning exercise.

So, a while ago, I thought it might be a good idea to use the same Kata principle on UX tasks and activities. The aim is to help us:

  • deliberately learn new skills (I’m very keen on “deliberate practice”, since I saw Kathy Sierra’s talk at Business of Software last year)
  • sharpen the skills we don’t use that often as part of our day-to-day project work
  • spend time together as a team
  • share practices with people who are involved in UX activity outside of our team (for example technical authors).

We organised our first kata last week, on “Heuristic evaluation”. The session lasted 90 minutes and I thought I’d share how it worked.

Session plan

Intro (10-15 min)

We spent the first 10 to 15 mins reviewing the theory and methodology of heuristic evaluation, for example, when it is suitable and when it isn’t, how many evaluators you need etc. (You can read more about this here: http://www.nngroup.com/articles/how-to-conduct-a-heuristic-evaluation/)

We also reviewed the heuristics themselves, using the classic list of “10 usability heuristics for interface design” from Nielsen and the review checklist by Deniese Pierotti from Xerox. Whilst the checklist isn’t *quite* always applicable to websites, it gives a good sense of what type of issues relates the the different heuristics.

Evaluation (45 min)

Our aim was to evaluate the revamped Ryanair website. The format at this first stage was for each attendee to review the site individually. Whilst not strictly necessary, I’d prepared some user scenarios to help focus on the tasks. This meant we’d look at the same part of the site, thus increasing the number of different findings.

tasks for the Red Gate heuristic Evaluation kata The scenarios used for our Heuristic evaluation Kata

the new ryanair site as per JUL 2014 The Ryanair website as per Jan 2013, thanks to Wayback.com

ryanair web site as per Jan 2014 Ryanair homepage as per July 2014

Review (20 min)

I split the attendees into two groups of five, hoping to demonstrate the impact of the number of evaluators on the results. Each group discussed their findings and listed the “issues” they found. Both groups found in total between 40 and 50 problems.

I am sure this won’t be a surprise for most of you: overall, we found that even after being revamped, the Ryanair site had a lot of usability issues. We assumed some of these are deliberately designed to be confusing for the users and trick them to buy something they didn’t anticipate (like the “travel without insurance” menu item in the country list). Some of them are just affordance issues, and could improve the site without compromising Ryanair values (like making the “book now” text in the journey planner clickable)

Red Gate UX heuristic evaluation kata - page 1

one page of the many we produced…

Debrief (10 min)

We took a bit of time to discuss the Kata format, and what we’d need to improve for next time.

Findings:

Are you interested in those? If so say it in comments and I’ll type them all up :)

Conclusion:

We found a large number of issues in a short amount of time, but due to time constraints, didn’t have time to prioritise them during the session. I’d forgotten about the values of heuristic evaluations, and when there are a few of you, it is really a good thing to do.

If you are lucky enough to be a group of UX practitioners in your organisation, I’d highly recommend running a kata like this. The 90 minutes were well worth it:  not only did we review  (in some cases, learnt ) the heuristics, but it was also fun and we had a good laugh too (often at the expense of Ryanair).

There is still some rom for improvement, though. We reckon we’d need to give access to the tools and methods to the “non-ux-ers” more time in advance, so they can be more familiar with the techniques before using them…. We’ll certainly try and do this for our next Kata: cognitive walkthroughs.

Now, I am considering whether we should send the list of issues to Ryanair… What do you reckon they’d say?

New Wizard Design in the Microsoft Azure Portal

May 22, 2014 by Stephen Chambers | 1 Comment

There’s little doubt that Microsoft has been investing heavily in the (re)design of many of its existing products and taking a different approach when creating its newest products. Some have been quite successful whilst others have been met with a wall of criticism and even anger (Windows 8 anyone?).

View the pictures →

This gallery contains 3 photos

May 15, 2014
by Marine Barbaroux
0 comments

Centralised or Embedded UX? How the team is organised at Red Gate

I’ve been asked several times recently what it’s like to work in UX at Red Gate and how we organise ourselves as a team. In this blog post I’ll attempt to briefly answer those questions.

1 – We are a functional team.

Development at Red Gate is split into divisions based roughly on product maturity. Each division contains a small number of multi-disciplinary teams, comprising the various skills needed by their project. For example, a mature product with a large user base typically requires a different type and scale of development compared to a newer, riskier, more experimental product, as well as a different style of design. This divisional structure helps us have processes and skills appropriate to the products being developed.

Product Development at Red Gate

Simplified view of development at Red Gate.

UX people are embedded in development teams. We are not a central design studio. However, we do meet regularly as a group to discuss function-specific issues (such as establishing a UX roadmap in the company), collaborate on non-product related matters (sharing project retrospectives, watching UX related videos and webinars etc.), and run design katas (where we sharpen our design swords). We also encourage UX people to meet on an ad-hoc basis to share design problems and help each other out.

Schema of the User Experience Team at Red Gate

The User Experience Team at Red Gate is embedded in development teams but meet regularly to share knowledge.

2 – Neither centralised, nor decentralised.

As well as the teams that keep Red Gate ticking over as a business (finance, HR, facilities etc) we have three development divisions:

  • The first one, deals with market validation. This operates like an incubator within the company: hosting internal start-ups exploring new markets.
  • The second one, works on opportunities that have been validated in the first division as being worth more effort. A little bit like an accelerator.
  • The third one, maintains our mature products and make sure they satisfy our customers.

In each of these divisions, the UX needs are different, and therefore we are organised differently in each of them:

  • In the first one, there are 3 small development teams, with a single designer shared between them (and hopefully a second one soon). Unlike the rest of the company, the teams don’t have very specialised roles (such as “project manager”, “technical author”, “sales person” “marketing expert” etc.) but everyone does what needs to be done in the project regardless of job title. This is very much like a startup environment. If you are designer and some copy needs to be written, then you might well be asked to do it. Equally, we expect software engineers to run user tests if that’s what the project needs at the time.
    Red Gate - Division 1

    In the first division, 3 teams share one designer.

  • In the second division, there are 3 teams, working on projects that have graduated from the validation phase to be a bit more mature. These teams are multidisciplinary, and our aim is to have one designer per team. The designers are managed by the project manager, and have to collaborate with product managers, developers, tech authors, etc. to deliver the project. Roles are a bit more defined, but it is still very much a multidisciplinary, collaborative approach.
    Shema of the second development division in Red Gate.

    In the second division, we aim at having one designer per development team.

  • In the third one, there are 6 designers covering 40 products (not all in active development) and 3 project teams. There, the UX people work in rotating pairs on one or two products at a time, according to the product pipeline schedule. At any given point in time, the designers are still embedded in multidisciplinary teams, but they are also part of a wider group that sit together in the division. In this part of the organisation, designers are managed by other designers, and we play to people’s individual strengths (in visual design, interaction design and research) as much as possible. This allows for peer design, good knowledge sharing, and quickly ramping up on a project.
    third development division in Red Gate

    In the third division, UX people work as a team and pair to work on one or two project at the time.

Last, we have one visual designer shared across all of the divisions. Right now, he is working on a style guide to unite them all :)

Division4: The Red Gate DNA.

Our Visual Designer is shared across all divisions.

So, in a nutshell, that’s how we work at Red Gate. We are neither a design studio nor fully decentralised. We hope we get the best of both worlds: flexibility, consistency, common practices where suitable, the potential for people to share and learn from each other and an opportunity to expand their skills.

This way of organizing ourselves as team is still quite new to us, so we expect it to evolve as we learn what is and isn’t working well.

If you are working in a centralised or decentralised team, I’d love to hear what your experience is, so make sure to comment below!

Oh, and by the way, we are hiring :)

March 12, 2014
by Pete Hotchkin
4 Comments

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
2 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
3 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.