Close

Jeff Gothelf and Lean UX

In case you don’t know, I’m a big advocate of “Lean UX” and the work of Jeff Gothelf on this topic. It was Jeff who originally coined the term ‘Lean UX’ and wrote a great book about it, together with Josh Seiden. In short, Lean UX is all about not doing all your product design upfront, designing in more iterative fashion instead. I recently attended a talk by Jeff in London, where he talked about the concepts behind Lean UX, and here’s what I learnt:

  1. Cut out the design phase – Jeff stressed that the traditional design phase, where design is done in isolation, needs to go. I totally agree. Far too often designs are being thrown over an imaginary fence and implemented in a way that didn’t match the desired user experience, as intended by the designer. Instead, designers and developers should collaborate around ‘transient artefacts’, a simple sketch or prototype (see Fig. 1 below), in order to come to a shared understanding. These artefacts are by no the finished article, but create a shared understanding of what we’re looking to achieve and why.
  2. So what!? – The main idea about being ‘lean’ and ‘Lean UX’ is to “do less, more often.” Instead of just focusing on shipping features as often as you can, Jeff argued that the goal should be to achieve specific user outcomes as frequently as possible. I can imagine that this means a change in mindset and approach for some product teams. I believe, however, the ability to constantly ask the question “so what!?” from a user’s perspective is critical to building successful products. Whether you ship 2 or 50 features per iteration, this becomes totally irrelevant if you’re not changing customer behaviour.
  3. Humility and risk mitigation – I personally believe that as a product persona, you need to have a healthy degree of humility, and Jeff addressed ‘humility’ within the context of assumptions. He acknowledged how hard it can be for all of us to admit that we don’t know what the end state of a product or solution is going to look like, especially when you haven’t spent months creating a full product specification upfront. However, this is a risk that can be mitigated by being humble, acknowledging that you’re making assumptions and picking the riskiest assumptions to test first. In practice this will mean that you’ll be doing user research and getting feedback as part of each iteration.
  4. Change definition of “DONE” – Instead of just taking a feature release as the final stage of the definition of “DONE”, Jeff suggested that “changing customer behaviour” should be the ultimate definition of DONE. You pick a tactical metric that reflects the impact that the product is looking to make on customer behaviour. For example, you focus on a leading indicator to represent ‘customer intent’ or ‘conversion’ and something is only considered DONE if you’re moving the needle on your chosen metric (see Fig. 3 below).

Main learning point: I always learn something new from Jeff Gothelf and it felt no different with his recent talk in London. The main thing I took away from his talk was the importance of focusing on user outcomes instead and changes in user behaviour, as opposed to just shipping features.

Fig. 1 – Visual depiction of a transient artefact – Taken from: http://www.jeffgothelf.com/blog/you-dont-need-a-ux-portfolio/ 

ixdPortfolio_blog_image

 

Fig. 2 – Acknowledge that we’re making a lot of assumptions when building products – https://medium.com/the-job-to-be-done/replacing-the-user-story-with-the-job-story-af7cdee10c27

Assumptions

 

Fig. 3 – Build-Measure-Lean and Think-Make-Check – Taken from: http://www.smashingmagazine.com/2012/10/lean-startup-is-great-ux-packaging/

Think Make Check

 

IMG_2814 (1)

 

Related links for further learning:

  1. http://www.jeffgothelf.com/blog/you-dont-need-a-ux-portfolio/
  2. https://medium.com/the-job-to-be-done/replacing-the-user-story-with-the-job-story-af7cdee10c27
  3. https://www.uie.com/brainsparks/2015/07/17/jeff-gothelf-discover-what-customers-really-want-with-lean-ux/
  4. http://www.smashingmagazine.com/2011/03/lean-ux-getting-out-of-the-deliverables-business/
  5. http://www.smashingmagazine.com/2012/10/lean-startup-is-great-ux-packaging/

App review: WeSwap

It’s all about the “sharing economy” these days. Think Uber, Airbnb and JustPark. Sharing is starting to become a ‘thing’ in the finance sector too; TransferWise is a good example in this respect. I recently came across WeSwap, which is a peer-to-peer travel money exchange service founded two years ago. I decided to review the WeSwap app and these are some of my findings:

  1. How did the app come to my attention? – I recently read an article in the Financial Times, titled “Travel money venture cashes in peer-to-peer cash.” WeSwap got quite a lot of coverage in the article and that’s how I found out about it.
  2. My quick summary of the app (before using it)? – Similar to the model behind TransferWise, I believe WeSwap helps people to exchange currencies without having to pay hefty bank fees.
  3. How does the app explain itself in the firs minute? – Before entering the actual WeSwap app, I see a screen which states “WeSwap helps you save on your travel money.” This is followed by the explanation “by swapping your money with other travelers, travelling in the opposite direction (see Fig. 1 below).”
  4. Getting started, what’s the process like (1)? – Despite the app being a bit slow to load, the account creation process felt very intuitive, clean and nicely laid out (see Fig. 2 below). I did feel a little bit of confused as I thought account creation was going to be a 1-step process (see Fig. 3 below). However, after I’d submitted my email and and password, I got a screen which showed a 3-step account creation progress bar at the top (see Fig. 4 below). I then had to give up on the the account creation process, as I was doing this on the go and didn’t have personal ID files that I could upload, nor was I fully clear on why this was necessary to create an account (see Fig. 5 below).
  5. Getting started, what’s the process like (2)? – From the screenshots that I’ve looked at (see Fig. 5), the WeSwap interfaces and interactions feel very clear and intuitive. What I couldn’t test, however, was how self-explanatory the “swaps” and “loads” are. I believe that the ability to explain the currency ‘swaps’ to casual users will be critical to the success and adoption of WeSwap.
  6. How does the app compare to similar apps?Currencyfair and Kantox offer a service similar to WeSwap. However, they don’t seem to have a mobile app. Transferwise, another WeSwap competitor, do offer a mobile app. The TransferwWise app feels very accessible, and is focused on being easy to use.
  7. Did the app deliver on my expectations? – I feel I can’t really answer this question, having given up during the account creation process. The way the app presents itself in the first few screens feels very intuitive and simple, but I hadn’t expected the sign-up process to feel as onerous as it did. That could just be me and not the app, but it did stop me from using the app on the go.

Fig. 1 – Screenshot of WeSwap opening screen (when using the app for the first time)

IMG_2797

Fig. 2 – Screenshot of account creation process in WeSwap 

IMG_2807

Fig. 3 – Screenshot of account creation process in WeSwap – Step 1 

IMG_2808

 

Fig. 4 – Screenshot of account creation process in WeSwap – Step 2

IMG_2811

Fig. 4 – Screenshot of account creation process in WeSwap – Step 3

IMG_2812

 

Fig. 5 – WeSwap screenshots – Taken from: https://play.google.com/store/apps/details?id=com.weswap.app

WeSwap 1

 

WeSwap 2

Why I am a big fan of Dan North and behaviour driven development

I believe that “behaviour-driven development” (‘BDD’)  is one of those techniques that when you have done it once, you are likely to keep applying it. BDD was first introduced by Dan North, a well known Agile and Lean technology specialist, and is great tool for specifying and communicating the behavioural changes that one wants to achieve.

BDD typically starts with defining business or user outcomes, and then drills down into a feature set that will achieve those outcomes. The key elements of a story are: Title (one line describing the story), As a (role), I want (feature) and So (benefit).

For example:

Story 1

Title: Running out of ice cream alert

As an ice cream lover

I want to get an alert as soon as I am running low on ice cream in my freezer

So that I can order new ice cream and never have to run out of ice cream

A story is then accompanied by acceptance criteria, which are usually presented as “scenarios”. These scenarios are meant to help establish when a feature is “done”, or complete. The key elements of a scenario are: Title (one line describing the scenario), Given (context), And (some more context) and Then (outcome).

For example:

Scenario 1

Title: Number of ice cream tubs is running low

Given that I have turned on my ice cream alert

And there are less than 5 tubs of ice cream left in my freezer

When I open the door of my freezer

Then I receive an alert on my phone letting me know that I am running out of ice cream and I can order my ice cream and fill up my freezer

Now that I have given a quick flavour of what BDD is all about, let me explain why I am such a big fan of this approach:

  • It provides a common language through which people can communicate what it is they are trying achieve and the scope of the work involved.
  • It is an “outside-in” approach which means that the initial focus is on identifying the business and/or user outcomes, making sure people are clear on what ‘done’ looks like.
  • Stories and scenarios are testable, irrespective of whether testing is done in automated or manual fashion.
  • Defining stories and scenarios helps to spot any gaps or edge cases early on in the process, especially if you involve the key people involved from a range of disciplines.
  • None of these stories and scenarios are set in stone, but are likely to evolve and expand. This fits well with products that are developed in an iterative manner.
  • In my view, a good story or scenario is unambiguous in terms of the outcomes it aims to achieve and provides something which can be measured.

Main learning point: As much as I am a fan of Dan North and BDD, I know that there a lot of people out there who are less passionate about this approach. For example, they feel that BDD can be too prescriptive or test oriented. I would love to hear from (non) fans to learn how other people do or don’t use BDD and what they see as its main benefits or pitfalls.

Book review: “The Laws of Simplicity”

“Simplicity” almost feels like a magic word, particularly when you’re a product manager or a designer. Last year I wrote about the rise of single purpose apps and mentioned John Maeda’s “Laws of Simplicity”. John Maeda is a well known graphic designer, computer scientist, investor and academic. He’s also an author and I recently read his most popular book, “The Laws of Simplicity”. In this great book, John has outlined 10 laws which define what simplicity actually means and how can you can apply its underlying principles in every day life.

I’ll outline Maeda’s “Ten Laws of Simplicity” and highlight the things I’ve learned from reading his book:

  1. Reduce – “The simplest way to achieve simplicity is through thoughtful reduction”: In short, “reduce” is all about removing functionality as the simplest way to create simplicity. Maeda advises “When in doubt, just remove, but be careful of what you remove.” Maeda uses the “SHE” framework to help make thoughtful reductions (see Fig. 1 below).
  2. Organisation – “Organisation makes a system of many appear fewer”: In order to help people seeing the wood from the trees, Maeda introduces another acronym: “SLIP”. SLIP stands for: Sort, Label, Integrate, Prioritise (see Fig. 2 below).
  3. Time – “Savings in time feel like simplicity”: The underlying idea about reducing the user frustration caused by time wasted. When any interaction with products or services happens quickly, we attribute this efficiency to the perceived simplicity of experience. If speeding up a process isn’t an option, Maeda suggests that giving extra care to a customer will make the experience of waiting more tolerable.
  4. Learn – “Knowledge makes everything simpler”: Maeda introduces another acronym here, called “BRAIN”. BRAIN stands for: Basics, Repeat, Avoid, Inspire, Never (see Fig. 3 below). He also points out that the best designers are those who marry function with form to create intuitive experiences that we understand immediately.
  5. Differences – “Simplicity and complexity need each other”: The more complexity there is in the market, the more that something simpler stands out. While technology is growing in complexity, there’s a clear benefit to differentiating by offering products which are simple and easy to use. That said, establishing a feeling of simplicity in design requires making complexity consciously available in some explicit form.
  6. Context – “What lies in the periphery of simplicity is definitely no peripheral”: This law relates to a common trade-off between providing people with direction versus leaving them to explore for themselves. “How directed can I stand to feel?” versus “How directionless can I afford to be?”
  7. Emotion – “More emotions are better than less”: Even though simplification is the core premise of Maeda’s book, he makes the case for adding functionality – and thus violating the first law of “Reduce” – arguing that this is allowed for the “right kind of more: feel, and feel for.”
  8. Trust – “In simplicity we trust”: The law of “trust” is about the tension between the effort required to learn about a system on the one hand and the trust offered by the system on the other.
  9. Failure – “Some things can never be made simple”: Maeda acknowledges that not all attempts to create simple products will succeed. He states that “there’s always an ROF (Return on Failure) when you try to simplify – which is to learn from your mistakes.”
  10. The One – Simplicity is about subtracting the obvious, and adding the meaningful: The tenth and last law of simplicity is to capture a number of ideas which Maeda felt didn’t fit neatly into a single law. He therefore devised three “keys”: Away, Open and Power (see Fig. 4 below).

Main learning point: Even though “The Laws of Simplicity” was published nearly ten years ago, its content still feels incredibly timely and relevant. If anything, for me the book makes it clear that ‘simplicity’ is not as straightforward as it might sound. Maeda provides some key principles that underpin the concept of simplicity, whilst being honest about some of the challenges involved in simplifying products.

 

Fig. 1 – SHE (Shrink, Hide, Embody) – Taken from: John Maeda, The Laws of Simplicity

  • Shrink: As technology is shrinking, i.e. becoming ‘smaller’ and yet more powerful, this approach is about designs conveying the impression of being smaller, lesser and humbler. This means that as a user your expectations of the product will still be fulfilled even though you might not think so, purely from looking at the product.
  • Hide: “Hide the complexity through brute-force methods.” The Swiss army knife is a great example of this technique since only the tool that you wish to use is exposed, while the other blades and drivers are hidden.
  • Embody: Maeda makes the point that as features go into hiding and products shrink, it becomes ever more important to embed the product with a sense of the value that is lost after Shrink and Hide. It’s about creating the perception of quality, which can be done through marketing or product design.

Fig. 2 – SLIP (Sort, Label, Integrate, Prioritise) – Taken from: John Maeda, The Laws of Simplicity

  • Sort: Sort and group information
  • Label: Each group needs a relevant name
  • Integrate: Whenever possible, integrate groups that appear significantly like each other
  • Prioritise: Using Pareto’s 80/20 rule is a helpful tool when deciding where to start

Fig. 3 – BRAIN (Basics, Repeat, Avoid, Inspire, Never) – Taken from: John Maeda, The Laws of Simplicity

  • BASICS are the beginning
  • REPEAT yourself often
  • AVOID creating desperation
  • INSPIRE with examples
  • NEVER forget to repeat yourself

Fig. 4 – Three keys (Away, Open, Power) – Taken from: John Maeda, The Laws of Simplicity

  • Key 1 – Away: The main principle here is that “more appears like less by simply moving it far, far away.” When you do outsourcing or moving a task it’s important to retain a level of communication with this task.
  • Key 2 – Open: “Openness simplifies complexity.” Examples of this approach are “open source” technology and Application Programming Interfaces (‘APIs)’. Public availability is the main characteristic that both examples have in common.
  • Key 3 – Power: “Use less, gain more.” This principle is quite literally about the dependency on (battery) power for a lot of devices and technologies. The idea is that not having enough (battery) power doesn’t necessarily need to be total disaster: “in the field of design there is the belief that with more constraints, better solutions are revealed.”

Related links for further learning:

  1. https://en.wikipedia.org/wiki/John_Maeda
  2. http://usabilitypost.com/2010/02/07/the-laws-of-simplicity/
  3. http://betterexplained.com/articles/understanding-the-pareto-principle-the-8020-rule/
  4. http://www.ted.com/talks/john_maeda_on_the_simple_life?language=en
  5. http://www.quora.com/What-are-examples-of-emotional-design
  6. http://thenextweb.com/apps/2012/02/15/review-how-a-simple-list-app-called-clear-may-change-how-we-use-our-devices-forever/

Image credits: http://www.tedxtokyo.com/en/talk/john-maeda/

john_maeda

Back to top