Scaling design the way

Here’s a fantastic, frank and inspiring 20-odd minute talk from Stuart Frisby, Director of Design at, talking at Clearleft’s Leading Design conference recently.

Stuart notes a number of important enablers that helped him work with the business to scale design from 5 people to over 200:

  1. Initially, recruit designers with broad skills (especially technical skills) to integrate with a highly technology- and data-driven culture. Go for specialist roles later on.
  2. Embed designers into each team, and use their skills in visualisation, prototyping and research to help bridge Engineering (technical) and Product (commercial).
  3. To prove the value of design, demonstrate how it adds value in terms that the company already understands. In’s case this was through A/B testing and conversion improvement.
  4. Once developed and proven, offer design’s playbook of tools and techniques back to the business as a ‘gift’. Stuart’s examples include the use of design systems to standardise user interfaces, team skills assessment processes and internal knowledge sharing meeting formats. When these tools are adopted by other teams in the company, everyone wins.

I did pick up some concerns stemming from Stuart’s talk too.

  1. Stuart mentions that prior to his promotion through the company, clear role definitions and career paths for designers did not exist. One has to wonder why. To people outside of design, this could betray a lack of professionalism in design that you wouldn’t expect from other business functions.
  2. The 200 designers at don’t report into Stuart as Director of Design. I found this strange, particularly the comment that Stuart does not have control over salaries and promotions. Which Finance or Marketing Director would allow this to happen with people working in their subject area?

Those considerations aside, this is a brilliant talk that lifts the lid on what it’s like to lead design in a rapid-growth, highly successful digital business.


How to identify that agile isn’t working for you (and what to do about it)

Dilbert Does Agile
Dilbert Does Agile

I’ve now had the pleasure of working with five different kinds of agile in different companies with different teams and different cultures.

It’s hard to make an objective assessment of a methodology’s impact when you’re using it and doing your darnedest to make it work. However being critical of ‘normal’ practice is a default for me. And I have reason to suspect that teams use agile to paper over the cracks of poor leadership, bad practice, and poor discipline.

During this time working with agile teams I’ve identified a few areas where you can quickly tell if things aren’t working, and what you can do to turn things around.

1. It’s hard to tell if the team is delivering measurable business value

Agile teams use a lot (I mean A LOT) of internal KPIs and metrics. Burndown, sprint velocity, story points. To the uninitiated these words mean nothing, and nor should they.

If the team appears to be busy and there’s code being tested and put into production, but commercially there’s no change in performance, you have a problem.

2. The team don’t know why they’re delivering what they’re delivering

It’s easy to tell a workaday agile team full of developers, business analysts, and scrum masters. There’s usually plenty of focus on stand-ups, tickets, progress, and blockers. But amongst all the ‘busy work’ that’s being done to get code written, it’s easy for people to forget why the team exists.  As soon as that happens, the team isn’t in a good position to challenge priorities or find faster ways to deliver more value.

If you ask one of your agile team why they’re doing what they’re doing, and the answer doesn’t resonate with your overall strategy, then you have a problem.

3. Product Managers talk about the volume of work delivered

A Product Manager’s primary responsibility is to deliver business value – and importantly, to role model the behaviours that come with this responsibility to the team. There’s any number of ways that a PM can impact on this, whether it’s in her roadmap, her decision making, the way she runs meetings, or her approach to prioritisation.

When Product Managers stray away from talking about the value their product has delivered and into the volume of output from the team, then you have a problem.

4. In the rush to deliver, quality gets neglected

The good thing about software is that objective quality is easily measured. Software either works or it doesn’t. However, the bad thing about software is that everyone has an opinion about how it works.

The true test of how well software works is when it’s put to its intended use. Users and customers are the best judges of quality. If users and customers aren’t adopting the product, they’re getting errors or bugs, or they’re struggling to use it and it’s showing in your commercial KPIs – then you have a problem.

5. The target design never sees the light of day

‘Agile-istas’ (those who promote agile above everything else) promise that the methodology’s emphasis on breaking things down into smaller and smaller chunks and making requirements negotiable means that value gets delivered sooner. On the whole I buy that philosophy. But in my experience, this can give the team the power to dodge tackling tougher challenges.

The emphasis on speed of delivery focusses the team on what can be done now, rather than on how the solution ought to work for users, and why. Sometimes there’s value in a really great experience rather than a ‘Minimum Viable’ experience. The hard work of the design team to research and construct the best user experience is left gathering dust on the shelf. I’ve seen developers losing interest in the design because they’re too busy delivering story points.

When the design you’re shown is way off what ends up being delivered, you have a problem.




Provocative ideas to shape your digital strategy

Here’s a short summary of a talk I gave at Biglight’s Customer Experience Explored event in London.

I came up with the topic in an effort to provoke the audience into thinking differently about the intersection of customers and digital, particularly when Amazon’s presence in  the UK retail and e-commerce space is looming large.

Unfortunately not all of the talk was filmed, but to see the last 5 minutes of my performance, hop on over to YouTube.

Getting the most impact from user experience

Over the past 10-15 years, the practice of user experience within organisations has matured significantly. But why do some organisations get more benefit from UX than others?

The answer stems from how UX is positioned within the organisation, how the organisation measures the success of its investments, and how UX groups seek impact. Those who report having a high degree of impact behave differently to those with low impact.

Continue reading “Getting the most impact from user experience”

The thought before the click: the locus of attention

This is the second in a series of fundamental user experience concepts useful for understanding people’s behaviour when using the web and mobile.

Scrabble Pieces VectorLet’s play a little game.

  1. First, think of your first name.
  2. Now, think of the last letter of your surname.

Neither of these are difficult tasks, but it takes longer to complete the second than the first. This is an illustration of the difference between conscious and unconscious thought. While your first name springs to mind immediately, you had to work a bit harder to come up with the last letter of your surname.

Meanwhile, when you were completing the tasks you had to switch your attention from this page to the task and back again. In doing this, you had to adjust what’s called your “locus of attention”.

Continue reading “The thought before the click: the locus of attention”