September 14, 2019

Werner Nomenclature of Colours

I was recently inspired by a designer’s project to digitise a 200 year old book describing colours seen in the natural world – see this FastCompany article for information on the project – and the project itself is available here.

I wanted to use the colours in various projects I was working on, and rather than have to keep switching in and out of the project, I found it easier to create my own personal swatch of all of the colours. In the spirit of the project, I have made the Photoshop/Illustrator swatch available for download here.

September 5, 2019

Product is a team sport

As many of my colleagues would attest, I love to use a good sports metaphor when talking about product goals or objectives. The reason for this is twofold; first, sports are a commonly shared experience, even if you don’t follow a particular individual sport or team, people know enough about it to draw understanding from the metaphor. Second, the skill, dedication and focus required to excel at a particular sport have particular lessons for any manager or person who wants to improve their own performance, or that of their team.  

With that in mind, and in my being a huge NFL fan (in the UK we are still a bit of a rarity, but increasingly less so), I felt that it would be worth writing a sports themed blog. The catalyst for this was listening to the season’s first episode of the Osi and Jason podcast, which in this instance featured them talking with Micheal Strahan. 

For those unfamiliar with the NFL, Jason and Osi are NFL pundits for the BBC, bringing their experience within the NFL to viewers and listeners on the podcast. Their recent podcast (listen here) with Micheal Strahan touched on the Superbowl winning season with the New York Giants and the culture and teamwork required to achieve that. Here are my top takeaways from the podcast.

 

Set standards and hold people accountable to them

 

One of the stories from the podcast was that if they made a mistake on the field, they weren’t worried about the coach/manager highlighting that mistake – they were more concerned with the rest of their teammates ragging on them for the error. They knew what was expected from them, and they didn’t want to let their team down – and they knew that they would be held accountable to those standards. 

 

The very best teams set high standards and consistently monitor against those standards. They don’t require a manager to monitor them, as they will be aware of what’s required and, more importantly, will hold other people to account. As a manager, I am often called into a team because someone isn’t pulling their weight, and they want me to resolve the issue by having a word. When this happens, I attempt to coach the team with ways to have this conversation themselves – it is more effort but has longer lasting value for the team as a whole if they can monitor this themselves rather than the short term impact I would have by having a single conversation. 

 

Recognise that everyone brings something to the team (and be ready to learn from them)

Micheal Strahan and Osi told a story about how they learnt from one another – as the veteran close to retirement, Micheal helped Osi learn how to study tapes and prepare for games. But learning was not one way – Osi also brought a different dynamic to the team, and taught Micheal new skills and approaches to preparation and training. 

This is a recognition that high-performing teams recognise that everyone has a different skill set and can bring something to the team. Not only that, but each team member wants to improve, and wants to help other members of the team improve as well. Incremental individual gains create an exponential improvement within them team.  

 

Be happy for others success (but be jealous as well)

A high performing team genuinely celebrates each other’s successes, knowing that one person’s success is the team’s success. But they also use that success to motivate themselves – learning how that person has reached those achievements, and wanting that success for themselves. This has to be done in a positive way, to stop the team from becoming a collection of individuals only seeking benefits on behalf of themselves. This is highlighted in the podcast from where Osi gets a record breaking 6 sacks in a game: everyone is happy for him personally, but it also drives the rest of the team onwards to raise their performance (culminating in 12 sacks for the whole game) 

 

Have fun to build team bonds

The whole podcast iterates how much both Osi and Micheal enjoyed being in each other’s company, and how they organised routines and structures into the team behaviours to lighten the mood and build comradeship. This is especially important to help build relationships during ‘slack’ times, so that when the pressure increases, you have got those bonds of trust and will be willing to work for one another. 

Equally enlightening is that they protected these routines from managers who wanted to change them or thought them inappropriate. I think the best advice here is that if it isn’t having a negative impact, then teams should be encouraged to build their own, authentic culture and if it ain’t broke, don’t fix it! This also applies to processes and ceremonies within the team: if they can adopt and adapt their own methodology to suit their needs, this is infinitely better than trying to enforce the ‘correct’ approach which may actually impede or drain the team’s enthusiasm.

August 1, 2019

Operational effectiveness and what we can learn from D-Day

The recent 75th anniversary of the D-Day landings gave us an opportunity to reflect on the enormous debt of gratitude we owe to the hundreds and thousands of servicemen and women who gave their lives to ensure that we may leave in freedom and prosperity.

The commemoration of these events brought alive what an astonishing undertaking the landings actually were; requiring a complex orchestration of logistics to get man, machine and weaponry all working in harmony to realise vitally important objectives.

The sheer scale of this achievement merits further examination to understand how they managed this combined effort, and to see whether any of these strategies could be applied within our organisations.

In doing so, I have taken my lead from a BBC programme “Normandy 44 – The Battle Beyond D-Day” (currently on YouTube). In the programme, the historian James Holland posits that the 77 day Battle for Normandy reveals the reasons for the success of the invasions, and that these were operational in nature, rather than the normal strategic or tactical viewpoints that are often cited. I will summarise some of the operational aspects that the programme highlighted, and then draw out the lessons a product team can take from it.

The dangers of over-engineering

The German war machine had applied superior technologies across different weaponry and vehicles. For example, the German MG42 was very high-powered, with a rapid fire rate and a high velocity, giving them a distinctive sound when fired. The Allied guns were under-powered in comparison – the British Brenn gun fired at a much slower rate and with a lower velocity.

This power came at a disadvantage however: the MG-42 became very hot when fired over a long period of time, meaning that the barrels had to be replaced else they would melt. On D-Day this resulted in the machine gun posts eventually falling silent at around mid-day, due to the barrels melting and not being able to replace them due to cut supply lines.

Another issue with the MG-42 was its slow assembly time: it took 150 man hours (or 9 months) to make a new gun, compared to 50 hours (or 3 months) for the Brenn gun. This gave an operational advantage to the Allies, who could replenish much more rapidly, and with a longer life cycle in the field before needing to be replaced.

This pattern was replaced with the German Tiger tanks, which were incredibly powerful and destructive, and were hard to destroy – but took 5 litres of fuel to move just 1km. The Allied Sherman tank had a longer range, only requiring 2 litres of fuel to move 1km. This meant that although the Tiger tank was a dominant weapon, it simply could not keep up with the Allied pace of warfare.

Lessons for product managers

Like in a game of Dungeons and Dragons, maximising your powers (product) in just one factor (feature) is highly likely to mean that other factors will be underpowered – and this can be used against you by a more agile competitor.

Product managers need to understand the context of how and where your product is going to be used, and the variety of different jobs it needs to perform for your customers. By understanding the environmental factors, you can ensure that you are not over-powered on a factor which is irrelevant in the market.

Second, designing lean and keeping the product as simple as possible, with minimal technical debt, gives you a massive advantage in agility, allowing you to outmanoeuvre bigger and ostensibly more powerful rivals.

Responding to the facts on the ground

In the First World War, it took both armies 4 years to adapt to the conditions. In the Battle of Normandy, it took 2.5 months.

The military now use a specific term for this type of learning – the OODA Loop – which provides a framework for applied learning during operational activities. The theory is that the side with a faster OODA loop will be more likely to succeed than the side with a slower loop – as they will be able to respond to the new realities of the environment faster, and will therefore start and then continue to set the pace of change within that closed environment – leaving the other side to be reactive to those actions.

This was evidenced within the Battle of Normandy – for example, the Guards Armour Division changing their basic operating battle group from being 2 distinct brigades (1 tank brigade; 1 mobile infantry brigade) to a unified regiment made up of both tank and motorised infantry. This closed the gap between Allied & German forces in terms of firepower, whilst retaining their superiority in speed and maneuverability. The German forces were not able to sufficiently adapt their tactics to this change in their environment.

A further disadvantage for the German troops was the elongated chain of command. Panzer divisions were ready to be deployed to support the front line of Normandy, but could only be moved on the command of Hitler – and nobody wanted to wake him up to ask permission.

Lessons for product managers

Scientists now understand that the theory of evolution is not survival of the fittest, but is in fact the survival of the most adaptable. Species that are able to change and adapt as the environment changes around them, are much more likely to be successful than those that have developed a specialism that is tied to specific behaviours.

I believe that this understanding has a direct corollary with the evidence of success in Normandy, as well as with organisational success. Those companies that are able to diagnose the environmental factors and continually and rapidly respond to those inputs, are more likely to succeed than organisations who do not have this capability.

It is paramount that product teams exercise their ability to adapt to continuous change – it’s not about being first and fastest once, but being able to learn and respond to your observations, and then to repeat that process without causing stress within the team. By necessity, this means that decision making has to be pushed down to the lowest point: these people are closest to the change

Defensive strategies only work in limited circumstances

Defenders have a difficult balance to maintain during a battle; they have an advantage due to the ability to make extensive preparations to bolster strategically important locations to enhance their overall position and strength – but this advantage comes at the weakness of having to replenish those positions, and (by definition) they are held in place.

On D-Day, the German forces held a distinct advantage at the beginning of the invasion. Allied troops needed to evade the fortifications and structures inserted into the beach as coastal defences, and soldiers were hunkered down in heavily fortified concrete bunkers that protected them from enemy fire – on Omaha, this was manned by just 44 soldiers. However, as the day wore on, their ammunition stores gradually reduced, and with no operational plan in place to replenish, these positions eventually became redundant and were overpowered.

Similarly, a strategic objective for the Allied forces was to seize control of the important town of Caen within the first 24 hours of landing. Instead, the infantry had ground to a halt, and was being held to a seeming stalemate against the German forces. Although strictly true in terms of inches and yards, taking a wider perspective reveals a superior operational capability slowly providing more strength to the Allied forces. Namely – reinforcements.

The Allied army were continuing to bring in vast resources of manpower, machinery and weaponry through their man-made harbours; the German forces were simply unable to re-supply their front lines fast enough. With US forces starting a second initiative in St Lo, the German forces were stretched too thinly across too many locations, with the resultant deterioration in strength finally resulting in collapse. (see https://youtu.be/8Lnxhw39EJ4?t=2817 for more information).

Lessons for product managers

This has obvious ramifications for product managers who are facing disruptive insurgents into their industry, as it speaks directly to the efficacy of any defensive strategy that they may put into place – you may be able to slow down an insurgent company in the short term (think London taxi’s successfully putting legal barriers against Uber), but unless you have the means to continue pumping money into those defences, it really is only buying you a limited amount of time.

The inverse is also true – if you are a disruptor, don’t be disheartened if your initial progress and growth reaches a plateau (as it will inevitably will at some point). This is the point to re-examine the landscape to get a wider perspective – what has your entry changed in the market? Has it created a fundamental shift that leads to a natural arbitrage in your favour? What can you do to press home your advantage (that isn’t necessarily measured in the extra ‘yards and miles’ of growth).

This same analysis should also be done in terms of technology shifts: my own personal experience of this has been in the shift from desktop products to cloud products, in two seperate companies. In the first, we acknowledged very early on that cloud would have a transformative effect on our industry, we couldn’t change that fact, all that we could do is buy ourselves some time with defensive strategies until we could migrate the product away from the desktop.

This acknowledgement was also present in the second company, but because no customers were asking for a cloud version at that time, the work to migrate technologies was deprioritised. Then de-prioiritised again. Even when the first few customers started to churn over to cloud replacements, we were locked in to delivering additional value on the desktop version – on the then mistaken belief that because cloud hadn’t really taken off yet, that it would only really be an issue a couple of years down the line. This turned out not to be the case, and only when it was almost too late did the switch kick in, but it meant that we had to manage that migration at speed, into a market with new competitors (who didn’t have legacy problems to deal with – making their response time infinitely faster), with what turned out to be a substandard product in comparison to newly minted companies.

Summary

Having a well constructed and thoughtful strategy is a necessity, but even more important is putting into place the right culture and structures to be effective through your operational endeavours. In the Battle for Normandy, this meant ensuring you had a steady supply line and continuing reinforcements. For product teams, this means identifying the critical points of your operating model, and being quick enough at continually improving those critical points iteration after iteration.

This means a strong learning culture is essential for success: those companies who are able to release, learn and re-orient based on those learnings to release again, are at a distinct advantage over companies who are more cumbersome and cannot learn fast enough.

January 9, 2019

Hummer & JTBD

Just read this great transcript of a Don Norman talk on Design & Emotion. The whole thing is worth reading, but this quote especially caught my eye, describing the exact reason why JTBD theory is so powerful:

Here’s a great reflective product. Owners of the Hummer have said, “You know I’ve owned many cars in my life — all sorts of exotic cars, but never have I had a car that attracted so much attention.” It’s about attention. It’s about their image, not about the car.

 

December 21, 2018

Maximising your impact in a new product role

I’m just about two months into a new product role with a new company in a new sector: a triple-threat of NEW. It’s taken me this long to start to feel a bit more settled in the role as I grapple with learning the ropes across a multi-variable set of factors.

This is my fourth product move, and it’s always been a bit of a jump into the deep end of product management. I’ve moved from law-tech to fintech to data viz and now on to cybersecurity, each one of them a different size of company and at a different stage of their product/company growth lifecycle – each bringing a different set of challenges to get your head around.

These beginning parts of a new job are hard work but fun – having to commit to an accelerated programme of learning about the product and domain, whilst taking charge of a product which is already in flight (with commercial commitments already baked into the product roadmap), alongside having to understand existing patterns of work and getting to know the team, and all without a safety net.

Although each new role has the same basic components, the learning challenge can often be very different. The learning challenge is a real opportunity to make a huge positive impact on your new product and for the whole business. I’ve collected together some of the behaviours that I have found can maximise your impact in the first couple of months in a new role.

But first, a note:

In every move I’ve made, without fail, new colleagues can always be guaranteed to say two things. First, they will mention how complicated the product is, and will tell you that people often find it difficult to pick up all the intricate and interwoven strands of the product. Second, they will ask some kind of “benchmarking” question e.g. “Is our discovery phase normal?” “Do our dev team take longer to finish a release than other places?” or other variations on a similar theme.

These are trick questions and you should absolutely do your best not to answer them (especially in your first week). There is no way that you can know how tricky or complex a product is in the first month – while you may get a superficial understanding of how the product works, and some of the moving parts that make it up, it will take a couple of months to really unearth some of the bigger technical issues.

Second, there is no such thing as normal in technology – there is only “normal for us” or “right for us” – if the company’s processes match the business and delivery model, then it is at least in the right range of normal. A good answer for the second type of question is “I’ve never worked in a place where people thought they were delivering at just the right speed”. Every company has things that it can improve – it’s your job to find them and make it happen.

Take the Chance to ask Dumb Questions

The first couple of months in a new role give you carte blanche to ask dumb questions – and the dumber the better! For the first couple of weeks in a new role, your new work colleagues will not expect you to have an in-depth and fully realised product knowledge, and will give you a get out of jail free card when you ask a seemingly dumb question. This grace period rapidly deteriorates, so you need to take full advantage to quietly question some of the assumptions behind historic product decisions and current business model and product strategies.

Utilising the classic 5 Whys Method can help you to really dig deep into assumptions from ideas that the company holds about the sector or industry it’s in, to the rationale for the most recent product release. It is given extra power when you are new in role because you genuinely have no pre-conceptions about the root cause, and you won’t unintentionally lead them a specific way. It will also accelerate your learning about the company and the way it sees the world.

Lean in to your product knowledge

If you are changing roles and you are in the same sector, you will have some knowledge to fall back on. If you have changed industries, now is the time to lean in to your accumulated product knowledge.

The reason you got the job (presumably despite other candidates potentially having sector experience) is because you brought a stronger overall product experience, which (presumably again) is what they were looking for.  Now is the time to really double down on that knowledge and examine the how and the why of your product processes, looking for areas that you could quickly improve with just a few tweaks. Despite the plethora of articles about “good” product management on Medium etc, many companies still operate within older paradigms.

The truth is, they want to be better, but don’t know where to start, and don’t know how to make this change while projects are “in-flight”. They need a catalyst to push towards being better. The good news is that you can be this catalyst for change, and the best time to do this is when you have just joined and are not emotionally involved in specific patterns of behaviour.

Embrace the idealised product methodology

Starting a new job gives you a licence to review how things are done within the company and make the changes that are needed to improve the processes. This gives you a great opportunity to embed best practices or to point out tweaks that could make a difference. There really is no better time than your first couple of months to make these suggestions – once you’ve been part of the team for more than 4 or 5 months, you’ll start to get used to these ways of working.

If you are starting in a new domain, you should be pretty much forced to model these kinds of behaviours just so you are able to do the day job. For example, with no product or domain assumptions to fall back onto, you HAVE to do the market and customer research on which your product relies. In doing so, you can bring in new schools of thought or methodology (e.g. JTBD or Design Sprints) that can help you get up to speed and can help the team build new insight.

A note of caution here to not take a cookie cutter approach to the new role: it’s not a case of taking what worked in your last role and re-implementing it. Take time to assess what’s going on in the business, what the objectives are, what the maturity level of the product team is – before you start making changes. What worked in previous roles may not be appropriate in your new circumstances. Your job is to make an evaluation of what could make the team better, and flexing your knowledge to meet those requirements.

Bust out your pad and paper and get designing

If you’ve got some design chops (hell, even if you haven’t), now is the time to dig out your pencil and paper and start taking notes on how your newly adopted product works.

This will be the only time you can come to the product fresh, seeing it through the eyes of a new customer, but with the additional training of a product manager. If you have problems working out what you should be doing as you onboard onto the product, then chances are, other customers will be experiencing the same problem as well.

If you don’t already have it, I recommend downloading a copy of Adobe XD, it’s a lightweight prototyping tool that is really simple to use to build out working versions of your product. It also allows you to add comments onto the prototype once you’ve shared it. You can quickly take screenshots of your product and put them into XD, and build out the workflow, noting difficult parts of the process as you go. It will act as a better memory aid later on than hastily scribbled notes.

Take opportunity to learn new skills & habits

Following on from my previous point, this is the time to push yourself to learn new skills and to really push yourself to do the tasks and activities that you always put at the bottom of your to-do list. For example, if you always put backlog grooming off in favour of other activities, make it a high priority item and commit to doing it well at the beginning of your tenure, whilst you don’t have thousands of other commitments crowding in on your time. Getting into the habit of backlog grooming (in this example) should then hopefully continue once your to-do list has grown. You are already out of your comfort zone, so embrace the anxiety and get yourself in the right frame of mind for continued and consistent performance improvements.

Finally…do the things that need doing

Seems pretty obvious, but sometimes the obvious things are the things that get overlooked. When you start in a new role, you’ll definitely notice a lot of things that could be improved, and lots of things that are simply not being done because no one else has the time. Don’t ask permission. Don’t wait and do nothing. Pick them up and do them. Now. Not only will you be picking up critical stuff for the business that people will notice straight away, you’ll get involved into the rhythm of the company very quickly and become trusted as a safe pair of hands that gets stuck into problems (assuming, of course, you make things better!).

May 25, 2018

Google Announcement UX

I’m loving the new announcement window that Google are using for Sheets (see pic below). Rather than the normal,ugly pop-up style window, this announcement blends into the application seamlessly, making it less jarring – but also much more noticeable – it really stands out from a normal message you’d expect to see there.

NEW - exmaple - google

 

 

May 23, 2018

Re-learning how to use frameworks by using a beginner’s mindset

One of the things that I am enjoying most about my current role is the opportunity to mentor new product managers as they transition from more technical roles and begin to learn the “craft” of product management.

I say “craft” because I genuinely believe that the role of product manager is comparable to those artisans of yore; much like an apprentice stonemason or carpenter had to learn when and how to use each specific tool to create the right final product, a product manager must learn when and how to use the right frameworks and processes to get the best result. Unlike a carpenter or stonemason though, a product manager should never truly finish his apprenticeship – there is always more to learn!

Taking a newly minted product manager under your wing and introducing them to some of the ‘core’ frameworks and concepts is a rewarding task because it allows you to look at those frameworks with new eyes. Over time, with familiarity, one can forget the power within those frameworks, and become blasé about how to use them and the value that is created by engaging in the process of utilisation.

A recent example is the business model canvas, probably one of the most widely used frameworks within the industry, and certainly one that I have relied on to help shape each of the products I have managed. Through constant use of this framework, I know I have a tried and trusted routine for how I approach a new problem, one that has worked well for me, and one that helps me think through the problem in a way that works well for me. It was this method that I was passing on to my mentee, when he asked a “beginner’s question” that temporarily floored me:

“Do you have to start at the same place, or can you start anywhere on the canvas?”

This question instantly made me take stock of how I applied the framework learnings: I always started at the value proposition, as this made rational sense to me – I then moved through to customers, as defining these can often help iterate back to improve the value proposition. I then work my way through the customer side, before moving back onto the resources and relationships side. But his question was a good one: Do we need to start at the value proposition? Or the customer segments? Does starting elsewhere impact the efficacy of the framework?

We decided to test it out, by starting at revenue streams: our company had stated that it wanted to change revenue streams on an existing product from licence fees to a SaaS model: if we took that model as a starting point which couldn’t be changed, what would that mean for the rest of the business model canvas? Would using this as the starting point allow us to get really into the details of the rest of the canvas?

The answer – obviously – was yes. From a fixed starting position, you can easily start to see how the rest of the picture becomes filled in. From revenue streams, we moved directly into customer relationships and channels: a SaaS model assumes that we would acquire customers in a very different way from the direct sales and relationship building activities we perform today. This also impacted on our customer segments – rather than building a product that appeals to the purse-holder and their specific pain points, we could build a product that would appeal to the end-user themselves, and directly target them with well-placed channel activities. And so on and so on.

Some of the ideas that we came up with as a result of this exercise were really exciting for us, and although we don’t know whether we would have got to the same place if we had used the tried-and-trusted method, some of the insights we created were, I believe, unique, because they approached the problem from a different viewpoint.

This was a great lesson for both of us: for him, a crash course in a framework that should serve him well throughout his product management career, and for me, that approaching familiar frameworks with a beginners mindset can really pay dividends.

February 2, 2018

idiosyncratic bit of UX

I recently welcomed a new puppy into our extended family, which has been great fun for us (especially the kids). As part of new ownership responsibilities, we had to transfer ownership from the breeder to ourselves, via the microchip technology which we are legally obliged to have here in the UK.

On registering ourselves on the Kennel Club site, I saw this little piece of idiosyncratic UX:

UX_mayhem

If this was any other website, I’d say this was poor UX: you are creating a huge list of potential items that could be included, most of which will never be used at all – meaning that for the majority of people, they have to do a huge scroll down to get to Mr/Mrs/Ms.

But this IS the kennel club – they probably do have a higher proportion of colonels, earls and duchesses using their website.

I’m sure that HRH is probably unnecessary though.

 

December 14, 2017

Designing better departures

I have been travelling quite a lot recently – meaning that I have spent far too much time sitting in various airports around the world, praying that my plane won’t be too delayed while eating comfort food with an impossibly small & blunt knife and fork.

During these long waits gazing at the departure boards and willing my plane to arrive, I realised that airports have solved their departure board problem in a number of different ways; the same problem has led to a number of different solutions.

For instance, Heathrow has boards which look a bit like this:

2113571_c03cf1f0

It has all the information you need: flight departure time, destination, flight number, status and gate number (or when you can expect to see the number).

Denver International Airport has approached it differently:

image

The boards still contain the same information, but rather than organising by flight time (as in Heathrow), they organise by destination A-Z. In a straw poll of fellow travellers, we agreed that the Denver board was easier to use: it was easier to orientate yourself to the way the information was organised and judge where your flight would appear on the board.

Finding your flight

With departure times used as the organising filter, it becomes harder to judge exactly how far your eyes have to move to find what you are looking for – during my time at Heathrow I observed several people looking at the departure boards, digging around in their pockets to find their tickets, look at them, and then look back at the departure board. I sidled up to them and asked one of them why they were looking at their ticket – the answer was that they were double-checking the time they were leaving so they could be sure they were looking for the right flight.

My contention is that people don’t commit to memory the exact time they are flying,  just the approximate time – so when looking for their flight they need to double-check. This isn’t the case for the destination – everyone knows exactly where they are going – so it makes using the departure board easier – you find the first bit of information, which you then confirm with airline carrier and time; as opposed to having to search by time, check what time you are flying, find that time on the board, and then confirm it’s correct.

Confirming it’s the right flight

The second stage for finding your flight is confirming that what you have found is indeed your flight. From the Denver board, this is done via the time of the flight (once you see the time, you recall your flight time – no need to look at your ticket as you’ve already matched the destination),  and then via the airline carrier. This is done by having the name and logo for each flight as the next piece of information.

The Heathrow board has as the 3rd confirmation piece of information the flight number – which is no good to anyone except the most committed plane-spotting anorak. I don’t think I’ve ever even attempted to remember the flight number – but I do know who I am flying with. I don’t think I’m the only one either – a little surreptitious look around the plane as people completed their boarding cards on the plane into the US confirmed this for me – pretty much everyone I saw had to locate their tickets to fill in the flight number detail. So again, it’s not useful information to help you find your flight on the departure board.

Design choices

There are a myriad of different options for displaying the information – additional status fields, headers for each column, colour choices and so on. On first glance, I prefer the Heathrow option – it has a very minimal look and feel, with red text to draw attention to urgent issues. The Denver board in comparison looks very cluttered with the large logos in the third column.

On deeper consideration though, there are a number of things wrong with Heathrow’s board: in particular, the destination is in a strident yellow colour, making it ‘pop’ more on the board and drawing the eye – which means that you are looking at the destination rather than departure time (which is how it is organised). This makes it more difficult to navigate the board. And while the Denver board looks cluttered, the ‘mess’ helps people to identify their relevant flight; although it doesn’t conform to current design trends, it does meet “good” design in terms of helping the user complete their “job to be done”.

What I hope this illustrates is that there are always going to be a number of ways to solve a particular problem, and that while a particular solution may meet that challenge and be reasonably useful, it doesn’t necessarily do it in the most optimal way. Even with a minimal amount of customer research, you are able to uncover behaviours that can help you to design a much better solution.

 

November 9, 2017

Brexit and the Condorcet paradox

The Condorcet paradox arises out of voting intentions where any decision available from the choices would be opposed by the majority of voters within the system. In the simplest version of this paradox, imagine that there are 3 choices: A, B or C. Majorities of the voter demographic prefer choice A over choice B, prefer B over C, but prefer C over A. In this situation, whatever choice “X” is eventually made, the majority of voters prefer “not X”.

concaderte

It’s becoming increasingly clear that sentiment towards Brexit is heading towards being a real-time example of a Condorcet paradox, where any decision looks likely to annoy over half of the electorate. The latest YouGov survey shows a trend towards a majority of people feeling that the UK was wrong to leave the EU (45% against 43% who felt that it was the correct decision). However, the numbers that – but the numbers that underpin that trend show a clear “soft middle” of 30% who either want a soft Brexit or 2nd referendum.

brexit20direction-01

Although the “continue with negotiations” answer is at 40%, further questions in relation to a “no deal” Brexit indicate that support for this option is currently at 32% (with 51% opposed). 57% of the respondents felt that a “no-deal” option would be bad or very bad for the UK.

So we are left in a parlous state – there is currently no appetite for a no-deal Brexit, so the UK Government must seemingly avoid that at all costs (although it seems as though they are determined at least to continually flirt with that possibility as an option, perhaps as a negotiating tactic). Similarly, if the Government was to go for a “soft Brexit”, perhaps elongating the transition period or softening it’s stance on freedom of movement, it would face a challenge from the previous 32%, alongside the 32% who want to reverse the original decision. And if the UK decided to remain in the EU, it would likely be challenged by the hardline and soft Brexiteers.

This is likely to continue to change as more becomes known of the likely shape and cost of Brexit, but it would need to change by quite some margin if the UK is to avoid a long period of disruption from the “annoyed majority”.