Posts Tagged ‘ux’


Getting user feedback into the backlog

by Sasha Ward

As UX designers we are always aiming to balance the needs of the user with the requirements of the business and with what’s technologically feasible.



A key element of this is understanding and addressing the user needs, which can be done by talking to them, testing prototypes with them and giving them the opportunity to give feedback.

Within large product teams, the likelihood is that there will be an abundance of feedback collected from a range of sources, which is great as feedback from our users is essential to creating products people want and can use. But what do we do when this feedback is scattered across a team of 40 or 100 people in multiple teams? How do we get the generic feedback that isn’t directly related to a current piece of work, back into the backlog?

In this post, I will run over the types of feedback that you can get from users and give you a framework that can help you turn this data into small pieces of work.

What types of feedback are there?

Firstly, I just want to clarify what we mean by feedback and how we categorise it. When I talk about feedback I am referring to any kind of response that happens as a direct result of a user using a product.

We can separate the feedback we get from our users into two categories, qualitative and quantitative feedback/data.

Qualitative data – Insights in the form of opinions, feelings and behaviours (e.g. “I didn’t expect that to happen when I clicked there, I feel slightly disorientated”). Usually gathered through observational research methods that require some form of direct communication with a user and used to help to define a problem or to explore an idea/concept. These kinds of insights are generally harder to get hold of as it requires more effort to gather. However, there are a number of ways to find these insights whilst still keeping your process lean, here are some examples:

  • Cafe/Guerrilla testing
  • Feedback forms
  • Social media channels (twitter, Facebook)
  • Reviews (trip advisor, app store)

Quantitative data – Insights that can be depicted by numbers (e.g. 80% of users bounced on the signup page). These sorts of insights are gathered through measurement methods including surveys and analytics tools. We often use quantitative research methods as a way of quantifying a problem, in order to validate its severity/prevalence. (1)

So…how do we turn all this data into something that we can actually work on?

1.Firstly, gather all your data in one place

Round up all the data that you have, this includes data from analytics tools and comments from user testing. All the most recent feedback that you have. (Grab some post-its too).

Ensure the data is summarised in a bite-size format with one insight per post-it, focussing purely on observations with no solutions at this stage. This is important as the purpose of this exercise is to translate random pieces of data into actionable pieces of work, therefore it’s essential that the data you have is in a short, simple language that you can communicate easily to the rest of your team. Find a large wall that you can use to pin up your data and then gather your team.

2. Secondly, identify themes

What you’ve got so far is a big pool of data, and in order to have something actionable and the end of this session what you need is some way of filtering down this data.

A great way to do this is by affinity mapping (sorting into groups) this data/feedback. As a group, sort the data into similar categories and name each category once all the data has been categorised.

3. Thirdly, write user stories/actions

Once you’ve got your main themes, you can then begin to write actions based one each of the themes. The most likely output from this would be user stories but it most certainly isn’t limited to this. It is likely that the data you have gathered might provoke more questions that require some form of validation, therefore a user story that is purely focussed on exploring or experimenting might be another great outcome from this exercise.


Here’s an example of a space we helped create, where we gathered insights, identified themes and created actionable user stories.

4. Last but not least, prioritise within the backlog

With the Product Owner or whoever organises each team’s backlog, go through the user stories that you have created and prioritise these alongside the other work that is the backlog. There are a couple of ways you can do this:

The MoSCoW (Must, Should, Could, Would) method whereby you gather the user stories that you have created and vote on which category each story falls into. Differentiating between each category is vitally important, I find using these definitions a great starting point:

Must – are features that must be included before the product can be launched.

Should – are features that are not critical to launch, but are considered to be important and of a high value to the user.

Could – are features that are nice to have and could potentially be included without incurring too much effort or cost. These will be the first features to be removed from scope if the project’s timescales are later at risk.

Would –   are features that have been requested but are explicitly excluded from scope for the planned duration, and may be included in a future phase of development.  (2)

5. Alternatively, you can use the prioritisation matrix mentioned in Jeff Gothelf’s Lean UX.

Our goal is to have a prioritised list of things to work on. This matrix helps us create that list, based on how risky a piece of work is. If a piece of work is not well understood and is high risk/expensive we want to find out earlier rather than later how it will affect us, therefore any user stories that are sorted into the top right (hatched area) should be worked on first. (3)

This way of gathering data, sorting, defining and prioritising is just one method that we have experimented with, but we’d love to hear from you if you’ve had any experiences both good and bad about how you’ve gone about getting user feedback back into the backlog.




3. Lean UX – Jeff Gothelf


Red Badger’s UX team is growing- check out our current vacancies here.


Lean UX Workshop with Jeff Gothelf – My top takeaways

by Sasha Ward

Last month I enjoyed a trip down to Brighton for a day long workshop with the author of Lean UX, Jeff Gothelf. UX enthusiasts from across the UK and some from as far as Sweden came down to the south of England to learn more about Lean, UX and all things in-between.

I’m going to run through my top takeaways from the workshop and explain how they can be applied within your product teams.

1.Don’t solve problems that don’t exist

It’s a waste of time, money and resources making solutions for problems that don’t exist. How do you know if a problem actually is a problem? Well, get out of the building (GOOB), talk to your users, ask them about their problems and observe their current behaviours or current workarounds. They might be happy with their current solution but you won’t know until you talk to them.



Within your team, get together and write down your assumptions of what you think the problem is and create a problem statement that you all agree on (you can use a problem statement template – see Jeff Gothelf Lean UX).

2.Focus on the ‘M’ in Minimum Viable Product (MVP)?

Every organisation, every team will have a different opinion of what an MVP is, “a stripped back version of the final product”, “our must have features”, “version 1″ the list goes on…

What Jeff helped cement in my mind about MVPs was two things:

– that MVPs are for learning, not basic versions of the “final” product
– and they’re not restricted to digital means

Think of MVP’s as tests or experiments to gauge interest/viability of a certain feature or product. The first question to ask yourself is “what are you trying to learn?”, then ask yourself “how can we learn that by doing the smallest amount possible?”. At this point don’t be restricted by thinking that you can only learn by shipping a basic version of the final product. What you can do instead is leverage existing technologies/services/products in order to create an experiment to test your hypothesis by using methods like landing page tests, feature fakes or wizard of oz/concierge tests.

It’s important to set a threshold for success when creating  your MVP, e.g. when we see more than 100 clicks per day on this feature we know it is worthwhile to continue with this, or if 1000 people subscribe on our landing page test in the first week we will know we are successful. If you’re not clear upfront what what success looks like then how will you know when to stop the experiment?

3.Write tactical hypothesis statements

A hypothesis is a hunch, it’s our best guess of what we believe to be true. They are a great place to start when at the beginning of building a new product or feature, but remember they are still our assumptions so they need thorough validation.

They are quite tricky to get right as a good hypothesis statement is made up of a lot of variables with a lot of assumptions baked into them. They are usually comprised of a KPI or success metric, a persona, a user goal and a feature.

Jeff Gothelf has a great template in his book Lean UX that combines them all in a succinct way:

– We believe will will achieve [KPI] if [persona] will attain [user goal] with [feature].

The most valuable lesson I learnt from the workshop was to be tactical about how you write these, think about what is in your control and think about what you are trying to learn. If something isn’t in your control then don’t go ahead with it, have a rethink and move forward swiftly.

4.Start learning more

What I mean by this is, add stories to  your product backlog purely aimed at learning something or running an experiment. Treat learnings the same as you treat other user stories and get your team invested in learning more.

These can be treated in the same way as regular user stories, scope them, define the problem, write a hypothesis and go out and test it. In doing so you are likely to learn something you didn’t know before and it’s good practice at getting everyone in your team involved in the collaborative exercise of writing hypothesis statements and creating MVPs.

5.Getting buy-in to Lean UX in the enterprise

This was a topic that had a lot of interest from the attendees of the workshop and the best pieces of advice was to speak the language of the people you are trying to convince to buy-in to Lean UX and in doing so try to bring them closer to the process.

There is a lot of technical jargon that gets thrown around day-to-day and understandably it can be quite off-putting and intimidating. What’s important when trying to get buy-in to Lean UX in the enterprise is to speak the same language as the stakeholders and understand what they value. If their interests are in acquisition and conversion, then speak to them in this terminology, don’t start talking about progressive enhancement or typeahead as this will only cause more confusion and more unproductive conversations.

In summary…

We all aim to create great products that people need, and Lean UX provides us with guidelines to help move teams from doubt (assumptions) to certainty through evidence based decision making. As the UXer, start by getting your team on the same page by facilitating hypothesis workshops and design studios to help identify the problem and create actionable hypotheses that you want to validate through testing. You and your team will learn every time you speak to or test prototypes on your users so make sure you do this as frequent and early on in the process as possible, seeing as these are the people that you are designing for you need to create a dialogue with them as often as possible to ensure that you are on the right track.

1. Lean UX – Jeff Gothelf-
2. Popcorn hoodie –
3. Feature fakes –
4. Wizard of oz/concierge tests –

This is only a brief summary of some of the things we covered throughout the day so if you’ve got any questions then please get in touch on twitter or comment below.


Badger Digest – April 2016

by Alex Savin

Image by Chris Beckett, used with Creative Commons license

Fresh issue of Badger Digest bringing you the most discussed topics and links from our 100+ private Slack channels over the past month.




One line news

  • Amazon EC2 Container Registry (ECR) is now available in the EU (Ireland) region







Good design is accessible: top tips

by Sari Griffiths

Accessibility workshop at Red Badger

But, but… accessibility makes design less creative…?

Well, no. Good design is inherently accessible. Saying it stops you being creative is a bad excuse for NOT doing a good design. I’m going to take you through why it is so, purely from a visual design perspective. If you are interested in the more technical side of accessibility, here is a good read from GDS or watch the final part of our accessibility talk (at 1:01:56).

Otherwise, read on…

Who are we doing this for?

When we think of accessibility, we tend to think these people are only a tiny part of your audience. But is that true?

Thinking in terms of visual design, here are some numbers to consider.

Mild visual impairment

I wear glasses. So does something like over 70% of UK population (1). Sounds too high but it includes contact lens and reading glasses. That’s a lot of people.

People’s vision naturally declines with age too. There  older generations are more and more tech savvy – 11 million people are over 65 in UK (2). There are more people aged 60 and above than under 18 according to the 2011 census data (3).

Colour blindness

Maybe this is the first sight related condition you think of. There are 2.7 million colour blind people in UK (about 4.5% of UK population). (4)


Ichihara test Red Badger


What can you see in above two images? For some, these two look identical. Others might see a figure on the left but none on the right.

These are called Ishihara test – common test used to check colour blindness. The left image is the actual test, and the right image is showing how it would look like for someone with Protanopia (affects red or green) form of colour blindness using a photoshop filter.


You might think it is strange to consider blindness when talking about visual design, but the design has huge impact on how blind people can interact with a web page via text reader.

Almost 2 million people in the UK are living with sight loss. That’s approximately 1 in 30 of UK population. (5)


Again it may not be the first thing to come to your mind, but it affects 10% of UK population – 4% severely so. (6)

Devices and browsers

If you use common cross browser testing tools such as BrowserStack, it has over 70 device and browser combinations. I saw an ad for a device detection service that claims to detect over 300,000 combinations, some of those can also be considered a disadvantage.

Let’s put all the numbers into context. In August 2015 in UK, only 1.86% people were using IE8 when all devices are included. Desktop share is 3.1%. (7) And the industry still spends loads of money and time to cater for IE8.

Different ability

So. The minority isn’t really that minority. The thing is, it is not easy to draw a clear line between disability and ability. It is just that there are different ways to consume the content you are designing. Thinking about accessibility basically helps making your design more versatile – even responsive ready.

7 accessibility tips

1. Good typography is semantic and responsive

Good typography is about making relationships between the words and sentences clear. It is about identifying hierarchy among your content and presenting them visually so that these relationships are clear.

For example, if we take a typical dictionary entry as an example, and strip all typographical treatment, it looks like this.




In the context of a whole page, there is no chance you’ll find the word you’re looking for if it is designed like this.

But we can use different weight, style, spacing to make a clearer difference between each element of this content.




Once you identified these relationships, it is powerful enough to take some modification. We can add line breaks.




Or change column width.




Good typography is versatile and a must have for any responsive design. When we have to cater for so many different viewport sizes, you can no longer guarantee or predict the exact location of any content all the time. But if your typographical hierarchy is clear, it will still work in the way you intended.

It is the same for screen readers. Your typographical hierarchy will be easily interpreted into semantic coding and contribute to the ease of understanding when accessed via screen readers.

To achieve this, ‘content first’ approach to design is crucial. It’s hard to design the relationship between words when everything is “Lorem ipsum”. On the side note, ‘content first’ is also an integral part of a lean and agile approach to user experience design. But that’s for another post…

2. Large & spacious

Forget the fold.

Okay, that’s a bit controversial but I’m sure everyone agrees that there is no ‘standard’ screen sizes any more as I mentioned earlier. Not like the days of 1024 x 768 desktop screen.

There are so many variations.

What you should prioritise instead, is the ease of reading. Dyslexia in particular, calls for a clear space around each piece of information. Also people with some level of visual impairment will appreciate the larger and clearer presentation.

It is more important that each element is digestible and has a clear flow, rather than how much you can fit in the first view.

Forget the fold, and make a compelling case for scrolling. If your content is engaging and makes it clear that it goes on, your audience will scroll.

3. Be picky with typeface

This affects mainly the dyslexic audience. And they prefer each letter to look very distinct. For example, having ‘b’ and ‘d’ completely a mirror of each other is very confusing. British Dyslexia Association has a good read on this subject.


I see this as a good opportunity to add some personality to the brand and definitely will consider when there is a room for us to select a different typeface.

4. Information should not be communicated by colour alone

“So, as I am a colour blind, I can’t actually see the status. But the green one means ‘complete’”

A developer

Believe me or not, above statement was actually made in one of showcase meetings I attended. Why do you build something you can’t see…?




The example above shows a familiar colour coding system on a food package. I have applied a filter in Photoshop (View > Proof setup) to simulate how it looks for someone with deuteranopia which affects the colour green. You might be able to tell the colours are different, but it’s hard to tell what is what.

Here is the full colour version.




Okay, now you know there are three colours. But this is based on traffic light system – so even if you CAN see the colours, you might not know what it represents in this context. What is “go” equivalent to the food? Eat now? Eat fast?

With this example, the solution was to use labels as well as colour coding. It helps people to learn what colours are associated with what information, and for some, to understand information without colours.




If we think this in terms of a web design context…




This lovely colour used on a popular website will look like this with Protanopia filter on.




As the example above shows, functionality that relies on colours can become invisible. You can see how easily inline links disappear, whereas you can still see the buttons.

So remember that blue doesn’t mean a link. It’s the marking and shapes you use alongside the colour that makes an element a link visually. It could be arrows, icons, buttons, or underlines. You can still associate colours with them and that can be a powerful reinforcer.

A quick note of caution for the use of underlines. It is a popular short hand for links, but long underlines – especially one that goes over multiple lines or bulleted lists – makes reading harder for any audience without even considering accessibility. Have a quick think before you use one and consider if it is appropriate.

5. Mind the contrast

This is fairly mechanical part of the process. In order to pass certain levels of accessibility standard, you should measure contrast between background and text colour in mathematical terms.

It used to be pretty crude, but the current version takes into account the size and boldness of text as well as colour contrast. It is not perfect though – it defines ‘large’ text as 14px and bold, which is rapidly becoming the standard size or even ‘small’. I tend to use 16px as the standard body copy size these days. And if you are using 160px letters, it will probably be visible if it fails the test by a small margin.

Do the contrast test as early as possible. It makes you more aware of characteristics each colour has and more deliberate in your choices. It is actually quite good fun (or is it just me?) trying to tweak the colour slightly to get a ‘pass’. I use Color Contrast Checker by WebAIM to check the numbers.

Yes, it might look pretty with that colour combination on your screen. But if your design effectively prevents nearly 5% of your customer base (about 3 million in UK) from buying your products or accessing your services, surely it’s not a good idea?

6. Give a bit of colour to your background

Knocking back the glare that white screen gives will make text easier to read for dyslexic audience. Also there are so many site with white background these days, I think it will add a bit of personality to your brand.

7. Consider printing




One of those papers obviously spent a little time thinking about print out. When the printout removes all the clutter of a website, it really helps the  dyslexic audience to read. There are many audiences that still find it easier to consume content as a print out, so it actually serves a lot of people to pay  some attention to print layout.

If the site you’re designing is all about reading the long form writing, I’d definitely recommend spending a bit of time thinking about printing.

Design that communicates

Here are the recap of 7 tips.

  1. Semantic typography is good
  2. Think large and spacious (and forget the fold)
  3. Choose your fonts like you mean it
  4. Information should NOT be communicated by colour alone
  5. Mind the contrast
  6. Consider background colour
  7. Plan for printing

Accessibility is not about lowering your standards. It’s about making your design communicate better. It actually helps you to make your design more versatile. And to be honest, it’s not a huge task especially if you are aware of it from the beginning.

So, why don’t you give it a go?

We are looking for a new Designer to join us and work on fun projects like Fortnum & Mason website. If you are interested, take a look at the job details here and get in touch! 


  • Photoshop / Illustrator – Protanopia / Deuteranopia colour proof – Go to View > Proof Setup to see how your design looks like for someone with colour blindness
  • Chrome extension “Spectrum”, “See” – these let you simulate some forms of visual impairments
  • Colour contrast


If you’re interested in stats. Here are the sources of my numbers.

  1. The College of Optometrists
  2. AgeUK
  3. AgeUK
  4. Colour Blindness Awareness
  5. RNIB
  6. British Dyslexia Association
  7. StatCounter



Attempting to reach actual reality

by Steve Cottle



Let’s do a usability test where we’ll take some participants and observe them with a product. We’ll take our findings and after a bit of analysis we’ll implement something. We’ll be able to base the development on solid research because we documented what the participants did and said. And that’s good.

Here are some things to bear in mind about usability tests:


Ironing out the creases
It’s good to practice. Practicing your test allows you to iron out any issues before they arise1. Imagine sitting down with your participant, you run through the first task annnd … they don’t understand what you’re asking! Oh no! All that time you spent crafting the perfect non-leading task and you have to rephrase what you’d like them to do. Will it be as effective as your original? Planning also means you’re not leaving everything to the last minute – printing stuff, getting equipment ready, sorting the room out and that.


Observation not conversation
As unnatural as it is, encouraging your participants to talk aloud2 about what they’re thinking gives great insight into why people find things easy or challenging. Also, try and avoid talking too much yourself. By the very nature of being a UXer, we want to help people achieve stuff so this is one that I personally really have to concentrate on. Avoid treating the session as a conversation and turn it into an observation3. Nielsen Norman Group has some good advice with their Talking With Participants article which covers three techniques (Echo, Boomerang and Columbo) that can be used in the test itself.


The whole truth?
So that’s all good. We’ve practiced and performed and now we can analyse our results.

Well hold on there Johnny-two-socks, the thing is sometimes participants might not be telling us the truth. Dun. Dun. Dunnn … There are several reasons why your results might be a little off the mark.

In UX Booth’s article Bridging the Gap Between Actual and Reported Behavior they have some insights into what could be going on in people’s heads.


1 – How would you like that answered?
Sometimes we answer questions in a way we believe the person who asked the questions would like them to be answered.  Similarly, we can answer questions how we believe to be socially acceptable … do we really exercise as often as we say we do?


2 – I’ll do what you do
There have been cases of participants straying completely away from what’s clearly a correct answer just to fit in with peers around them:

“[In the Asch conformity experiments] Research subjects were shown several lines of different length, and asked to select the two of equal length. The subject didn’t know that everyone else answering the question was a confederate of the researchers. The planted participants would sometimes unanimously give an incorrect answer and, 37% of the time, the real research subject agreed with them.”
Kat Matfield, Bridging the Gap Between Actual and Reported Behavior


3 – Self Image
People also say what they want to be true and perhaps not what is actually true, viewing their capabilities through rose tinted specs. Not so much delusions of grandeur, more wishful thinking:

“ … our self-image doesn’t match up to reality. But that self-image still influences how we respond to questions about our intentions, rationale, or preferences”
Kat Matfield, Bridging the Gap Between Actual and Reported Behavior


4 – Where and when
People respond differently in different contexts. For example there are more suitable environments than an office room to evaluate the usability of a sports app. The results from one environment would be quite different to the other4.

It’s not just about how people subconsciously answer questions. The very fact that people are being observed encourages changes in behaviour. The Hawethorne effect demonstrates that if a participant is set a task to complete while being watched by someone they might change their approach to completing that task. For example during an observation the participant may read through instructions leading to a more successful task completion, whereas if they were alone at home they may simply ignore them and fail the same task. There is also the notion that if a participant is asked to achieve a task then they presume that task can be completed. Whereas if they were using a new product outside of the test environment they wouldn’t know that what they wanted to achieve was possible and would enter a journey within the product to find out5.


5 – Ultracrepidarianism
People may also give you an answer to a question even if they they have limited knowledge of the subject just because the question was asked of them. And, if asked why they did something, sometimes participants simply may not know so they make up a reason, or offer their opinion anyway6. This is known as Ultracrepidarianism.


So …
Preparation will help things go smoothly and by applying some simple techniques during your test you can make the bits you have control over more successful. However the fact is, it’s inevitable that your participants will show some of the characteristics described above. The important thing is to be aware of them and to identify when they happen. You can’t control a participant’s subconscious or how much value they place on social acceptance and if you do become aware of anything which might skew things, note it down and advise how it may affect the results.


Usability testing tips
Here are some top tips for running a usability test courtesy of

1 – Be polite and make participants feel comfortable

2 – Help participants understand that you’re after feedback on the design. It’s not them that is being tested

3 – Remain neutral (refer to the Talking With Participants article)

4 – Avoid helping and leading the participant

[5 – Encourage participants to think aloud]

6 – Take good notes – there should be two of you, one to ask questions and the other to record

7 – Measure both performance (success, time, errors) and subjective (self reported satisfaction and comfort) metrics


Fancy joining the Red Badger team? We’re hiring UXers!










Apple Watch – A sceptical badger’s experience

by Jun Taoka


It’s been one month since I have started wearing the Apple Watch. From the outset I was a sceptic; my general lack of faith stemmed from seeing a former colleague use the watch on a phone call. Awkwardly speaking in to the device, he would frantically raise his wrist to his ear for the response. It wasn’t that he just looked completely ridiculous, but I couldn’t see the sense or value in it, and it left me with a rather cynical thought;

Could it be that new technologies are actually regressing our forms of communication all in the name of progress? 

Sure enough, the appeal and abilities of the Apple Watch extend far beyond replacing the phone for conversation, and with an open mind I explore how it might improve my everyday life. I’ve been wearing the 38mm sized version, the smaller of the two options available. Aesthetically, the face looks stylish, although I can’t say the same for the white silicon strap. The screen is high quality, colours are sharp and text is crisp on the small scale, partly thanks to San Francisco, Apple’s new typeface. To navigate, the digital crown is an intuitive tool, a clever nod to its mechanical predecessors.

First Impressions

The screen is activated as you turn your wrist to face you, and you can customise how simple or complicated you want the watch face to appear. Swiping up from the main screen activates a dashboard, which summarises ‘glances’ – top-line stats or feeds from my selected apps. I like having the weather update in my glances, which is useful before stepping out the house in the morning. Also among my glances is the music app, which allows control of my music from my iPhone without having to take my phone out of my pocket – particularly handy on the crowded commute. The native Activity app keeps record of your calories burnt, minutes spent exercising and reminds you to stand at least once an hour. I’ve never been one for tracking my exercise as I’m naturally active, but for those who are keen to improve their fitness I can see its value and I do appreciate the reminder to stand, given the slump I easily fall into sitting at my desk.



The Apple Watch is able to take photos from the iPhone remotely. Here’s the happy design team out on a lunch trip. Goodbye, selfie-sticks. 


Double tapping the crown will take you to the last viewed app, which aids continuity in your task flow, whether it be returning to a news feed, inbox or map. Holding down the crown will activate Siri, which I have only genuinely found helpful for setting reminders for tasks at a particular time. Message notifications come in through a vibration, which can then display when looking at the watch. Surprisingly, I do find myself enjoying the ability to quickly read messages on the watch, and although it’s only a tiny inconvenience to grab your phone, somehow I find it less interrupting when I’m in the middle of a task or on the move. Receiving multiple messages at once is a bit unpredictable though, and often these messages can’t actually be read. In turn I’ll have to look at my phone, resulting in a frustrating and disjointed experience.


One crisp Autumnal morning I take the watch out for a run with the Strava app. Unlike fitness trackers, the Apple Watch doesn’t have an internal GPS. This means that if you intend to keep record of your route, you’ll need to carry an iPhone with you. I start running and with the press of a finger the timer starts ticking along with my speed and distance covered, which is all presented clearly enough to take in at a moments glance. Trying to change song track while in Strava was a problem, though. Navigating is just too fiddly if you’re not stood still. It’s certainly a nice-to-have pairing, but if I were a serious runner I might consider buying a GPS fitness tracker and a light MP3 player for simplicity’s sake.




Having read positive reviews, I try Google Maps, one of the more popular apps for the watch. Once I set my final destination using the iPhone, I tuck it back into my pocket. In theory, this should allow me to glance at the watch when I am notified for simple directions, rather than being glued down to my phone, helping me avoid oncoming lamp posts and commuters. The thing is, because my internal compass isn’t actually calibrated with my iPhone, directions like “Head East towards X Street” are rendered utterly useless. Instead, my colleague takes charge and leads us through some scenic London shortcuts. This is a bit of a shame, since the technology is ready, but the usability is let down by the execution.

In its early stage, apps for the Apple Watch seem to be in varying stages of development. The BBC app for example is excellent at summarising succinct headlines, which you can then read in further detail or open the full article on your iPhone. The Guardian, on the other hand, has a beautifully designed app on the phone, but is appalling on the Apple Watch. Publishing only one article at a given time and removing any control of browsing content leaves me feeling disempowered and discontent.

Final Thoughts 

The Apple Watch feels like an incomplete product, a prototype in its infancy still testing the waters, or maybe a strategic move for Apple to assert its stake in the market. Generally, I find it too delicate to navigate between apps, and the apps themselves often take a few seconds too long to sync with the iPhone. At other times I don’t find it sensitive enough; a casual glance at the time won’t work and you’ll sometimes find yourself doing a double take to ensure it displays. Although slight, the momentary delay between flicking your wrist and reading the time creates a small and unnatural disruption in fluidity.

With the development of better considered apps and hardware, such as integrated GPS, smart watches are likely to become more versatile and seamless in our everyday lives. Indeed, wearables in general and their interaction with ‘The Internet of Things’ are likely to shake things up in unexpected ways. They are already bringing new changes to healthcare and medical research and are likely to spread to sectors such as Insurance, Manufacturing, and Childcare to name a few. 

But if the Apple Watch was made to make communication less invasive, then I believe its purpose has failed. In the past few weeks a number of friends have commented (with offence taken) that I can’t keep looking at my wrist. Most of us learn to be courteous enough to ignore the vibration of a phone in a pocket, but it’s much harder to dismiss the temptation to glance down at your wrist. Naturally, the added complexity and functionality won’t change the fact that looking at a watch is universally recognised as an expression of impatience and boredom.

Fans of the watch will cry out that there’s no mention of Apple Pay here, and it’s something I would have tried had I not had a complication with the bank. That said, the more popular smart watches become, shops will need to anticipate how they can make payments easy enough for everyone, regardless of height or disability, without it feeling needlessly painful or harder than taking your card out your wallet. The biggest obstacle for the wearables market could rest in addressing behavioural change and integrating devices in truly seamless ways that won’t upset social norms.


Tips for keeping User Experience lean

by Joe Dollar-Smirnov


There are a huge number of buzzwords, acronyms and trendy methods around in our great industry, the title of this article is a case in point. At Red Badger we have started to collate some of them into a glossary and we have already exceeded 20 different processes or methods for what amounts to ‘getting shit done’. 


Sometimes these methods and techniques are credited with being modern and new but normally they are simply a rehash of previous ideas and methods based on years of historic research and study. Scholars come up with theories and methods, they become adopted and then adapted – and repeat.


Let’s take UX design as an example. Although User Experience as an explicit discipline has only been around for 25 years or so, it’s roots go back much further. 1957 was when the Human Factors and Ergonomics Society was formed. It is a group committed to “the discovery and exchange of knowledge concerning the characteristics of human beings that are applicable to the design of systems and devices of all kinds”. Sound familiar?


Frequently we come across organisations who have Agile development teams with talented pools of designers who have not had a chance or the space to get to grips with the implications of working Lean. More often than not they have read all the books and are concerned with how to implement what they have read. The focus should not be on doing everything by the book if it isn’t necessary, but in delivering value. The reduction of waste in the process. That is how we work – by offering maximum value and great quality. It’s also how we create multi-award winning websites that delight our clients, their customers and generate significant return on investment.


So how do we integrate user experience design into a fast paced, lean, multi-disciplined team?


1/ Build a shared understanding

Jeff Gothelf says that Shared Understanding is the currency of Lean UX. Do what you need to do to get a shared understanding. Collaborate, pin up your thinking, sketches, notes, discuss around the project board every morning, during the day, whenever you can. Involve the team in as much of the following points as possible.


2/ Keep ideation rough and fast

Do not to spend ages working on ideas that might not work. Keep it loose so that people can understand the idea is not final and can be open to interpretation. Keeping it rough and fast means you do not get too attached to your ideas and if required you can discard them easily.


3/ Check your assumptions – research and test

Designs should be based on your knowledge of the problem. Research, check your assumptions and test your ideas on real people. Use quantitative and qualitative methods. Some feedback is better than no feedback but make sure you use your data to inform, not dictate your decisions.


4/ Be humble and ask questions

If something is unclear then ask. Speak to the client, or other team members. Don’t fall into the trap of automatically thinking that your way as the designer is the best way.


5/ Make it a team sport

Everyone is a designer, well at least everyone likes to have an influence on design, harness this. Allow people to have their say, input into the problem. Run sketching sessions with the whole team if possible. Include the client in this. It helps to build shared understanding and allows you to quickly understand the business and technical constraints on a problem if everyone is present.




If you are doing all these things there are no promises about the output, but you should find that you can start to work with more freedom and produce more ideas at a greater quality, furthermore, the ideas will have already got team buy in. Time selling in design ideas and presenting the client will be reduced and the overall productivity of the team will increase.



Relay runners and dance revolutions

by Olga Loyev

This week I’m in Antwerp, Belgium for a 2 day Lean Change Agent workshop with Jason Little. Day 1 just ended and I’m exhausted!! But in that great my-brain-is-buzzing-with-new-ideas-and-information kind of way. Since my brain is way too excited to let me fall asleep, I thought I’d share just a few interesting bits from the workshop today that got me thinking:

But I’m a people’s person!!



Jason started off the morning by comparing organisations to relay running. In a relay race, participants run around passing sticks to each other. Okay, it’s more complex than that but you get the gist. Sometimes while passing the baton to the next runner, they might drop it. Things happen. Runners will then train harder, learn passing techniques, get leaner etc; and they’ll get better, faster and drop less batons with time.

As organisations grow, some things get dropped. And oftentime instead of focusing on how to get leaner, organisations will instead add a “baton passer” to be in charge and accountable that the baton gets from one set of hands to the other. If we put one person in charge and accountable for something, then it’ll for sure get done, right? But what you end up with as company continues to grow is less runners moving you forward and just more “baton passers”.

Lean organisations on the other hand, don’t want unnecessary specialisation. They want T shape people with depth of knowledge in some area (like programming) as well as an interest and understanding of a broad range of other disciplines (like user experience). The result: lean organisations are faster and stronger because they hire and nurture the relay runners and not the “baton passer”.

Waterfall is right!

How many of the following statements would you agree with?

“Kanban brings about evolutionary change”

“Agile is the right way to deliver software”

“Waterfall is best way to deliver software!”

Say whaaaat?!?! Jason almost lost most of the crowd at the workshop when he made that last statement. For me it was a very loud and definite “NO”.

What will it take for me to convince you that Waterfall methodology is the right way to go?

Some of you might be screaming “absolutely nothing!” in your head. And I was the same. I had an immediately and very strong reaction to that question where I’ve already made up my mind and no matter what was going to be said after, it was never going to convince me that Waterfall is the way to go.

And now imagine that that’s exactly how some other people feel when you tell them “Agile is the right way to deliver software”. Some people have such a strong and immediate negative reaction to that statement that no matter what you say after, you will never be able to convince them by starting off making a statement like that. And that doesn’t make them crazy! Did you experience first hand the failure of a Waterfall project? Well what if they have experienced the same with an Agile project?  

What if instead you ask them how they would do a project. I bet you most of them would say (more or less) something along the lines of “Well, I want to understand what needs to be done, design it, build something that works and ship it”. Yes! That’s pretty much how we’d do it as well, but we’d do it more frequently and in smaller batches. Ultimately, in the context of software delivery we all want the same thing: to deliver the right thing in the right time at the right cost.

As a change agent, start with what people believe, value and do; establish a common goal; and focus on the positives. Don’t start off with by pushing your beliefs or approach on to them as “the best”. I personally think the term “Agile” has been bastardised almost beyond recognition by individuals and organisation using the “Agile stick” to force change or beliefs onto others. And it was fantastic hearing Jason Little say to take “Agile” and “Waterfall” out of the conversation completely! Focus on what’s good and agree on ways to eliminate waste and continuously improve. Drive positive change together.  

Let’s get focused

How many of you have seen this video before? If you haven’t, get ready to laugh (and learn). Even though I’ve seen the video below previously, it was the first time I watched it with this commentary. Although hilarious, it’s also very insightful into how movements and change happen.


“All mankind is divided into three classes: those that are immovable, those that are moveable, and those who move.” –Benjamin Franklin

In simple terms:

The movers are the leaders. The movables are the people that can be converted to the believers or to the non-believers of something. And the immovables are the ones that just won’t budge. They are strongly opposed and resisting to whatever the movement the movers are trying to start.  

Change agents often focus their attention on converting the immovables to understand and join the “movement”. Most of the time that results in spending insane amount of energy and time in vain trying to convince someone that has no intention of trying to understand or consider your suggestion.




What if instead we focus more on the majority of people, the movables? The people that are willing to listen and to try. The people who are not absolutely and unconditionally opposed to the change you’re trying to bring around. Nurture the first few followers. Facilitate them with the skills they need to bring about the change. Help them become the movers who will then help to do the same with the movable group. And then maybe, just maybe, the majority will convince the immovables to try something new and give change a chance. And then, well, then you may have just started a dance revolution!

Red Badger offers an annual £2,000 training budget to experience things like this. Sound good? Then come join us.


Smooth Sailing- Designing businesses to deliver value

by Sinem Erdemli

“Improving experience starts with every customer interaction. Your customers see you as a one entity.” –Jiri Brezovsky

This is a quote from his post Stop wasting money on a “beautiful” interface it’s about the importance of improving the overall experience, rather than creating beautiful UI. It’s a brilliant and valid point, one which we at Red Badger think about a lot.

Even though a beautiful design, a high quality piece of software or sky-high conversion rates may seem like the ultimate goal of running a business, especially on a day to day basis, there is one crucial bit that shouldn’t be overlooked. That is to deliver value. 

I just want you to get the job done

As a customer, I don’t care about how well your metrics are doing, whether or not you’ve met your sales goals or when the next software update is due. 

I only care if I can get what I want from you or not. How much do I need to give [time, money, effort] vs. how much I get out of it. 

In the end, if I want to get my hands on a new computer I want to decide which one is for me, where and how to buy it, and how to set it up and who to get in touch when something goes wrong. All of that should be easy peasy, but is rarely so. 

The times they are a-changin’

Businesses have complex structures, they exist on multiple channels, partner with numerous 3rd parties and carry ways of working from the day they were established. 

A business runs with the help of multiple ‘departments’ ranging from marketing, sales, merchandising, customer services, online, suppliers, logistics. There’s also a big board of stakeholders to please with the outcomes.

“The problem [with designing in silos] is that customers don’t just care about individual touchpoints. They experience services in totality and base their judgement on how well everything works together to provide them with value” –Andy Polaine et al.

Each and every department has different targets and end-goals. They are usually focused on just one channel or a single touchpoint of the customers overall experience of a customer. The problem arises when the links between these individual touchpoints are left unattended, when they don’t appear on the targets because they are not tangible enough to make it to the boardroom. As a consequence, your customer’s experience with your business ends up being nothing but a broken, inconsistent and painful journey. 

When you think about it there is only one simple relationship to focus on, whether you’re in the boardroom, at the shop floor or in the office developing the website; and that is the one between you and your customers. 

 Love thy customer

value transaction

When it comes to deciding whether or not to come back, or to ‘recommend the service to their friends’ customers will not think about one interaction in isolation. They will think about how easy it was to use the website, how the staff treated them on the shop floor, they will consider the call they received by customer service team when their package was late all together. Overall their decision will depend on how easy it was to reach their end goal, the whole reason why they chose to get in touch with your business in the first place. 

Keeping the bigger picture in mind at all times will allow you to have meaningful conversations when you’re collecting requirements. It also will give you a reason to talk to each other, regardless of your position in the business. 

Stop and ask why how who

Before you get in your productive autopilot mode, stop and have a think about what the greater goal is.
are you doing what you’re doing?
How might you make it better for the person at the other end?
Who else might have an effect of the delightful experience you’re trying to create? 

Go speak to your colleagues, your stakeholders, customers. Involve as many parties as you can. Make sure you, as a business, are giving the same message, have the same tone and same level of delightfulness for your customers throughout their journey with you. 

Then and only then will your efforts count for something. Don’t forget, your profit, sales, conversion rates can only improve if you love your customer, try to make their journey with you as happy and valuable as possible because your customer will love you back. (and will most likely recommend you to a friend, if that’s what you’re after)

further reading has plenty of methods you can use to think about your business offer as a whole. I would recommend checking them out. Or have a read through Andy Polaine’s book Service Design, it is delightful and one of the best you can find around. 

let’s spread the love together

If you crave consistency in experiences and want to help businesses create value with beautifully designed high quality software get in touch. It doesn’t matter where you’re coming from, as long as your intentions are well:) 


What I Learned about the Future of Internet From Fluent Conference

by Alex Savin


By the year 2015 I imagined the internet to be something close to how it was envisioned in Gabriele Salvatores’ Nirvana cyberpunk film. You’d plug yourself into cerebral cortex, put VR goggles on and off you would go flying into the cyberspace.

Funnily enough, there was a glimpse of that during the recent O’Reilly Fluent conference in San Francisco. But all things in order.

Fluent isn’t a conference to attend if you want to get deep knowledge on a certain subject. 30 min long sessions are great to get a drive through the topic, to give you understanding on what it is. What Fluent is perfect at is to give you broad overview on stuff you had no idea about. 5 simultaneous tracks of talks, one extra track of meetups, one more for workshops and as a bonus there is ongoing exhibition hall with companies and live demos of hardware and software.

There is optional extra day for just workshops – which actually was good for getting deep into a subject. We went full contact with ES6/7 new features, intricate details on type coercion in Javascript, and did a good session on mobile web performance with Max Firt.

O’Reilly also brought some heavy weight keynote speakers. Paul Irish (creator of HTML5 boilerplate and Chrome web tools dev), Brendan Eich (creator of Javascript), Eric Meyer (author of pretty much every book on CSS), Andreas Gal (CTO at Mozilla) among others delivered a comprehensive overview on where we’re now and what to expect in a next few years. I’m going to cover a few interesting trends spotted during the conference.

Rise of the transpilers

This was mentioned directly and indirectly during many talks, including creator of JavaScript himself. Future of Javascript is not meant for humans, but instead a something you’re compiling into. Many new features in ES6 and 7 should make this easier for compilers. If you had any doubts so far on things like LiveScript, ClojureScript or even Babel, it’s time to stop worrying and start implementing transpilation into your build pipeline. Especially since Babel might as well become a language on its own.

React is hot

In all the honesty I missed all React related talks during the conference, of which there were quite a few. Later catching up with other attendees I got my confirmation that all of the talks were indeed mostly of introduction into React, Flux and ways of injecting React into your app. What was interesting is that each time I’d mention React and Red Badger working with React for the past year and a half, I’d become centre of attention, with people asking questions on how we do things. After describing our (now pretty much standard) setup with apps being isomorphic, hot components reload in place, immutables for state handling and ability to deliver app to no-JS clients, people would often say that Red Badger lives on a cutting edge. I couldn’t agree more.

Many people would also ask – how come it’s year and a half already – isn’t React just being released? The important part here is that lots of people are hearing about React now for the first time, and are really excited.


Eric Meyer made a great point during his keynote dropping a (deliberately) controversial slide that Web is not a platform. Right now lots of web developers assume JavaScript support as a given on any client. This is something Eric tried to address. Web is not a platform, there are and will be lots of clients with support (or lack of) for any sort of tech stack. When you take CSS off the webpage, it suppose to stay functional and content should still be human readable. Same goes for JavaScript, and any other tech we might introduce in the future. Assuming that you are targeting a broad audience, it’s always a great idea to implement your app isomorphically, with gradual degradation of user experience, in case client doesn’t support some of the tech we’re relying upon.

Be conservative in what you send, be liberal in what you accept.

All of this goes very well with the React and what we’re currently doing with it. If you have modern device, browser and JavaScript support, you’ll get single page app experience, with blackjack ajax, client side routing and visual effects. If not, we’ll gracefully degrade to the server side rendering – which will actually improve performance on older mobile browsers instead of forcing JavaScript on them.

Importance of the progressive enhancement was echoed by @obiwankimberly during her talk on second World Wide Web browser and CERN’s efforts to revive it. Line Mode Browser was the first browser ported to all operating systems, and was used by many people around the world. Most of us might not consume web in text only mode anymore, but the idea of progressive enhancement goes all the way to accessibility, screen readers, and those people who rely on text-only representation of the Web.

HTTP/2 is here

Or simply H/2. Not only the spec is finished, H/2 (in its SPDY incarnation) is supported in 80% of all modern browsers.

For the transition period you can setup your web server to fallback to HTTP/1 in case client is not ready for new hotness. IIS doesn’t support H/2 at all, but there’s nothing stopping you from getting Nginx proxy in front of it with full support for H/2.

Why H/2 is important? Few things:

  • Multiplexing. Each HTTP request requires quite a bit of time to initialise, thanks to something called “TCP three way handshake”. Even with fibre connection this consumes precious time and patience of the user. In addition to that, HTTP’s known bottleneck is slow requests that block all other requests. With H/2 you can retrieve multiple resources during a single connection, practically streaming data from the server. No more need for concatenation of CSS / JS files, image sprites, inlining CSS / JS. Even domain sharding is obsolete now.
  • Security is not optional. It is not part of the official spec, but Firefox and Chrome require you to encrypt all communication when using H/2. Which means, you have to use HTTPS. This has one interesting consequence – if one of the web proxies on the way of our request doesn’t support H/2, such request will still get through, since it is just a stream of encrypted data.
  • HTTP headers compression. All headers are now nicely packed together using something called HPACK encoding.


It seems that people at Mozilla are sharing my passion to see Internet with users immersed into it. If you have Oculus Rift and latest Firefox nightly, you’re all set to check out something they call WebVR. Idea is simple – WebGL graphics rendered by the browser into your virtual reality goggles, as well as you being able to look around and interact with the experience.

To boldly go where no man has gone before.

On the second day of exhibition they enhanced the VR experience by sticking LeapMotion sensor with tape on the front of Oculus, which allowed people to see their hands and fingers inside the simulation. That’s something that makes experience truly immersive – we like to move our hands around and seeing them interacting with stuff.

Another possible use for such technology is spherical panorama viewing, be it still picture or video. YouTube already supports such experiments, and one can only imagine this expanding in the future. I believe Mozilla VR department is spot-on about VR experiences delivered with the browser. There are still lots of questions, most of VR territory is completely unknown (UX in WebVR, anyone?), but it feels truly exciting to live during times when such things are coming to life.

Internet of Things

This whole IoT concept was pretty abstract to me, until IBM did a live on-stage demo of a cloud based AI overlord, speaking in a nice voice and doing neat tricks.

I can monitor and command your devices. Typically I monitor vehicle fleets, cool things like power boats, medical devices, and perform real time analytics on information as well as historical data storage and visualisation. I can see you’re wearing heart monitor today. – Sarah, the AI overlord.

During a very short keynote by Stewart Nickolas he let Bluemix cloud based app to scan the room for controllable devices and sensors, and then asked Sarah the App to take control over one of the robotic spheres on stage that she discovered. Interesting part starts where you can imagine Sarah taking over fleets of vehicles, smart sensors and making decisions for us, humans. IBM is building a platform to unleash apps out of cloud into the real world.

On conference

Fluent was by far the biggest and extremely well organised conference I ever attended. Here are a few observation on how they did things.

  • Wifi. As usual on internet conferences with 1k+ attendees, it’s hard to provide reliable wifi signal in a single room. Biggest problem was keynotes, since everybody would be in the same place, actively posting things. In addition to bringing more routers into the room, they also quickly realised to ask audience to pause Dropbox syncing and whatever other cloud backup apps you might have on laptop. That actually helped a lot.
  • Speed networking sessions in the mornings were actually more fun than expected. Not only you get to meet bunch of mostly interesting people, it also puts you into the right mood of the conference and makes you a bit less introvert.
  • Game of code. During first two days you could do your part in collecting stickers by performing various quests and attending events. Each sticker contained few lines of JavaScript code. Once you’ve collected all 12 stickers, you’re suppose to figure out the order of those lines, enter them into browser console of the Fluent Conference website, and, if successful, get a confirmation ID for a prize.
  • Info board. In the main hallway they placed a huge paper board where anyone could leave messages, post job ads or distribute stickers. Often people would pin business cards next to the job ads.
  • After lunch desert location was used to great effect to direct flocks of attendees. In a last two days it was moved to the exhibition hall, so you could munch on a desert while checking out Mozilla VR experience.


All keynote videos are now available on O’Reilly YouTube channel. Few of my personal favourites would be:

I also compiled a video for the whole San Francisco trip – was my first time in California after all.

Red Badger offers an annual £2,000 training budget to experience things like this. Sound good? Then come join us.