Tim Brown on Creativity and play – oldie but goodie0
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.
Pervasive UX – Who is Responsible?1
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.
For example… An individual might start a shopping order on their Tesco iPhone app in the morning. At lunchtime they might pop into a Tesco Express to grab a salad. When they get home that evening they get their mail and there are Tesco vouchers, which they then use when they log into their MacBook and finish their Tesco shopping order for the evening. The next morning, their shopping is delivered to their door.
Their Tesco journey moved from mobile to in-store to direct mail to the Internet to home delivery in the span of 24 hours. It moved from work to shop to home. Their experience of Tesco was a pervasive user experience.
And yet, for many brands, why are so many of the above functions managed in silos?
A single individual experienced the journey described above. Hopefully, they had an experience that felt integrated, efficient, economical, convenient and pleasant.
The reality is that while a user is a single entity (or a series of different entities with varying needs), businesses can be multi-faceted, politically divided beasts.
Take a bank that is undertaking a redesign of its home page. A single user comes to the bank website with a need, a desire to satisfy that need, and often less time than the bank would like them to have to satisfy their voracious needs.
Banks offer a variety of services: loans, current accounts, mortgages, pensions, investment plans, etc. The home page is like a giant billboard. Only imagine the political entities behind the scenes – we’ll call them business owners. They are each fighting for a piece of that billboard. In reality, they each want the entire thing. They fight, they squabble, they negotiate, eventually, they compromise.
The user often just wants to do one thing. But they have to wade through the bank’s compromise in order to get to the one thing that they want. It’s as though the bank turned itself inside out and exposed all of its organs to the customer. Now add in the in-branch experience, direct mail, real billboards, television ads, iPhone and iPad apps, etc. How many stakeholders do they have to handle those experiences?
Who is responsible for the pervasive user experience, the journey, of that poor individual who must experience everything this bank throws at it?
So I began by saying I’ve been thinking about the ‘edges’ of user experience. It’s easy to think about the historical deliverables, in terms of Information Architecture. But it’s more difficult to understand the role that User Experience might have to play in terms of business process change.
As businesses and organisations offer more information and functionality through more channels and in more places, it is imperative that someone considers who all of this was being done for to begin with. If the output, due to internal disagreement, is already a compromise, then the experience for the individual can only be fragmented.
Is the ownership, or at least the nurturing of this finally a job for the UX Strategist? Or are we now going even beyond this to a Board or Management team level role that is responsible for the integrated experience?
As always, I’d love to hear your thoughts.
Update: 29 August 2011
There’s also another good take on Pervasive UX @windahl‘s blog.
The actual writing1
So, I’ve written about 5 chapters now – including, funnily enough, the last chapter (which is subject to change).
Having spent time getting the story arcs sorted for each of the three novels has been a tremendous help. Also, writing character descriptions for the main characters has been very helpful.
The actual writing is going well enough, though I’d like to be a bit further along by now. How in the world do you just keep your head down and not get distracted? I’m finding anything can be a distraction, from a phone call to a piece of lint. It’s irritating.
I guess I need to just keep pushing myself and take on some of the discipline I have in my (other) professional life. This is, after all, a job like any other. Just one that requires intense periods of focus.
Let’s see how far I get by the next post.
Alphagov musings1
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.
When Alphagov launched a couple of weeks ago, it was amusing to watch the crowd of people – who several years ago berated pretty much anything we did at Directgov – practically fall over one another in praise of Alphagov. Surely, if they are happy there must be something to it.
Certainly the £261k spent on the project didn’t bother them. In fact, it was considered a bargain.
However, after a couple of weeks of love, the veneer began to crack and UX expert Lisa Reichelt chose to write about ‘Opportunities Lost – AlphaGov’, while Steph Gray, former BIS digerati chose to write about ’10 Things that Alpha.gov.uk gets wrong’ – in 2 parts (Part 1 & Part 2).
This past weekend, I attended the OpenTech conference in London, and attended the Alphagov team session. There were a number of interesting questions and points raised by the audience – and not very many fully formed answers forthcoming from the team – with some answers unfortunately missing the mark entirely.
Asking a few questions at the event has codified my thinking about the project. Below are some of the things I’ve been thinking about and some questions I have.
In general, I’m delighted to see that the Alphagov project has sparked so many conversations about the Government digital content landscape.
Aggregation vs. Distribution
When I worked for Directgov and variably headed up the Product Design and Innovate teams, there was a general sense across Government digital types – and from colleagues outside of Government – that we were exiting the era of websites as destinations, and that content (and services) were not fully distributable commodities, e.g. through mediums like social media and devices.
‘Convergence’ had lost its sense of purpose because users no longer expected to only find content (or services) in one place. They were learning that they could find information, services, social connections and a voice in places where they naturally reside and not have to go searching for it.
Alphagov, on the other hand, seems to not only take on Directgov’s historical remit of convergence, but according to one of the Alphagov team at OpenTech, takes it a step further resulting in the dissolution of all Government websites, making Alphagov the UK destination site for all things Government.
David Varney, himself, couldn’t have put it better.
But still, I’m curious, if in a world of growing distribution of content and services, where individuals are finding more everywhere, is this philosophy of aggregation and centralisation – ergo portalisation of content and services really the revolution spoken about by Martha Lane Fox in her report ‘Directgov 2010 and Beyond: Revolution Not Evolution’.
Solving the content sourcing problem
Though the Alphagov prototype is ‘pretty’ (and I’ll come back to that later), what I was most looking for in the project was revolutionary thinking about how the content sourcing issue would be solved.
With thousands of pages representing many millions of words of content sitting across Government, all in quite different formats, some accessible via feeds, some inaccessible and requiring content scraping, what was the plan to source (and make relavent), in a sustainable way, content from across all of Government’s assets?
From their own blogs and comments, the Alphagov team scraped content, adding editorial and curation on top. Expedient? Yes. Sustainable? Probably not.
Directgov already has a Publishing model whereby approved editors write content with their departments and it goes through a process of ‘curation’ ending up on the site.
While the Directgov model is probably a bit too process-laden (as many things in Government become over time), I’m not sure that the Alphagov project, which should be more than just a collection of pretty pages with scraped content demonstrating a possible end-state, has even tried to posit a solution to the content origination, curation and publishing problem currently faced by Government.
Going forward, I believe this is still one of the largest challenges facing any such effort.
Revolution – or a change from one institution to another – in this instance does not necessarily mean success.
Low hanging fruit
When developing a prototype or creating a demonstration in a limited amount of time, one avenue you can take is to pick off the low hanging fruit. For me, the Alphagov project is a demonstration of that approach.
Given the prototype – which of course is all we have to judge the success of the project by – it would appear the team has yet to:
- Tackle the development of a content strategy that takes into account all of the diverse and deep content the Government has to offer
- Do the requisite user research to develop a core set of personas that would help to give the site focus and shape
- Understand how to take content on a journey from origination to relevance without losing users along the way
- Ask users – not technically oriented colleagues – what they want
- Consider the organisational structure that would give their project a chance of success
- Demonstrate a system that is scalable and sustainable
It’s one thing to say you are developing a better Directgov website. It’s another thing altogether to say you are developing a better Directgov – which is really the driving force behind such efforts (remember the revolution bit).
These two things are not mutually exclusive if you want the process of engendering Revolution to succeed.
Putting the emphasis on Google
For years, Directgov has spent millions of pounds purchasing key words, advertising, etc. Because of this, they have reduced the amount of direct traffic coming in to the home page. While this puts less emphasis on the home page, it puts significantly more emphasis on the navigational structures of the internal pages to perform and inform users of other content (and services) on the site.
While the idea of relying on Google seems interesting, it really only works when all of your content is indexed and large numbers of people have hit the pages to help determine any sense of weighting or relevance.
If you deep link to the prototype at the moment, the only real means of navigation to other content seems to be via the search bar. This assumes that NO users are browsers and that the page they have landed on contains enough information to satisfy their search. Of course, the premise is that if they do not find what they are looking for, they will ‘pogo’ from the site and initiate a new search on Google. This is, in fact, sustained by research conducted by Directgov several years ago.
One worry, of course, is that unless Government intends to continue to pay a significant amount of money to Google for key words and paid search, is complete reliance on paid search engines such a good idea? And of course, doesn’t this further promote the idea of Government as a destination, rather than support the direction of content and services as distributable commodities?
And one incidental point, as the prototype has been developed to work as though people are using Google as the primary search method, there is currently no real means of testing Alpha.gov.uk to see if their premise actually works. All visitors will go to Alpha.gov.uk, entering the site via the home page.
UCD, Analytics and Accessibility
Alongside the talk of this being a User-centred design (UCD) project, there has been a lot of talk about their use of Government site analytics and web logs. Nowhere has there been discussion of user testing with real users, persona development, or other means of Qualitative research used in a UCD process.
From all accounts – and from their own words – they have designed based on the ‘what’ of analytics and not the ‘why’ of a qualitative UCD approach.
Additionally, to ignore IE6 – used by the Public Sector and many large public organisations, and Accessibility, they have denied those in the Public Sector and those with assistive technology needs the opportunity to participate in the discussion about improving Government digital services.
Just as Lisa Reichelt stated in her aforementioned blog post, I don’t believe they can claim to be a user-centred project when in fact they ignored most of the basic precepts of a UCD approach.
Is too much design distracting?
This is a small point, but for an Alpha prototype, I would question the level of design they have used. In some ways I’m not surprised. Solving the real problems of how you build such a site in a scalable, sustainable way would inevitably lead you back to something similar to a Directgov model, albeit scaled down to prototype size. And I imagine that no one really wanted to go there.
By focusing on the design and not being able to answer questions around it’s scalability and sustainability, is this just an exercise in form over function?
If we make it look nice no one will look to closely at what we’ve done.
An alpha should have set about to answer more fundamental questions. It should have looked at the problems it ran into during development and asked, how do we fix those problems? How do we ensure that as we iterate this prototype, we move closer to a sustainable and scalable model for development?
Perhaps those questions have simply not yet been articulated to the public. I think there is some opportunity for some real debate here. Collaboration with the public over how to solve the content issue could result in revolution. Or it could end up with simple iterations to Directgov’s existing process of publication – boring old evolution.
Is Project Austin the real Alpha?
A few years ago, Directgov undertook a project called Project Austin. Austin was an attempt to postulate a metadata driven model for delivering Government content (and services). Research was undertaken, personas developed, content strategies looked at, a prototype was developed (tested and iterated), and then… well, I don’t know.
What happened to it?
It was predominantly designed and developed by individuals who came to Directgov from the Commercial sector. They worked with Civil Servants and external research agencies to develop a new model – sound familiar?
Did the Alpha team take any cues from its predecessor, Austin. Did they review the work? Did they learn any lessons? Did they find anything of use from the project?
Does having a predecessor really make Alpha a Beta?
What have you learned?
This brings me to my last thoughts (and some questions) on Alphagov.
Three months is a good amount of time to form some opinions and make some decisions about what you would have done differently, whether you think you addressed the right issues, what obstacles you see in taking the next steps.
How does the Alphagov team intend to take the project forward? I know that the site is essentially up for a couple of months for feedback. I also know that the team intends to take the work forward.
Given that you have opened the site up for comment for a couple of months, does it make sense to keep changing it during that process? If you think of this as a consultation of sorts, you wouldn’t expect the consultation to keep changing as people commented. Do you think iterating it while you’re getting feedback will possibly cause you to change things that an accumulated set of responses might cause you to look at differently?
Will you continue to use your blog to keep people informed? And will you publish the feedback and thinking that you receive? There were a lot of comments at OpenTech at the weekend. Will these be captured and published?
And purely selfishly… how much will Alphagov cost going forward? We’re told the project cost about £261k – was that to get it to its recent launch?
I’d like to commend the team on doing something we had difficulty doing from within Government – getting a prototype out for public comment. This would have been inconceivable a few years ago. With the change in Government it’s nice to see some things are changing in the digital space for the better. For that you have my admiration. Despite any concerns I’ve voiced above, I think it’s important that efforts like this are taking place. I believe the team that undertook this project was highly capable.
That said, I really wish they had placed some dedicated UX people on their team. I wish they had focussed more on identifying and tackling the work that needs to take place to make it sustainable and addressed the issues of how to get content from so many different sources into a single place – other than scraping it.
But I think this team has raised some big questions for all of us to consider and have certainly gotten discussion going around all of these areas, which should be supported by all of us who have an interest.
I look forward to the next steps…
Agile as the process6
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.
In this instance you will likely need some kind of planning permission and therefore some designs drawn up for the planners to review. Once you have permission you will engage contractors to do the work. They will of course want to utilise the plans, but you can work with them side by side throughout the process. As the end customer you will have to live with the output of their work, and therefore any changes and modifications you make along the way will affect the outcome of YOUR project, affecting YOU as the user.
From a web or software development viewpoint, on small projects, where something already exists, and you understand its structure and use, adding something new or making modifications means working with known technology, design, users and a history of analytics. You may, at this point, even be working from a wish list provided by your users.
The Agile process can work very well here, where you are talking about iterative design and development and you have teams who understand the environment in which they are working. Many projects fall into this space, and I can understand why people might simply jump right into the Agile (development) process, running mini-UCD cycles either in, or slightly in advance of the development sprint.
Significant failure is low in this circumstance, and the ability to iterate or retract work should there be a problem minimises project risk. However you do run the risk of people not fully understanding, interpreting or developing things in the way you would have liked, and therefore may have issues with the quality or output of the work carried out.
Building a house
Analogy: Think of this as building a house from scratch. You start with a plot of land, planning permission and architectural blueprints.
On these projects, you are best served by putting process and structure in place. More to the point, before you engage a builder, you should understand – as much as is possible – what it is you want them to build. You likely engage an architect who you will work with throughout the process to get the best out of your budget and ideas.
The more you know about the build before it starts, the more potential you have for success – and the more possibility you have to efficiently build what you set out to build. We’ve all watched those shows on television where the owner went ‘off-piste’. What ensued was runaway costs, layouts that didn’t suit, missed opportunities and homes that, in the end, were livable but may well not have met the expectations or desires of the people who set out to build them. In essence, they began and ended with the Agile process, throwing User-centred design out the window.
From a web or software development viewpoint, on these medium sized projects, where nothing exists, you need to understand what problems you’re solving, who you’re doing the work for, why they want it, who else is doing it, and how what you’re doing will be measured to better understand success or failure.
In this instance you really need to understand the requirements of the business and the users. You need good prioritisation and clarity around the requirements. And because you are now building something new, with no pre-history, you really need an understanding that exists beyond that which Agile will give you. It is no longer enough to carve up what you perceive as the work, and then jump right into Sprints. You need to understand the shape of what you are building, what the major interactions are, and if there are technology constraints or technical architecture issues.
In short you need a set of blueprints to work from so that you don’t end up with something that no longer meets the needs of the business or the users, but satisfies a technical need to develop something. You need to do a larger portion of the product design up front, understand workflows and understand what a successful build will look like – and then engage development teams and work in an agile process.
Significant failure is high in this circumstance, and the reality is that most agile teams – even though they are supposed to be iterative – are often only given time and budget to develop new functionality, with one of the foundational aspects of agile – the ability to iterate – falling by the wayside.
Raising the skyscraper
Analogy: Think of this as building a large multi-story (say 40 floors) office building.
These projects are all about getting the planning right. From understanding the location and impact on the environment, to structural design, understanding how people flow and move about the building to how you integrate necessary function (elevators, stairs, electrical, heating and air conduits, power plants, plumbing) in a way that is people-friendly.
You simply wouldn’t jump right into construction of the building without understanding all of these things – it would be a disaster. In fact, understanding how these sorts of things are so important that companies like BAA – whom I worked with several years ago – go to the extent of setting up prototypes of bathrooms in warehouses and conduct user flow testing to understand how people use bathrooms and how to build them more efficiently for the people who use them. Even they don’t just say ‘Hey, we need a new bathroom’ hire a bunch of contractors and just start building.
You would engage with architects, planners, experts in construction, clients, and a myriad of other stakeholders, develop your plans – to a very detailed degree – which you would then use in a RFP to construction companies so that quotations would be as focused on what you are attempting to develop as is possible.
In the same way, with large web or software development projects you wouldn’t imagine kicking off with ‘just enough’ requirements to get going. There isn’t enough context at this stage to know if your starting point is appropriate, if what you are doing is even relevant, and how what you are doing interacts with the rest of what you are building.
Failure on this scale of project is catastrophic and costly.
So why do so many companies do just that?
Agile is too often being sold as the entire methodology, when in reality it is a development – note, development, not design – methodology. For that, we have a User-centred design methodology.
These things don’t work in opposition to one another. They should be complimentary. And yet, often you find people saying that UCD is too much like waterfall, and because they have bought into the idea that Agile solves all of their problems, they see Waterfall as antiquated and Agile as the new kid on the block, shiny, new, better.
The truth is, that in the latter two examples above the potential for catastrophic failure is quite high – and can be accomplished quite quickly. When a team hasn’t taken the time to understand what it is building how can they know that what they are building answers the needs of the business – or the users – for whom they are developing? And when – as is so often the case – the agile process itself is compromised and iteration isn’t allowed to occur how can you expect success?
I think of UCD and Agile as working together on a sliding scale. To the left we have the known, where UCD and Agile are in the trenches together solving problems as they go and adding incremental functionality. On the right side of the scale we have UCD and Agile working in a different configuration where Requirements and UCD provide more shape and detail before the development process begins and Agile delivers the output once everyone understands the shape and function of the application. The fact that this doesn’t often occur doesn’t mean it isn’t the right process to follow.
More open conversations need to be held between the Agile and UCD communities to ensure there is a process that works for everyone. And more recognition needs to be given that there is significant differentiation between small incremental projects and large-scale web or software development projects.
I hope the two communities continue to work together to understand the best implementation of these two methodologies.
