UX and the Art of Digital Appropriation

UX and the Art of Digital Appropriation

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.

Pervasive UX – Who is Responsible?

Pervasive UX – Who is Responsible?

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.

Agile as the process

Agile as the process

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.

Walking the line between Skunkworks and Business as Usual

Walking the line between Skunkworks and Business as Usual

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.

Do UX tools help or hinder?

Do UX tools help or hinder?

For me UX has always been about contact with real people in the process of collaboration, workshops, design, prototyping, testing and iteration. Which is why lately I’ve been thinking about the growing reliance UX has on tools like Axure in our day-to-day work. I’ve been around long enough to watch UX grow from an adjunct to other people’s roles to a profession of some importance in the digital space (see my post ‘Is UX Returning to being a Multidisciplinary Role’.) As we moved from site maps and simple sketches, to complex sketching, workshops, process flows and wireframes, specifications, prototypes and user testing our profession developed a set of tools by which we could express to the world the value of our contribution. But more importantly, it enabled us to give voice to the oft-forgotten or silent users who eventually are the benefactors of our engagement with the process.

Are UX roles becoming multi-disciplinary?

Are UX roles becoming multi-disciplinary?

Back in the early days of digital there were far fewer roles than there are today. You basically had people selling for the agencies, project managing, designing and writing content, and building. Life was simple – yet in many ways everyone’s role was multidisciplinary. Early project managers’ roles encompassed sales, strategy, project management, account management, requirements gathering, and developing of site maps. This last bit, with some additional thinking and sketches, laid the groundwork for ‘creative’ designers to do their work – and also for a discipline that would eventually emerge and become what we know of today as User Experience. User Experience had a hard-fought role to play in the digital process. UX professionals have come from project management, content, design and technology disciplines.

Digital helps Government reduce costs… really?

Digital helps Government reduce costs… really?

I find myself thinking about Government’s desire to reduce costs by ‘going digital.’ It’s as though the very notion of something being online instantly results in reduced effort and cost and provides a useful and usable service to Citizens. In recent years, Government has seen digital as a means of reducing ‘avoidable contact’ – that type of contact that Government might not have to have with its Citizens face-to-face or on the telephone if it could service them digitally. It could rationalise this by saying that digital was a progressive means of servicing a society of such diversity, breadth and distance that face-to-face was no longer an appropriate medium to provide services. Of course this begs the issue of the ten million or so UK residents who do not have access to or use of the Internet.

Hack Days: What expectations do they set?

Hack Days: What expectations do they set?

I love Hack Days. I love them because of the anticipation, the spontaneity, the community and the creativity. They generate energy – if for a short time – around the issues they are organised to expose, and for a brief moment overcome the inertia that most people come to dread within large organisations – like Government. I say ‘expose’ because in my experience of Hack Days often people come to ‘show off’ their skills, ‘show’ the organisations or sectors whom they are targeting ‘how to do things better’, and ‘show’ each other what they are capable of. None of which is bad. But all of which worries me slightly.

The 80:20 rule of Agile and UCD

The 80:20 rule of Agile and UCD

I want to tackle the intersection of User-Centred Design (UCD) and Agile. I’ll start by saying I am fundamentally not an Agile detractor. I respect and appreciate the need for process to help shape and deliver complex projects. When it comes to UCD I am a strong believer in designing the ‘right’ thing for the ‘right’ user – of course, I also strongly believe the most successful UCD projects find a good balance between the needs of the user and the business. In my experience, whether intended or not, Agile has typically promoted the technology team to the front of the pack, with the consequence of producing the product through the eyes of a team focused on what it can do in the time (Sprint) and with the team (capabilities) to hand.

Open data is not a panacea – but it is a start

Open data is not a panacea – but it is a start

Today the UK Government officially launches its effort to open up UK data. This is a project that I am proud to have even a small part in developing. In certain circles there is a real fervour around the release of data, this being the essential ingredient missing to give citizens the power to manage their own destiny. Wait. If what I’ve been hearing is right, it sometimes seems there is a real belief that Citizens – not Government – will be developing ‘Services’ based on the data that is released. Who are these Citizens? For years I have made the argument for the guy on the street. Let’s call him (as I so often do) Joe Bloggs. He works hard, spends time with his family and mates. In fact he represents a significantly large portion of the population. Is the supposition that he is going to suddenly take an interest in the release of Government data, teach himself how to code and do SPARQL queries, and develop his own ‘Services’?