Product and Service Design
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.
So, I feel caught in a language loop recently. I talk about (and practice) User Experience. I do these things in the digital/mobile space. And really, I’m mostly focusing on good, strategic paths to design.
But all of it is an illusion.
User experience is pervasive. It is ubiquitous. Like air. And I don’t design air… I breathe it, I need it to live, I experience it, it’s all around me. It’s ubiquitous too.
User experience is about more than just digital experiences. If we accept that it is pervasive, ubiquitous, we have to accept that it extends well beyond our digital boundaries. But we most often hear about “UX” in relation to developing digital experiences.
I came across this again the other day. I’d forgotten about it – which in its own way is one of the lessons of the video. Every time we stop to play, and allow ourselves to be creative in our thinking, we all too quickly become adults in implementing it. This is a reminder not to stop playing.
I’ve been thinking a lot about the ‘edges’ of user experience lately. Most projects demand tactical UX – a bit of research, some wireframes, perhaps a prototype, and some annotation.
It slots neatly into place in a project process.
But ‘User’ experience isn’t quite so tidy. Actual user experience is ubiquitous, pervasive. It doesn’t have neat edges or clear boundaries.
I’ve been talking a lot about pervasive UX recently. In the sense of brand, to me it encompasses all of the potential touch-points encountered by a user on journey.
A few weeks before it launched, Tom Loosemore kindly invited me over for a preview of the Alphagov prototype. I was given a whirlwind tour of their agile process and some of the thinking behind their work. Not to mention a very dark – and thick – cup of coffee. Hey, I’m not complaining. I like it that way.
I met a few of the team (some of whom I already knew), and watched as a group of Government Communication types were taken through the same whirlwind tour – a mix of curious and skeptical faces making up the lot.
On the whole, it was a pleasant visit.
Over the last year or so I’ve come across quite a few people – technologists mostly – who keep asking the question – why can’t Agile be used as a methodology for both UX and development? Having spent some time considering it, I’ve put down a few thoughts below. Apologies in advance for the use of overused clichés.
So to begin, if you think about the differences between what we do as the differences between Architects and Construction teams working on buildings it might help.
Additions and renovations
Analogy: Think of this as modifying the interior of your home or building a small addition to an existing home.
Several times recently I’ve heard the word ‘skunkworks‘ mentioned. Most recently it was in a Guardian interview with Mark O’neill, the ‘leader of the government’s IT ‘skunkworks’ team – as well as CIO of two prominent UK Government departments.
I have to admit to being fascinated by the idea of a skunkworks capability in Government. Ideally, a skunkworks team is untethered from organisational rules and structures, and allowed the freedom and flexibility to focus on solving problems and pursuing real innovation – which often means failing a good number of times before (potentially) achieving a measure of success.