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.

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.