Red Gate's User Experience Team

Evening of User Experience

Adam Walker — Wed, 17 Apr 2013 10:47:46 +0000

We’re looking forward to hosting Software East’s Evening of User Experience on Thursday, April 18 from 6pm-9pm. Along with drinks and networking, there’ll be three talks:

Andy Priestner & Ange Fitzpatrick – “Love, Actually”: building relationships and developing information services through social media outreach and real life interaction
Lorisa Dubuc – “Mission impossible?: Global charter, remote channels, twenty customers and two researchers…”
Tim Caynes – “Mobile Design & the Death of Narrative”

Targeting Actions for Great User Experiences – Dot Vote or Force Rank?

Andy — Fri, 05 Oct 2012 14:12:23 +0000

“A Meeting without an Objective is a Chat”, so states the Book of Red Gate. In my experience setting a high-level objective for a meeting is easier than getting agreement on the list of actions to reach it. Likewise setting the goals of usability tests seems much easier than forming the prioritised list of development actions or product features afterwards.

At Red Gate we are always keen to use facilitation techniques such as Gamestorming to encourage participation from everyone in a meeting. If you are not familiar with Gamestorming, these are collaborative activities focused on resolving specific issues. We decided to spend a “Collab Lab” session evaluating two techniques for closing a collaborative session – Dot Voting and Forced Ranking – to establish their relative advantages and get some experience on when we should use one and not the other.

Dot Voting

Dot voting is a simple technique to prioritise a list of items into an agreed solution, these items could be actions or product features. The items are written on a whiteboard or by sticking Post-It notes to a wall. Each participant gets a set number of votes that they can cast on those items – they can even vote for the same item multiple times if they feel strongly about it. Some items may not receive any votes. In this exercise we used a whiteboard and the participants used markers to cast their votes, which makes it easier to remove and re-cast a vote compared to using sticky dots or making a more indelible mark. In our session the list of 10 items were written on a whiteboard and each participant got 5 votes. All the participants cast their votes at the same time by marking an item with a dot. This is a public activity where participants can see the others’ votes being cast. After the votes had been cast they were tallied so that the items would be prioritised.

Force Ranking

Force ranking is also a technique to prioritise a list of items into an agreed solution. Where it differs from dot voting is that every item must be ranked relative to the others. The important consideration for the facilitator is the framing of the question given to the participants – the criteria needs to be very clear. For example, “The most important features for the next software version”.

In our session the list of 10 items were printed out and each participant received a copy. The facilitator framed the exercise to target a specific criteria and then the participants were given 6 minutes to rank the items from 1 to 10, where 1 was most important and 10 least important.

After the time had elapsed the ranking of each item was tallied so that the items would be prioritised.

Results Comparison

After both activities were completed the priority scores were compared and the favourite items ranked in order, as below.

Comparing the two activities there was little difference in the overall ranking, but there were variances in the results for 3 items (5, 7 & 8). The participants suggested that this difference was because Force Ranking made them consider the items in relative importance to each other, not just the most important overall. This made them re-evaluate items more thoroughly during Force Ranking.

Although a couple of participants force ranked the items easily in one go, most commented that they changed their minds a lot and wished they had an easier way to shuffle the items into order as they iterated. They suggested that having each item cut out would have made it easier to achieve this.

Conclusions

If you need to get consensus on a list of actions then either Dot Voting or Force ranking are great activities to get all stakeholders involved. The results are broadly similar for the most popular ranked items. Choose Dot Voting when the most popular items need to established; chose Force Ranking when you need every item ranked in relative popularity. Here’s a summary of what we discovered about using the two different techniques:

Dot Voting

Easy and quick to establish the most popular choices
Useful where not all choices are necessary
Voting multiple times for the same item can establish the strength of opinion
Simultaneous ranking activity – seeing the votes already cast could influence the casting of remaining votes
Even though participants could change their minds, none of them changed a vote once cast. Even though the marker dots made this easy to do, some commented that they soon forgot where they had voted and were concerned that they risked changing a vote that was not legitimately their own
Tough choices could be avoided since not all items may get votes. Facilitator should verify that items without votes haven’t been missed without reason, so it’s worth revisiting these with the participants to check this is the case before settling on the final list of actions to focus on next

Force Ranking

Takes longer than dot voting – can feel like harder work too
Individual ranking activity – less likelihood of influencing others
Tough to sort the middle ranked items
No direct indication of strength of opinion for specific items other than the overall tally
Participants reported that they changed their minds at lot when ranking – they suggested having the list as Post-Its or cut out lists that they could easily re-order
Forces tough choices when ranking unpopular items
Ranking all items requires more careful consideration of all items

Running a Live Lab at a Tradeshow

Michele Ide-Smith — Tue, 17 Jul 2012 07:55:09 +0000

How do you design a software application in 3 days at a conference? Earlier this year my colleague James Murtagh, a Marketing Manager, pitched the idea of ‘Red Gate Live Labs’. His inspiration was drawn from Lean Startup and the Nordstrum Innovation Lab iPad app case study.

“By the time the product is ready to be distributed widely, it will already have established customers.” Eric Ries, The Lean Startup

In Lean Startup, Eric Ries advocates getting a product idea in front of potential customers as early as possible, to establish if there’s a market for it. Once you’ve validated that customers will pay for your product, you iteratively improve the concept and design based on their feedback. James also read ‘The Next Evolution of Marketing: Marketing with Meaning‘ which promotes engaging customers to create meaningful communications with them.

Our Hypothesis

Source controlling application code is common practise in most development teams. However, source controlling a database can be time consuming and painful. Developers use alternatives, such as backups instead, but this workaround is less than ideal. Based on conversations with existing customers, we formed a hypothesis:

Oracle Developers and Database Administrators (DBAs) need a better way to get their database schemas into source control

Running a stand at a software conference (or tradeshow) typically involves giving demos, talking to customers and giving away promos. Kscope, the annual Oracle Development Tools User Group (ODTUG) conference took place in June this year. The conference provided an ideal opportunity to validate our hypothesis using the Live Lab concept. We convinced the company to let us try it out, by designing a Source Control for Oracle tool in 3 days and getting feedback on our designs. Here’s what we did in Texas…

The Live Labs Stand Design

Our internal marketing Agency came up with an awesome stand design!

On the left was the user experience area: for lo-fidelity paper prototyping and gathering customer feedback. You will see later in this post how we used the whiteboard to the left and the rear wall of the stand for post-its from customer feedback sessions.
On the right was the development area: for hi-fidelity HTML/CSS prototyping. The scrum board was integrated into the design of the stand to track progress with team tasks. This area was also used for product demos of our existing Oracle tools.

The Methodology and Process

We split the 3 days at the conference into 9 mini Agile sprints. The sprints coincided with break times when conference attendees were in the exhibition hall. In between breaks we aimed to review the feedback we had gathered and iterate the designs for the tool.

Paper Prototyping

Ok so I admit we cheated a little bit. I prepared a basic paper prototype of our Windows application before we arrived in Texas, based on feedback from a marketing survey and a couple of telephone conversations with existing customers. This was partly because we had such limited time at Kscope, that we wanted to have something to show people and start collecting feedback on our designs as soon as possible. The prototype was quick and easy change on the fly as each interface control was stuck on separately. For the stationary geeks among you, I used Sharpies (fine and super fine), a Letraset warm grey marker, a red Sign pen, scissors and Blue Tac. I also took print outs of two simple ‘frames’ I created in Balsamiq to emulate desktop application windows and a printed screenshot of a Windows desktop. As you can see, my handwriting is not very legible, but it was legible enough! I created a rough flow diagram of the workflow to help participants understand the concept more easily.

Feedback Sessions

Over 3 days I ran about 25 feedback sessions with developers, DBAs and team managers. I must stress that the sessions were not usability tests. They were somewhere between an interview, a participatory design session and a usability evaluation. Before we went to Texas I searched online for write ups about doing usability testing at a tradeshow or conference. Surprisingly I found very few references in the literature. But one good reference I did find was a paper titled ‘Extremely Rapid Usability Testing’ by Mark Pawson and Saul Greenberg (2007). Pawson and Greenberg designed their method (ERUT) to:

Assess the usefulness of the core functionality of a product, i.e., was the product’s unique selling proposition solving a problem that a majority of customers wanted solved?

Find major usability problems in the core functionality.

My method was similar, but unlike Pawson and Greenberg I didn’t have a sectioned off area for usability testing and I wasn’t evaluating an existing software application. My method was closer to the Nordstrum case study mentioned above. We were very keen that our process was transparent and engaging. We wanted customers to feel involved in the design and development of the tool. Before the conference, I didn’t know if we’d have 2 minutes or 20 minutes with participants. As it turned out, many participants stayed for 15-20 minutes, and some stayed for 30 minutes to 1 hour! Because of the fluid nature of the traffic to the stand, we weren’t able to recruit participants in advance or for a specific schedule of sessions. Instead my colleagues (from Marketing and Project Management) and myself initiated conversations with anyone who visited the stand. We asked a few questions about the person’s role, development environment and processes, use of source control etc. If the person was interested in source controlling their databases, we would invite them to participate in a feedback session with me (providing I was available).

A feedback session with some of the speakers from Kscope: Cary Millsap, Dominic Delmolino and Ron Crisco.

Data Collection and Analysis

Unlike normal usability tests, I was unable to record the sessions. The environment was very noisy, so recording audio was tricky. And it felt awkward to ask consent to be recorded if a participant only had 5 minutes to spare. However, when a participant was relaxed and able to spend 20 minutes or so with us, we asked for consent and one of my colleagues used a Flip camera to get overhead shots. We had an action camera positioned above the coffee table, but we found the sound and image quality was fairly poor. I used various methods for collecting feedback:

During the sessions I wrote observations on sticky notes (as in the photo above) and stuck them on the rear wall of the stand. I used the KJ Technique (or affinity diagramming technique) to group similarly themed sticky notes together in between feedback sessions. I stuck orange dots on any feedback that I incorporated in design changes, so I could keep track.
I used an empathy map (hat tip to Dave Gray) to collate snippets I picked up from conversations about what people feel, say and do, what’s important to them, their pain points and what they’ll gain from having the tool. I created some provisional personas before the conference, and have since used the empathy map to update them.
It’s important to know what development environment our customers use (for Oracle database development) and what source control systems they use, as there are several. I wrote the names of systems on sticky notes and used sticky dots to track which systems participants said they used.
Although I hadn’t planned for it, I found it extremely useful to sketch out someone’s process with them, let them draw a diagram of their environment or come up with UI design ideas. This was particularly useful to validate my understanding of a participant’s team, their development environment or process. With one participant, Wendy, we were able to identify her pain points together and then look at how our tool could solve her problems.

What was really great about my feedback ‘wall’ was that some people who participated in our feedback sessions returned on day 2 and 3 to see what feedback we had received and if we’d implemented feedback from their session. I had conversations at the coffee stand with previous participants who were delighted to know I’d updated the UI based on their feedback. The empathy map became a talking point and developers liked to see what development environments people used. One guy said he used Notepad, and a couple of participants noticed that post-it and said “Oh that poor Notepad guy!” All the time I was learning not only about how Oracle developers work, but also about their organisation and team culture. This was something I wouldn’t have got from running remote usability tests back at the office. At the end of each session I asked participants to complete a small feedback form which helped to validate our hypothesis, and collect email addresses for our Beta list. Along the way we made several tweaks to the paper prototype and I was able to test these out and get immediate feedback, for example changing details in a system tray notification on the desktop with a participant. If you want to read more about what we found out while we were at Kscope, you can read our blog post which we updated at the end of each day.

Team Collaboration

When I had slack time, I would go through the feedback with David, the developer who was working on an HTML/CSS interactive prototype. I found it hard to provide regular feedback to David as often feedback sessions were back-to-back. We found people skipped conference talks and drifted into the exhibition hall throughout the day and I didn’t want to miss opportunities to talk to potential customers. We had stand up meetings between sprints with the rest of the team and updated the Kanban board to show progress on tasks. Sometimes our stand-ups were watched by people who arrived at the stand at that point! The whole team had to wear multiple hats. We all did product demos of our existing Oracle tools, spoke to customers, got feedback on the prototypes and did coffee runs.

The Dev Area

Whilst I was running feedback sessions, David was working away on creating and updating the HTML/CSS version of our Source Control for Oracle prototype. We wanted to show more complex interactions and the paper prototype could only go so far to showing how the tool would work. We used Twitter’s Bootstrap for the UI components. Bootstrap provides ready-made buttons, icons, tables and much more, meaning that we hardly had to write any custom CSS. We also used Knockout to make it interactive. Knockout’s simple framework made it quick and easy to add features such as the search-as-you-type filter. David’s screen was displayed on the large monitor in the middle of the stand, so passing traffic could see him coding live. This certainly attracted some of the developers to our stand! We didn’t get to do as much testing with the HTML version of the prototype as we’d hoped. The paper version was still much quicker to update. But by day 3 we were testing it with people and getting feedback.

The Outcome, and What’s Next

Over 92% of people we spoke to said they would purchase our tool, which was meant our hypothesis was well and truly validated! We had some amazing conversations with potential customers and gathered some great feedback on our designs. The project team is now working full speed on development. I’ve got some time to reflect on running a Live Lab and will be posting up some lessons learned here on the UX team blog in the near future. I’d love to know what you think about our Live Labs case study! Please do get in touch if you have any experiences you can share from doing UX research, design or evaluation at a conference or tradeshow.

Terrible Form Design: How Many Mistakes are Possible in Just Two Steps?

Stephen Chambers — Sun, 01 Jul 2012 18:20:58 +0000

I recently came across 2 examples from the same online form that highlight a case whereby the person implementing the content doesn’t necessarily mean they are the people who should be designing it. I’m going to assume that’s what has happened in this case. It’s the most likely answer.

Designing the information on a form is basic questionnaire design in most cases but it’s something that rears its head time and time again and which people frequently get wrong. I thought I’d share these delights of design with you to highlight just how wrong it can be.

First up – the well travelled and often impossible to mess up ‘New User’ registration step…

I’m not sure I even understand the text which accompanies the example above.

Now for the delight that was Step 2 in the process – the security question step that’s often used to help password recovery:

An Open Ended Security Question the User has to Create!

I especially like the security question example. When almost every other form I’ve come across in the world has a pre-set number of questions for the security question in a combo box (which can’t be edited), they leave the user to write their own. It requires extra validation, allows for incomplete or non-comprehensible text to be entered and it’s just… stupid. Given the small length of the text field itself – it was going to have to be a very short question. The addition of the helpful text “The answer must contain at least 1 character” really rounds it off with a laugh.

What was the question going to be? Is the user going to get philosophical when getting to this and write ‘what’s the meaning of life?’ as the security question with a blank gaping text field underneath it to demonstrate the philosophically expansive and endless possibilities of answers? Given the field was mandatory in the first place I think it’s safe to assume there would have to be at least 1 character in there.

So, before sending out a questionnaire or creating a form– please have it checked by someone with experience in creating this type of content. It’s often presumed that anyone can create a questionnaire but nothing could be further from the truth. In examples I’ve come across, or created myself, it can be easy to get it wrong. There’s the chance of broken logic, ambiguity of question text or its responses, misuse of scales or question controls to name just a few. Before sending out your next questionnaire, make sure to ‘usability test’ with the target audience as a dry run. Test and iterate until you are satisfied that the questionnaire is both asking the right questions and in the correct way. These will help identify problems in its content or format and lead to much more robust data.

I stopped going through the process, so the vendor has just lost out on potential business and left me with a negative opinion of the company in general.

A/B Testing desktop applications

Tom Randle — Tue, 26 Jun 2012 14:52:45 +0000

A/B testing websites and web applications is relatively straight forward. Tools like Google Optimizer (now part of Google Analytics) make tests easy to set up, and changes can be deployed without much hassle.

Things are much harder if you want to run a test on a desktop application:

There are no off-the-shelf tools to help.
Changes are installed by the user, not deployed by the development team. This means you’re reliant on either existing users upgrading their software or new users installing it for the first time for your changes to become public.
Users don’t expect their software to change without first installing a new version. Users also have to be given a reason to upgrade without jeopardising the test. Once the test has finished you can’t just switch everyone over to the winning design without another update.
Users are more sensitive about data being sent back from desktop applications than websites. You therefore have to ask their permission first, and this reduces your sample sizes.
The types of conversion being optimized for are often harder to affect. There’s a big difference between optimizing a sign up form and changing the functionality of an application.
Data volumes tend to be smaller. Once a user has downloaded and installed your application they’re already quite far down your conversion funnel so tests will take longer to run.

However, A/B testing desktop applications is still possible! We recently ran a month long test on one of our .NET Profiling tools. The test itself was a failure, our new design was not an improvement, but we were able to establish a procedure for running experiments that worked.

To avoid changing the application under our user’s feet we decided to only show the test to new users and did not upgrade existing ones. This made particular sense in our experiment as we were trying to optimize the experience for new users.
To show our users different versions of the application we chose to keep a single build rather than a separate one for each test. This reduced our build overhead, kept things more maintainable and meant that if necessary our support team could help users switch versions. Our download server tagged each installer with a random number and during installation this added an item to the registry telling the application to show either version A or B.
To track events were able to use our existing feature usage reporting. All we needed to do was decided exactly what we wanted to track. This gave us the raw numbers we needed that we could then perform significance calculations with.
To save time, as our changes were only minor, we chose not to update any documentation or screenshots.
To overcome any data privacy concerns we explicitly asking the user’s permission to send back usage data.

The only major problem we were unable to resolve was the low volume of data we were able to collect. Only around 12% of users opted to send back feature usage data, resulting in only 5 new users per bucket per day. This meant that in order to see significant improvements in a reasonable amount of time our new design would have to be substantially better.

Of course, this problem isn’t unique to desktop applications, and the remedy is fairly simple. Either run your test for longer, get more users to opt-in, or make bigger changes. If you’re application is anything like ours don’t expect to test every little detail – save A/B testing for dramatic design changes.

Failing to optimise a product page for downloads!

Tom Randle — Fri, 18 May 2012 08:16:47 +0000

I recently worked on a short project to try and optimise sales of one of our products. This isn’t something we’ve tried very much of in the past. We run occasional A/B tests on the website but they’re usually to optimize marketing campaigns or sign ups.

We typically develop our products by working out from user feedback, competitor analysis, market research and innovations from the team, what we could to improve the product. To a certain extent, we trust that doing the ‘right thing’ (improving the user experience or functionality of the application) will ultimately improve sales.

We spend a surprisingly small amount of our attention on the trial / download experience. In this project we decided to try a slightly more cynical approach; could we earn the company a lot more money by tweaking a few things here and there? Were there any choke points that we could remove that would suddenly increase downloads and subsequently sales?

We kicked off the project by first trying to identify all the touch points in our existing evaluation and sales processes. These ranged from marketing campaigns, product pages, download forms, installers, sales contacts, automatic emails to the actual product itself.

After gauging the relative importance, potential upswing and effort required we decided to focus our efforts on the product page and using the application for the first time. Here I’m just going to talk about the experiment we ran on the product page, but we’ll write about the application A/B test in the future too.

Our product pages are the bread and butter of our website. They’re the gateway to finding out about a product, downloading it and ultimately buying it. They receive over half the page views and are where we invest the vast majority of our effort.

Our existing product page – April 2012

Despite that, we felt that the main indexes for each product look tired, failed to provide a quick overview of the product, and didn’t prioritise the information very well. We thought with a bit of love we’d be able to freshen up the design, increase downloads, promote our other products better, improve the information design and reduce the maintenance overhead by removing extraneous content.

Our proposed new product page, with re-prioritised content, simpler layout and sticky nav bar.

We were wary that some A/B tests tried in the past had had no measurable impact, so we decided to go all out and try a radical design for our first iteration. We decided not to worry about consistency with our other product pages. If the page was a resounding success then perhaps we’d update all our other pages or tone it down, if it failed then we could just throw it away. The metric we decided to track in the A/B test was Downloads – how many people clicked the download button and then successfully filled out of the form. We’d have loved to have tracked the funnel right the way to the end, to see whether users who saw A were more likely than those who saw to buy B, but couldn’t due to low data volumes and potential privacy issues.

We kept an eye on other metrics too, including adding to cart, but were less concerned by those as the decision to buy our products is predominantly influenced by the evaluation experience, rather than the product page itself.

Before running the test we had no benchmark conversion rate and we had no idea what kind of uplift to expect. This made working out how long we needed to run the test to observe significance rather difficult! (It’s important to decide how long you’re running the test up front and not stop as soon as you A/B testing tool tells you the improvement is significant as this can lead to false positives. Read Evan Miller’s article if you want to understand the maths behind this.)

In the end we settled upon 2 weeks. This turned out to be too short and the test failed to reach significance. There was an observed improvement of around 10%, but as we’d not reached significance this could easily have been noise. We’d underestimated the existing conversion rate (~19.5%) and overestimated the effect of our ‘improvements’!

We therefore decided to run the test again after revising our calculations for working out how long we’d need in order to reach significance based on the observed results of the first test. This time instead of setting a time, we decided to stop the test once 4000 people were in each bucket – this turned out to take about 4 weeks.

The results second time round: no significance at all. In fact the new design was observed to slightly under perform the old one. We were shocked! We’d have been less surprised if the new design had decreased conversions than for it to stay completely unchanged.

Our final Google Optimzer results. While it looked to begin with as if the original might out perform our new page, the lines converged over time.

What we think this probably implies is that users arriving on this page have already more or less made up their mind whether they’re going to download or not. The number of people clicking download is already very high (~30%). There’s a fairly large drop off on the next page but still nearly 20% of users arriving on the product page end up downloading.

Average time on page did go up from around 45 seconds to 2 minutes. It’s probably unwise to read too much into this though as it could simply be a symptom of moving to a single page design rather than increased engagement. Clicks through to the shopping cart decreased, although in the new design, nearly a third of the clicks were for the bundle instead of just the standalone product.

So what did we conclude and what do we do next?

We still think there’s plenty of scope for improving our product pages. This just wasn’t the right page in the funnel to try and increase downloads. If that was our aim we’d have been better directing our efforts on marketing campaigns or the download form. However, we’re sure we can still improve our customer’s experience, better promote other products and reduce our content overheads with a better product page.

We’ve taken the new page down for now, but we’ll use what we’ve learned when we revisit them again in the future. Next time we’ll focus on improvements for our users and just use A/B testing to make sure we haven’t in advertently caused conversions to plummet!

If nothing else, this was a useful exercise to show that tweaking our product pages isn’t suddenly going to double sales. It’s also made me even more sceptical of the tests posted to sites like whichtestwon.com.

Computer Says No – A Down Tools Project

Jenny — Fri, 04 May 2012 16:22:36 +0000

Down Tools Week (DTW) happens every three months at Red Gate. It is a chance for everyone in the office to put their day-to-day tasks to one side and work on their own projects. Some people choose to put their headphones on for five days and learn a new skill such as Photoshop, CSS or a new programming language. Others present their brain child at the DTW Hustings, a session organised about a week before Down Tools so that people can present their ideas and sign up willing recruits for their project team. Projects that have recently come out of a Red Gate DTW include SQL Tab Magic, SQL Data Masker, a marketing project for UI Sketch, a 404 page and Page Trawler, to name just a few. If you’d like to know a bit more about DTW at Red Gate then you can also watch this video. A team of two (but not for long…). The most recent DTW happened from the 26th – 30th March. Jonathan Watts, one of the Testers in my day-to-day project team (and Head of Test at Red Gate) had a particular problem he wanted to resolve: he wanted a better way to process the completed assessments that come in as part of the Red Gate recruitment process. The current workflow for processing these applications is rather laborious, and consequently in dire need of a makeover. So, the UX/ Tester team of two set out to recruit some helpers for a new web-based assessment processing system, with help from a Popplet illustrating Jon’s ‘Workflow from Hell’.

The existing Hiring Manager workflow for processing assessments

The birth of ’Computer Says No’: a new web-based application system for Red Gate. Meanwhile, down on the ground floor of Red Gate Towers, Bart Read, Head of Technical Recruitment, had hatched a similar plan to ‘Kiss goodbye to CVs and cover letters’. Having stumbled upon our mutual recruitment process interests at the Hustings, we decided to join forces. Little did we know that we were about to create a monster! Having assembled an army of fourteen people we embarked on a project to revamp Red Gate’s recruitment process; a project christened by Bart (in true Bart style) as ‘Computer Says No’. Out with the old and in with the new. The current process for applying for a job at Red Gate has several steps and starts with the candidate viewing the vacancy, clicking on the ‘Apply now’ button, filling in a form, uploading a CV and cover letter and then submitting the form. After the form is submitted the recruitment process has several stages, as shown below. First impressions count: a new UI for Red Gate job applicants. My role as the UX person was to design the UI for the new web-based application system. The aim for the new recruitment process was to create a workflow in which all applicants complete assessments at the first first stage of the process. Applicants that are successful at assessment stage will then be asked for their CV. We started off planning this workflow as a team; firstly to discuss what was possible in five days, and secondly to highlight potential issues with the workflow early on in the process. By Monday afternoon we had already started work on the new designs, which were implemented by the Developers as we went along. After clicking ‘Apply now’ the new UI will take the candidate to a web page where they can create a new application. The candidate can then log in to and complete this application over a period of time. After creating or logging into an application the homepage shows all the tasks that need to be completed before submitting. We thought this would be a useful way of providing the candidate with good visibility of the tasks that would need to be completed before their application could be submitted. When each task has been completed its status changes accordingly, and the candidate will not be able to submit the application without completing all the exercises on their application homepage. As part of the design process, we also updated the Bug Hunt exercise that the Test candidates have to do as part of their assessment. Previously, candidates had to play with a small calculator app for 10 minutes, note down any bugs they found on a piece of paper and then email the list of bugs to Red Gate in a Word document. The new process enables candidates to play with the calculator app for 15 minutes, whilst entering bugs on the web-page via a ‘bug stream’. When the 15 minutes have expired, the application will stop working and the bugs will be automatically submitted to our system for assessment. Some lessons we learned. 1) We should have done a lot more planning at the beginning. The fact that we had only five days to achieve our goals meant that we launched onto the project like bats out of hell. On hindsight we think we could have saved a couple of days of Dev time if we had planned how all the various parts of the system linked together. For example, we came up with the diagram below as the project went along, when we should really have done it at the beginning! 2) Developers lose quite a lot of hair if UX/Tech Comms sit next to them for too long. Despite Marianne (Tech Author) and I feeling like nagging wives for a good bit of the project, I think we all saw the benefit of pair (or sometimes trio?) programming. Designing alongside the developers as they were developing improved efficiency, helped maintain the integrity of the designs and allowed us to address any problems on the spot as they arose.

Tech Comms and UX vs. Dev!

3) It’s difficult to get an exact match between the design and the final implementation The biggest lesson for me was that it is more difficult than I thought for a design to be implemented from a mock-up, pixel by pixel. For example, sometimes design elements just don’t want to line up, despite the best efforts (and loss of hair) of our developers! Hats off to them for putting up with my nit-picking for a week!

The calculator and bug stream would not be resized to line up with each other!

Next step: Tying up loose ends. We took on a monumental task this DTW but with such a large team we managed to make a large dent in the process of improving Red Gate’s recruitment process. It will take a while to see the final version of the designs live on our website, with the resourcing on the project having gone from a team of 14 during DTW, to what is now effectively team ‘Bart’. For now, we have removed the idea of creating an account, in favour of getting some of the material and concepts live on the website. So far, the concepts have been introduced only to the Software Engineering vacancies. This will allow us to gather some data and feedback on the effect the overall concept is having on the recruitment process, before spending time on the final, polished version. Possibly a project to resume during the next DTW!

Consulting the past

Adam Walker — Tue, 24 Apr 2012 05:44:16 +0000

Bill Buxton kicked off UX London 2012 with a talk on ‘Long noses, sampling, synthesis, design and innovation’. What I found most interesting about this talk was his view that good designs don’t come from alchemy, but from prospecting. The idea of a lone genius designer with profound powers of invention is a myth – innovation comes from mining and refining ideas that are already out there. He gave the example of the Rolling Stones’ Keith Richards who, when inducting Chuck Berry into the Rock and Roll Hall of Fame in 1986, said

“It’s very difficult for me to talk about Chuck Berry ’cause I’ve lifted every lick he ever played”

Hell, even the band name wasn’t unique but tweaked the title of a Muddy Waters song. This ‘lifting’ of other peoples work is mentioned often in music. Earlier this year, Bruce Springsteen in his keynote address at SXSW referred to the Animals ‘We Gotta Get Out Of This Place’, saying

“That’s every song I’ve ever written. Yeah. That’s all of them. I’m not kidding, either… everything I’ve done for the past 40 years, including all the new ones”

Bill suggested that even in art, the genius inventor is a myth and often they work more like architects, with many people working towards the design; Rembrandt had a studio of artists around him who cut their teeth copying his portraits, likewise Andy Warhol had his studio ‘Factory’ where an assembly line of his famous silkscreens were produced. That creations are more often than not iterations of existing ideas is a frequent theme in literature too; even a quote about that very thing has been adapted many times

“Talent may frolic and juggle; genius realizes and adds” – Ralph Waldo Emerson “Immature poets imitate; mature poets steal; bad poets deface what they take, and good poets make it into something better, or at least something different” – T.S. Elliot “Talent borrows, genius steals” – Oscar Wilde

Bill showed a very persuasive example of this in Apple’s prospecting of a design idea from Kodak’s Vest Pocket cameras. Seeking to broaden the camera’s market appeal, particularly to women, in 1928 Kodak released a version of the camera in 5 different colours, where previously it had only been available in black. In 2003, when Apple wanted to expand the market for its iPod, it too released the product in 5 different colours. The same colours. “That was no accident”. In his article for Businessweek.com What Apple Learned from Kodak, Bill explains:

“What Apple did was learn from history, and adopt, adapt, and assimilate past success to current context. That is simply good, intelligent design in action. It is also a very good lesson: an obsession with the new and original, without a deep literacy and appreciation for the past, leads to a path of missed opportunities.”

He even suggested this as an antidote to the ‘woke up this morning…’ blues designers sometimes face – hungover, stressed by the project, hating the client – yet proffesionalism demands that we do fantastic designs regardless. In these situations we can draw from history.

Wise men say, and not without reason, that whoever wishes to foresee the future must consult the past

. If you’d like to find out more, here are Michele Ide Smith’s Sketchnotes of Bill Buxton’s Talk

UX London in sketchnotes

Michele Ide-Smith — Mon, 23 Apr 2012 06:48:16 +0000

Last week our UX team were lucky enough to attend UX London 2012 for three days of inspiration, learning and networking. I’ve been practising sketchnoting (aka visual notetaking) since UX Cambridge last year. Here are my sketchnotes of most the talks and workshops I attended at UX London (also available on Flickr).

On Long Noses, Sampling, Synthesis, Design and Innovation, Bill Buxton (keynote)

The crux of Bill’s talk was simple – no idea is original. Designers are constantly influenced by what has gone before. To innovate, designers should reference existing designs that have proven successful and follow an iterative process to refine design ideas using techniques like sketching, prototyping and user centred research. He showed many examples of how product design in the past has influenced and shaped successful digital technology products such as the iPod and iPhone. For detailed text notes of Bill’s talk see Luke Wroblewski’s notes or Jon Kolko’s notes.

Learn to Play UX Rugby: Why your agile UX adoption is failing and what to do about it, Anders Ramsay

Anders stepped in at very short notice to replace Janice Fraser, who couldn’t make it in time due to a delayed flight. He talked about some methods which designers can use to work more effectively in Agile teams. For example design pairing, where designers develop and try out multiple design ideas collaboratively with developers or other designers. And user Fridays, where no matter what stage at development a team is at, users are always brought in on a Friday to get regular feedback on design concepts and prototypes. For more detailed text notes of Anders’s talk, see Luke Wroblewski’s notes or Jon Kolko’s notes.

Luke Wroblewski, ‘Organising Mobile Web Experiences’

Luke provided some excellent insights into how mobile design patterns are evolving. He covered the importance of considering context of use and the ergonomics of smart phones (e.g. the comfortable ‘reach’ for your thumbs when holding a smart phone at the bottom). Luke advised designers to think ‘mobile first’, a similar concept to designing for top tasks or red routes, which requires designers to strip away content and functions to the most useful / frequently used. For more detailed text notes of Luke’s talk, see Jon Kolko’s notes.

Kristina Halvorson, ‘A Content Strategy Roadmap’

Kristina talked through a practical framework for managing content-led projects. She explored content roles and responsibilities, tools and techniques to ensure project teams don’t get ‘burned by content’ (an experience that many of the audience had been through). For more detailed text notes of Kristina’s talk, see Luke Wroblewski’s notes or Jon Kolko’s notes.

Mobile and UX, Inside the Eye of a Perfect Storm, Jared Spool

Jared’s talk was very entertaining. Starting with Sturgeon’s Law which states that 90% of everything is crap, he asked the audience “Are your designs in the other 10%?”. Jared covered various examples of how experience design can delight users, but warned that expectations change over time and delighters can become basic expectations. Therefore understanding and considering context of use is vital. Being a User Experience Designer requires us to develop a vast range of skills and methods. Jared ended with three simple questions to ask your team:

What will the experience of your design be in 5 years?
In the last 6 weeks, have you spent 2 hours watching users use your design?
In the last 6 weeks, have you rewarded a designer for a design failure?

For detailed text notes of Jared’s talk see Luke Wroblewski’s notes or Jon Kolko’s notes.

The Next Step for Design: Social Entrepreneuship, Jon Kolko

For me (and many other delegates, judging by the response afterwards) Jon’s talk was an inspiring and energising end to the first day. Jon established the Austin Centre for Design and teaches design and social entrepreneurship techniques and skills. He discussed how designers can solve ‘wicked problems’. He urged the audience to leave the organisational machine behind and use their design skills to develop and pursue innovative business ideas in order to solve complex social and humanitarian problems. If you are interested in this topic, Austin Centre for Design have a free book called Wicked Problems.

Methods of Design Synthesis, Jon Kolko

Following on from the previous day’s talk, Jon’s workshop was fast-paced and fun. We covered a huge amount of ground in 3.5 hours (2 week’s worth apparently!). Although I was familiar with much of the content of the workshop the one real stand-out technique for me was what Jon referred to as ‘Insight Combinations’, a way to match insights from contextual or ethnographic research with design patterns, to develop design ideas.

Design for User Experience Workshop, Dan Rubin

Although I found Dan’s workshop a little slow, compared to the morning workshop with Jon Kolko, there were some useful takeaways about working with Visual Designers.

The Quest for Emotional Engagement: Information Visualisation, Stephen Anderson

Stephen’s talk highlighted the risks of using well worn design patterns and questioned if they help make sense of complex information. During the workshop he walked through a practical way to analyse data points and the relationships between them. He then demonstrated how to develop interactive information visualisations which make sense of data and invite engagement.

UX Team of One Bootcamp, Leah Buley

Leah’s workshop was idea for those working in teams or organisations where they are the only User Experience practitioner. She provided some tactical and persuasive tips for winning over colleagues. She also ran us through some practical techniques which encourage team collaboration and buy-in. One technique which I found particularly useful, and hadn’t heard of before, was the UX Health Check-up - a framework for analysing product quality over time.

Sketchnotes from a talk by Peldi from Balsamiq

Michele Ide-Smith — Tue, 17 Apr 2012 10:23:55 +0000

This week Peldi from Balsamiq visited Red Gate. I’m an avid fan of Balsamiq Mockups. It’s a very simple, sketchy wireframing tool which our team uses a lot for early designs and wireframes. At lunchtime Peldi gave an excellent talk about the importance of listening to your customers, based on his own experiences of starting developing Balsamiq and starting his company. Here are my sketchnotes of Peldi’s talk: