Digital product delivery and its impact on businesses, teams and people.

Month: September 2010

What is UX – The many faces of user experience.

The many way’s I’ve described UX

What is UX (1)

User Experience is an umbrella term for a series of different disciplines:

  • Usability
  • Accessibility
  • information Architecture
  • Interaction Design

but certainly not interchangeable with web developer, it’s true to say that some web developers do some maybe all of the above but in the most part their job is about cutting code to create products. Also, some user experience professionals do cut code but it’s not their primary role.

Lets not also forget that user experience operates outside of the web, so customer experience tends to refer to the experience a person has with a brand across all it’s platforms: in the shop from, customer service calls, marketing materials etc. Where as Human factors and Ergonomics tend (??) to refer to products not services.

What is UX (2)

UX activities give us a unique insight into how the customers interact with our product and service but the product and services only really exist to improve the bottom line of the organisations who commission them. 

UX therefore should also be about defining and measuring business goals and validating the outcomes in terms of customer acceptance and business realisation. 

What is UX (3)

 “A person’s perceptions and responses that result from the use or anticipated use of a product, system or service.” – ISO 2941-210, (Thanks to Allen Caeg)

What is UX (4)

UX is the sweet spot between business, technical and customer requirements.

What is UX (5)

UX works across three elements of service delivery. 

  1. Strategy I.e goal definition
  2. Asset delivery i.e Outputs
  3. Measuring the outcome

Depending on how you’re engaged on a project you will view UX differently. 

Suppose we view “service delivery” as product lifecycle with 4 key phases. 


  1. Definition
  2. Design
  3. Development
  4. Testing


It’s easy to see how the role of a UX professional won’t fit easily into the definition I gave in what is UX (1)

Phase 1. Deals primarily with early stage tasks, setting out the business case for change, requirements analysis. Here a UX professional will use research techniques to evaluate the opportunity to help set the business goals for the project. There are some research techniques which can be used but very little outputs from IxD, IA etc. at this stage

Through phase 2. and 3. Were moving into the realms of creating outputs to support other functions delivering. Here IxD, IA etc can and do play a cruital role. It’s in this phase that most UX professionals exist. 

Phase 4 is where UX professionals again provide a strategic role. Did the delivery meet the project goals?

All this rests on the premis that a project needs to pay equal weight to: business, technical and customer needs.

UX plays a role in all four phases although traditionally these roles are given different job titles. Business Analys, Change consultant, web designer etc. etc. The skills a UX professional has are relevant to all these job titles. 

Job titles are a way for a company to define and constrain a persons role to fit it’s individual needs and area of responsibility. The skillsets though (as described in the diffrent UX roles) are present in most roles engaged in product or service delivery.

What is UX (6)

A way to chat up the only girl at a geek-up

What is UX (6)

What [Guru X] tells us it is.


Feature trading to facilitate change.

Those who have worked with me will know that I can sometimes be as frustrating as hell! I work by a let’s get it done mentality; rules be dammed. Why, I wonder, follow the rules when the bureaucracy actively prevents humans acting reasonably to work together to bring a project to fruition. Trust in enlightened self interest I say!

The fear is, of course, that at some point another’s view or agenda will take precedence, diverting the project from it’s original goals. We spend weeks and months defining and tying down, the how’s to ensure that everyone knows what they are responsible for. These rules are ultimately designed to mitigate the financial risks of the organisations we work for.

There are real constraints though: a goal or vision must be defined and measurable, the outputs must be declared and the outcomes must be measured. Project plans, milestones and checks and balances exist to ensure the successful delivery of the project outputs. After all, we are ultimately constrained by time or money and usually both.

By measuring the project at the vision or goal level we are able to determine if a project has succeeded or failed, without having to legislating for every individual action. Conversely the act of legislation prevents creative thinking, and learning, from happening ensuring that efficiency and positive feature changes are not discovered.

By denying the activity of continual discovery we are unwittingly adhering to the fallacy that we can accurately predict future wants and needs. I.e. Future efficiencies and better functionality cannot be explored as the problem space is illuminated because they weren’t declared ahead of time.

Where change is recognised, the business case is presented and a change request is created. Usually though this is a one way street. Features are taken out while project expenditure remains the same and additions always increase the project expenditure. Reinforcing the need to restrict change as “scope creep” is always presented as having a negative impact on a project.

I therefore suggest creating an feature/output trading scheme. Whereby all change regardless of the impact is assessed this includes the financial impact; Good or bad. If the impact is positive (for the project) put the balance in the project bank, for when something goes wrong. If it’s negative and you have something to spend, spend what you have. If there is nothing in the bank to spend, you at least have the data you need to decide the next step.

For example

It is discovered that feature a/output b is no longer needed. An impact assessment is drawn up showing the impact of not doing it, including financial saving. If agreed, It’s withdrawn and the saving is added to the project balance. Later if feature c/output d is required, an impact assessment is drawn up showing the impact of doing it. If the change is agreed and there is a positive project balance the costs are transferred and the change is committed. If there isn’t a project balance a business case us drawn up and more fund requested with the data from the impact analysis used to support the request.

I’m in no doubt that this simple idea is unofficially in practice in most projects. Except, that when something goes wrong and you need to understand who’s financial responsibility it is (I.e. Who’s to blame) the whole house of cards can comes tumbling down. As it is unofficial: Change, financial impact and trade offs are not captured and therefore the problem can not be measured against the original brief.

By acknowledging the reality of the situation in a transparent, documented approach we can embrace change, allow new discovery to flourish knowing that at a later date, as long as the bank account balances, everything is okay.

p.s. for any agile practitioners out there i know an agile approach can facilitate change as described above. Agile isn’t a pervasive methodology for most of the clients i work with.

© 2020 Matt Goddard

Theme by Anders NorĂ©nUp ↑