My takeaways from UX Brighton 2017

This was my first time attending UX Brighton and after a day of excellent talks based around the subject of 'complexity', I would fully recommend it and hope to make it to next years event too.

In total there were eight talks throughout the day and whilst all were good, the following are the talks that I personally took the most from:

James Box

Director of UX, Clearleft

Fortunately, I had already consumed a fair amount of coffee before James began the day talking about abductive, deductive and inductive reasoning. In a nutshell, reasoning is the process of using existing knowledge to draw conclusions, make predictions, or construct explanations.

James also likened the early design process to a single line, tangled and messy at the start, but gradually flattening out as the project develops:

"The conclusion already exists and we need to use our intellect and experience to solve it"

Inductive reasoning

Also referred to as 'bottom-up reasoning' because it seeks to prove a conclusion first.

For example, 'My older brother is good at math. My friend's older brother is good at math. My neighbour's big brother is a math tutor. Therefore, all older brothers are good at math.'

This is a generalised conclusion. Being an older brother does not inherently make you good at math.

Deductive reasoning

Also known as 'top-down reasoning' because it goes from general and works its way down more specific.

For example, 'All cars have engines. I have a car. Therefore, my car has an engine.'

We know that the conclusion is true because it is based on generalized premises that are true without any exceptions. As long as the premises are true, then the conclusion will also be true.

Abductive reasoning

One of the most common types of reasoning.

For example, you see someone with a tanned line on their wrist, and abduce that they regularly wear a watch.

Liz Keogh

Independent Lean and Agile consultant

Liz introduced us to Cynefin (pronounced, 'Kinevin'): a framework for making sense of different situations and how to approach them depending on their predictability.

"People say one thing and then do another. You learn by making people do things"

Liz also made the point that you have to learn by getting people to do things. It’s okay to fail as this can lead to new discoveries, and finding out what’s going right can be more challenging than what’s going wrong.

Estimating complexity

One interesting way of estimating the complexity of a task is to compare it against the following levels of complexity:

  1. We all know how to do it
  2. Someone in the team has done it before
  3. Someone in the company has done it before
  4. Somebody outside the organisation has done it before (probably a competitor)
  5. Nobody has ever done it before

Companies should want to invest their time and money into points 4 and 5 but because that is also where the most risk lies, they often don't.

Gerry McGovern

Involved in web customer experience since 1994

Gerry's highly amusing talk focused on prioritising the activity of the customer rather than the activity of the organisation - which is what traditionally happens.

Often the simple approach is best for the customer, but the complexity comes from the organisation. The organisation wants flashy things to show how great they are. But it's not great for users.

  • Interview your customers to see what they want
  • Interview your stakeholders to see what they want
  • See if the two sets of priorities align
  • Base the top tasks on what the customers want

One example of this was a search field to find your nearest health centre. Gerry showed that one year this search field had a 100% completion rate, yet the following year it nearly halved. Why? Because the organisation introduced an interactive map showing all of its health centres. Innovative solutions look great but they very rarely fit with the target audience.

"Customer success rate and how long it took them to do a task are the only goals you should have. Being able to complete a task is extremely important, but enabling the customer to do it quickly is when you'll get a positive reaction."

ShekMan Tang

Product designer at Intercom

Shek's talk was particularly interesting to me because he spoke about how designers and devs can work with each other right from the start of a project. This is important for a number of reasons:

  • The focus is on what the product/feature does, rather than how it looks
  • Everyone gets a say
  • It creates a shared vision for the whole team
  • Allows the devs to start planning
  • Allows feedback and collaboration early on
  • Breaks a big product into smaller parts in order to prioritise tasks
  • Product consistency
  • Allows a component (for example, an article) to look the same wherever it is used across the site/product

Essentially, it’s a top-down approach where you consider the big picture first and the specific interactions later.

Other things to consider:

  • What are the core elements in the systems?
  • How are the elements connected?
  • What are their relationships?
  • What are their inputs and outputs?
  • What does it help you achieve?

You should take new product ideas and establish how they would work within the existing system. Are there elements with similar purpose. Can you reuse or combine them?

And, your job is never done. There are always things that can be improved. So keep asking yourself if the system can achieve the same goal with a smaller amount of elements?

Daniel Harris

Service Design expert

Dan's talk was slightly different from the rest as he spoke about the social responsibilities that we have as designers.

We are changing the way we interact on the internet via websites and apps and this has psychological impacts. Our work can touch the lives of so many people and we should be considering the impact we can have on our end users.

"Barclays’ ‘digital eagles’ program resulted from an org seeing customers as they really are rather than idealistic personas"

It's extremely important to not only think about the functional outcomes of using a website or service, but also how doing so makes your users feel.

Thanks again, UX Brighton. Hope to see you next year!

Like this post? Got a question?

Reply via: Email, Bluesky, Mastodon, Twitter