N.

Navigating Design in Transformation

Words have meaning.

Words can be defined in many ways – and can be misinterpreted in just as many ways depending on the context in which they are used.

Have you ever had a conversation about ‘design’ with a development team only to find half-way through the conversation that you are talking about the UI and the Customer, and they are talking about the design of the database structures, the code, or the technology stack?

Read more
C.

Can teams “innovate” in organisations that aren’t design-led?

Over the years I’ve seen the approach to innovation vary in organisations. Where organisations are design-led an innovative approach is part of the cultural fabric or ethos of the organisation. This can be seen in organisations like Apple and Tesla. It can also be seen in many start-ups, where a founder, in pursuit of defining a vision sees obstacles as challenges to be solved and the perceived risk of large organisations as opportunities.

Keep reading…

C.

Conduct user research WITH – not ON – your Customers

We all like to think of ourselves as responsible designers and researchers. We follow design methods that take into account our experience, we analyse data and we follow user-centred design methods that involve testing with our Customers. But designers who follow design methods don’t commission ALL research that is conducted. Research is often commissioned by project managers, proposition teams, sales teams or others who have various agendas that revolve around saving time, managing scope, conforming to budget, plugging revenue gaps, or fulfilling other less customer or design-centric reasons.

Keep reading…

D.

Delivery, inertia and the micro-experience in UX

Micro experiences can be delightful artefacts to design and use. They are designed with care and crafting and seen as completely standalone pieces of functionality that are meant to delight in their simplicity and usefulness. But how standalone are most pieces of functionality? How often are these small, simple pieces of functionality part of a larger User Experience?

Keep reading…

I.

Is your organisation ready to “fail fast”?

“Ever tried. Ever failed. No matter. Try again. Fail again. Fail Better.” Samuel Beckett

Fail fast is a nice alliteration – which is one of the many reasons I think it has gained such momentum in the product design space. “Succeed fast” or “iterate quickly” doesn’t roll off the tongue nearly so well.

Fail better seems only moderately more hopeful. How many times can you fail fast before you need to succeed in something? Small organisations – e.g. start-ups – might be better positioned to fail fast – if only because their idea-to-launch cycles can be quite short, and the ability to pivot more easily done.

Keep reading…

T.

The importance of understanding “will” vs. “can” in usability testing

In my experience it never fails that many stakeholders come to usability testing with the question of “will” vs. “can” Customers use their products or services. It’s a natural and desirable outcome of conducting user research. A positive answer can lead to acceptance of a business case, sign-off on a product launch, or pre-mature glory for the product owner and team. A negative answer can help to avert a disastrous build and launch.

Keep reading…

W.

Whatever happened to discovery?

It’s a cool, sunny late Autumn Sunday morning. You live in the countryside; the nearest village is a mile away. It’s been a while since you bought a Sunday paper. But for some reason, you want one. Instead of getting in your car, as you normally might to do to drive the mile to the village to buy milk or go to the pub, you decide to walk. There are paths through the fields behind your house that take you to the top of a hill and then down to the village – which is actually less than a mile to walk.

Keep reading…

P.

Prototyping as an ethos

When car manufacturers design a new automobile, they develop requirements, conduct research, draw designs, make scale models, test scale models in wind tunnels, computer model their ideas, build full-scale prototypes, test them, and iterate the designs – all of this before putting them into production. What they don’t do is go right from drawing them on a piece of paper or having a pocketful of highly subjective ideas to putting them into production.

So they don’t base their decisions on a paper prototype or a list of personal ideas. Why? Because a car is a 3 dimensional experience. It is an experience of the senses. It is an interactive experience. You really need to understand it before you put it into production. Mistakes carried through into production would be costly.

Keep reading…

N.

No Virginia… you are NOT the user

As individuals, we have many user experiences over the course of a day. Certainly over the course of a week, month, year… indeed a lifetime. In a sense, we become experienced users over time of many things, and remain inexperienced users of many other things. In some instances we feel we can extrapolate the experience by comparing it to ‘like’ experiences.

When it comes to designing apps for use on the internet, software, or web, everyone is an experienced user. At least that’s the impression I’ve gotten over the years in dealing with clients and colleagues.

Let’s take clients. They are often made up of many constituents: a business owner, stakeholders, marketers, project managers, IT geeks, editors, business analysts, and possibly even cobbled together components of a web team. Each of them has an opinion. Each of them view digital projects in terms of their own interests, experience, discipline and exposure (or lack thereof) to similar types of projects. They also have their own agendas – which are a double edged sword – that guide their actions.

Keep reading…