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!

 

“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

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:

1. What will the experience of your design be in 5 years?
2. In the last 6 weeks, have you spent 2 hours watching users use your design?
3. 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.

The release of Ad-Aware 10

I have used a malware removal product called Ad-Aware by a company called Lavasoft for a number of years. I recently purchased a copy and was informed that I would also be given a free upgrade to the upcoming version 10 when it was released. Sure enough, an email arrived in my inbox a few days ago informing me it was now available and I could download it.

What I found interesting about the email was their focus on a key new feature in their description of the product:

“Discover Ad-Aware 10’s newly designed interface, better protection and powerful new features”

Design before features? Surely not.

It didn’t stop there. Immediately below the initial pitch was another advert of its number 1 new feature:

Focusing on the UI: The Ad-Aware Email Advertisement

I have to say that I was pleasantly surprised by this and I’m always curious to see the difference a company can make by performing a radical overhaul of their product when there’s a new major release. Given the current state of version 9 (shown below), it was certainly due a major overhaul:

The Ad-Aware Version 9 UI

I’m going to actually ignore what they have done with the new UI as dramatic as the change may be. There are quite a few reviews of the new release and one reviewer comments that:

A big reason that the new Ad-Aware stands a good chance of surviving is because it’s finally a usable product again. (CNET review)

The Ad-Aware Installer

For this post I want to focus some attention on the new installer for Ad-Aware 10. Many companies opt for standard installers that are generic in their appearance and the way in which they work. With version 10, Lavasoft have gone for a simple but highly customized install experience and for me it is one that works pretty well (although not perfect).

The first thing is that it was no fuss and obeys all the standard recommendations that creating a process like this should have. An installer is essentially a ‘wizard’, i.e. a small UI mechanism that guides you through a one off process. It typically involves a small number of steps, requiring little input from the user and an indication of progress during the longer stages such as downloading and installing for example.

Design and branding

One element of the install experience that struck me was the consistency of the company and product branding. The choice of clean white contrasting with the use of black and orange really stood out. The consistent visibility of the product name and the company name throughout the process were very pronounced and it felt designed. As it turns out, this style of design persists through to the actual main UI of the product and is even used on their website. From my use of version 9, all I remember is a slightly horrible blue colour everywhere.
You begin the install process by selecting your language preference so it’s a 1-click process and differs from the more typical treeview approach showing 30 different language choices. The design is clean and modern with a strong visual impact without being overpowering. Using large buttons are quite nice too.

Choosing which language to install

The next step is quite standard with install folder and license agreement combined to cut down on the number of steps required.

Selecting Install Location and EULA in 1 Simple Step

They maybe could have given an indication of the exact number of steps involved in the install process but that’s a small quibble.

Advertising new features and reducing the perception of time to install

The second most noticeable element however was the use of a rotating carousel advertising the new features as the application is being installed. I’ve seen some examples of images popping up during the install process to advertise features of the product before. I’ve never seen the use an animated carousel with supporting text that faded and reappeared in perfect synchronization as each icon, representing a category of feature, moved to the front. It was rather… umm… cool.

I’ve tried to capture the process below with the first feature being displayed:

The Rotating Carousel: Highlighting Key Features

Next you can see the carousel in action with the text fading as the rotation happens to the description of the next feature with the new icon also taking its place.

The Rotation in Action: Smooth Animations with Synchronized Text Changes

As is consistent with the display of each feature category, you can see the Antivirus feature being displayed with simple bullet points to the right highlighting the top 3 features. The use of different icons also gives a nice visual appearance to separate out each feature category. Then it’s a simple matter of rinse and repeat.

The Carousel Showing the Next Key Feature Set

So what’s the point of this? As well as being a nice visual feature with really slick animations – it keeps your attention while the product is being downloaded and installed. This distraction makes time feel that it goes just that little bit quicker. It’s a nice distraction because it feels the download process was fast and I also benefit from its design by learning about the top features I can take advantage of. It’s also different in its implementation from probably every application I’ve installed before it.

Their attention to detail from the very beginning sets the tone for the rest of the evaluation experience. When you launch the application after install (which was very lengthy unfortunately), the consistency in many of the UI elements serve to link everything together in a way that isn’t often half as effective with the implementation choices of other companies.

The game

We used one of our own processes as an example to work with. This process involves emailing existing users of one of our products, asking them to visit a webpage to download the latest update. They would then be required to enter their name and email address to proceed. On the face of it, emailing users and asking them to then enter their name and email address seemed an obvious example of a bad user experience and one we should change. But while there were plenty of reasons for driving that change, Force Field Analysis also revealed the restraining forces – reasons for maintaining the status quo.

Having chosen the example to work with, each member of the group wrote down on post-it notes as many reasons as they could think of for driving the change. Obviously, the bad user experience was mentioned by many, but other reasons included consistency with other update processes which didn’t require user’s details and that the process might harm uptake.

We then spent 5 minutes writing down the reasons against change. For example, the process could be seen as a way of validating the email list and of tracking exactly who had downloaded the update. At this point I was surprised just how many different reasons against change were thought of, and how persuasive some of them were.

We then grouped the post-its so that, for example, any comments around bad ux were grouped together. We discussed the reasons for and against change and this had proved to be an insightful experience. It was clear that the user experience wasn’t the only consideration, and other forces were acting on the decision.

Highlighting the pros and cons doesn’t always lead to a resolution though, so at this point we allocated points to the groups relative to their strength of force – 1 for very weak to 5 for very strong – and totalled them to identify the strongest forces. By totalling the strengths we also had hard numbers to base decisions on, but we could see how these numbers could give undue weight to less critical but more numerous issues. One tip suggested was to focus on the bigger arrows, reducing them to find consensus or rank the force-field top down with stronger forces at the top and light forces at the bottom – sometimes (some) opposing forces can be paired up and ordered in pairs.

Summary

This game seemed like a useful technique to use where it was difficult to find consensus, and reassuringly the forces for change were stronger for our example.

The game seemed most effective as a technique for revealing opposing forces and encouraging the group to discuss and acknowledge the relative strengths. A change which seemed obvious from one point of view was far less clear cut when seen from another with the restraining forces. However, the force fields can be dynamic, so increasing the strength of driving forces could affect the strength of restraining forces and vice versa. It’s certainly a game that encourages discussion rather than one that decisively answers a question of whether a change should happen. It’s also an excuse to use phrases like ‘the force is strong with this one’, never a bad thing.

Recently I came across two apps that particularly impressed me with their quirky brilliance.

The first, Fingle, is a bit like Twister re-imagined for the iPad. It’s incredibly suggestive, and borderline dirty, but it oozes personality. The clever game play, distinctive orange graphics and provocative sound effects make you feel naughty (in a good way!) playing it. It’s most certainly a conversation piece.

Fingle Gameplay Trailer from Game Oven Studios on Vimeo.

Scorekeeper meanwhile takes a simple concept but executes it superbly. The 80s inspired, text-less UI, does nothing more than let you keep a score. Its charm is all in the details, the subtle animations and graceful interactions. It has an incredible feel of quality and it’s so much more fun than that scratty bit of paper, Biro and erratic arithmetic we’re all used to!

Interfaces don’t always have to fade away, personality can be good!

Last week we tried out the Challenge Cards game. The object of play is described in Gamestorming as:

To identify and think through challenges, problems and potential pitfalls in a product, service or strategy.

If you haven’t already got the Gamestorming book I’d highly recommend going and grabbing yourself a copy, or getting the iPhone app or Android app for handy reference on the move.

The game involves two teams: a ‘solution team’ who brainstorm the strengths of the product or service and a ‘challenge team’ who brainstorm problems or challenges. Each team writes the ‘solutions’ or ‘challenges’ on index cards.

Some of the challenge team’s cards:

And the solution team’s cards:

The real value of the game comes from the fun part, which is when the teams play their cards together. This competitive but collaborative aspect of the game results in rapid idea generation about user needs, problems and context of use and the potential solutions or features which can make the product or service work well for users. There is a form of points allocation, which I’ll explain more about later.

When we tried out the game we decided to use a fictional product idea, which was:

A mobile phone app to manage book appointments with your GP, communicate with your GP surgery and get test results

The benefit of using a fictional product idea was that we didn’t get hung up on internal challenges or focus on one particular product. We are all from different teams, working on different products. So we avoided a situation where one or two people were very familiar with the product, but others in the group weren’t.

We had two teams of 4 and 5 people respectively.

There weren’t any timings specified in the book, so we decided to use the following timings:

• Introduction – 5 mins
• Product / service definition – 5 mins
• Brainstorming – 10 mins (this felt a bit long)
• Playing cards – 20 minutes (we could have done with longer)
• Discussion about the game – 15 minutes

The main things we learnt about playing the Challenge Cards game were:

• The game is great for initial idea generation about a product or service.
• It’s good for getting creative juices flowing and great for coming up with multiple solutions and possible risks or constraints.
• The ‘game’ aspect prevented us getting hung up on personal gripes.
• Because the game has a ‘challenge team’ it’s actually a really positive way to deal with people who tend to be very negative in workshops and brainstorming sessions. Play to their strengths by putting them on the challenge team!
• Both teams were working to a shared outcome.
• It’s a good way to get people involved who are less confident about having a say.
• The game would work well for people who are fresh to the product.

Some of the more practical things we learnt about playing Challenge Cards were:

• Each team should use different coloured index cards! We quite quickly realised we couldn’t visually distinguish the cards on the table.
• You need a big table to lay the cards out on, or alternatively stick them up on a wall (you could use stickies for that purpose but we felt that the feeling of slapping the cards down on the table added to the game play).
• The facilitator should just do facilitation and not attempt to be part of a team.
• Some of the cards can be too general, particularly the ‘challenges’ and could be played on multiple occasions.
• It’s hard to award points to the teams when the problem seems very wide e.g. “I have no service / network coverage, I can’t access the info when I need it”.
• Teams can get very competitive about points allocation and as the facilitator I quite quickly found I was being challenged about whether I’d allocated points fairly! When you pair up the challenge and solution cards it would be useful to write a reference number on them or find some way to cross-reference the cards with points allocated on the scorecard.
• We wanted to keep writing on the cards – the facilitator needs to lay out clear timings.
• We could have done with more time.
• We needed a follow up session to discuss some of the problems / solutions in more detail.

If you have experiences of playing the Challenge Cards game, do let us know if you have any other tips for good game play!

As UX practitioners we spend a lot of effort into engaging users early on in their experiences with our products. Where does their experience end though? When should we stop attempting to engage them? Earlier this week I attempted to uninstall an application called Soluto and was pleasantly surprised by the experience.

Instead of the usual Windows uninstall wizard Soluto presented me with a customised dialog (shown above) giving me a choice of uninstalling or keeping the application. As I moved my mouse cursor towards the ‘Uninstall’ button the computer got sad:

Moving my cursor towards the Keep Soluto button cheered the computer up:

As well as putting a smile on my face, this got me thinking. It’s interesting that the team at Soluto decided to put some effort in here; at a stage when someone has already made the decision to uninstall the application and then gone to the trouble of reminding themselves how to do this.

I’d love to know whether this was a response to large numbers of users uninstalling. If so was it worth the effort? I wonder if it has had a significant impact on the number of users who uninstall the application. The whole application has some really nice design touches (read more about it on the Soluto blog) and they clearly think that their is value in providing a unique experience even at this late stage.

Anyway, here are a few of UX Yoda’s best quotes so far:

• Strive for “better” not “new” and innovate you will.
• User error it may be. But your responsibility it is.
• Drawing conclusions from data without first understanding that what drives your users. A path to the dark side this is.
• A UX team your entire company is.
• Waterfall, agile. These things mater not. Focus on product not process.
• Powerful is a product that does one thing well. Like Death Star yes. Mmmahahmmm.

Somehow this kind of zen like, slightly inane advice seems more palatable when it comes from Yoda’s green lips instead of Seth Godin’s!