Mobile Cloud Summit video
A couple of weeks ago I ran a panel at the Mobile Cloud Summit on Evolution of the Mobile Cloud, which looked at the impact of Mobile Cloud on User Experience. I really enjoyed the panel and its participants, which included Windahl Finnigan from Cap Gemini, James Clarke of Thin Martian, and Jules Ehrhardt of ustwo.
Apart from the fact I quite obviously need to go on a diet and get to the gym, the panel was engaging and the participants engaged and quite obviously experienced.
And now I see what people mean about my accent. Doesn’t sound quite American… oh well.
I hope you enjoy watching the panel: http://vimeopro.com/quadriga/mobile-cloud-summit-in-tech-city/video/30120511
Prototyping as an ethos
When car manufacturers design a new automobile, they develop requirements, conduct research, draw designs, make scale models, test scale models in wind tunnels, computer model their ideas, build full-scale prototypes, test them, and iterate the designs – all of this before putting them into production.
What they don’t do is go right from drawing them on a piece of paper or having some ideas to putting them into production.
So they don’t base their decisions on a paper prototype or a list of words. Why? Because a car is a 3 dimensional experience. It is an experience of the senses. It is an interactive experience. You really need to understand it before you put it into production. Mistakes would be costly.
Most people, if you asked them to draw a picture of a car would do so. And the exercise would result in many different shapes, sizes, features, etc. However, if pressed, most people don’t actually believe they could design a car for production.
So why, then, do so many people believe they can design a website?
When done properly, websites go through a process of understanding requirements (those of the business – and the users), which can mean conducting research and workshops with all constituents to understand needs, desires, etc. All of this informs design and function. We sketch, we wireframe, we prototype, we test, we revise, we design, we build, we test, etc. There is a process that we follow, not because we want to be difficult, but because we are often delivering something, that in todays world, can sit at the core of a business’ strategy.
We wouldn’t want to take our responsibility lightly, because to do so could be catastrophic for the companies for whom we work.
So if we take our responsibility seriously, why don’t our clients? Why do they so often try to cut corners, cut out research and prototyping, shudder at the idea of iteration (which will equal cost now but provide potential benefit later), and railroad us down an agile path that promises iteration, but so often delivers linear, scaled-back development with no opportunity to evolve already built functionality?
Prototyping and testing gives you a real opportunity to test, iterate and re-test. It allows teams to incorporate learnings (other than their own) so that the end results more closely resemble the type of result that users might actually find useful.
If I could I would present a counter argument to this process to try and give some sense of perspective, but through all of the prototyping and testing I’ve been a part of throughout my career, there have always been a set of beneficial learnings that have come out the other end, and a set of clients (marketers, tech teams, stakeholders) who sit back and think ‘we didn’t know that before’.
I’d love to see more time built into projects for prototyping and testing because I enjoy it when projects are given a chance to be successful and clients are given a chance to shine when their results bear fruit.
And isn’t it better when we share our work while it has a chance of being improved than after when it is too late?
What’s that on your shoe?
Just a bit of rainy afternoon levity following on from my last post.
No Virginia… you are NOT the user
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.
I could almost forgive them, as they try hard, they all want to succeed for different reasons, and if their business does well, they will all look good. Unfortunately, just because 8 people are rowing in a boat doesn’t mean they are all rowing together – that takes time, collaboration, recognition that they are all working towards the same goals and objectives, and an honesty about their capabilities.
I could almost forgive them. But I won’t. They should know better by now.
But it’s not the clients that worry me most.
It’s people I’ve worked with over the years – and will work with in the future. The ones for whom the phrase ‘you represent the user on this project’ applies. The people who say it often have no clue what they are talking about. Of course, the only people who can represent the user on the project are, well, the users. And the Information (or Experience) Architect, who gets used to being beaten down when talking about inclusion of the user, after a time begins to believe that the only way to include the user is to ‘be’ the user. This is the one that really frightens me.
No Virginia… you are NOT the user.
The Information Architect brings a bag of skills and tools, a degree of experience, and the capability to open the doors to engaging with users on a project. The user should be the first port of call. Who are they? What do they want? How do they live? Why would they use or want a client’s products or services? When is the best time to engage them? Quantitative statistics that can only answer, to some degree, some of the questions above can only provide pathways to partially thought out designs.
The IA is often left to sort out the rest. And the worst part of this is that the more it happens, the more confident they become in their own capabilities – those of actually representing the user on projects.
Where UX represents a world of ubiquitous experiences for users (also see my blog posts on UX and the Art of Digital Appropriation and Pervasive UX – Who is Responsible?), more Information Architects, with their own values, interests, varied experiences and goals provide a dangerously seductive (and less costly) alternative to representing user experiences on projects.
I think this is something that everyone needs to be aware of and consider when they limit the potential of a project from the beginning by assuming the inclusion of Information Architects solves the issue of user engagement in the process. You cannot say you practice user-centred design when you do not engage users in the process.
No Virginia… you are NOT the user. The user is the user. Someday, you may have the opportunity to be a user on a project – where you are not doing the design. But until that day, please, everyone involved in projects, work harder to get to know who your users are, and please, do involve them in the process. It can be really quite rewarding!
Update 6 September 2011:
A good example of why this is important can be found on @pubstrat‘s latest blog post, ‘Cleaning up the user interface‘.
Mobile Cloud Summit
On 21 September, 2011 the Mobile Cloud Summit will take place in Hoxton.
It is a one-day event that will focus on how cloud-based applications delivered via smart mobile devices are transforming business and society. It will also focus on the Mobile Cloud investment opportunity and will be an opportunity for leading IT companies, investors, entrepreneurs, and the tech media to get together and discuss.
I will be moderating a brand new session at Mobile Cloud Summit called The Evolution of the Mobile Cloud.
For more information on the event, visit the Mobile Cloud Summit website.
You can also track the event on Lanyrd.
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.
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.
Alphagov musings
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…
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.
I’ve made the argument in the past that innovation could be as simple as taking the practice of one sector and applying it to another, bringing about change and introducing a new way of achieving something. This often requires people who work across sectors and have the ability to spot latent needs in one sector that can be met by standard or best practice from another. This is briefly alluded to in the afore mentioned article when Mr. O’neill speaks about what Government could learn from its engagement with London 2012.
Skunkworks have historically been used to come up with solutions where normal business practice has failed or where significant leaps in technology are required, the success and output of which may later be put into production using Business as Usual (BAU) methods of production.
All of which leads me to ponder what kind of leap is Government trying to make?
It strikes me, from my brief sojourn into Government a couple of years back, having worked for commercial organisations across multiple sectors for more than twenty years, that Government departments could do with more exposure to how businesses plan and manage their IT, develop their digital services, and have an imperative to find a balance between the needs of the organisation and the desires and goals of their customers. Indeed, even the Government itself has gone down this route by engaging people like Sir Alan Sugar and Martha Lane Fox.
On the other hand, if the idea of the skunkworks team is to be a rapid prototype development unit – that doesn’t get too bogged down in coding, and spends more time achieving some of the balance I’ve referred to – then they could possibly introduce more rigour into the process of developing their IT and digital services, introduce the people who design these services in departments to their users, and look to build ‘just enough’ to accomplish a specific set of tasks, then possibly there is some educational value.
However, with a large proliferation of open source technologies on the market, and project management and user-centred design methodologies that many in Government fail to understand or embrace, I worry that what many will think of as innovation, is already so imbedded as BAU elsewhere that BAU will get mistaken for innovation (I recognise a degree of my own hypocrisy here).
One other thing the article mentioned was the use of Agile development. I’ve had the distinct ‘pleasure’ of working with agile in projects that range from quite small (new builds and enhancements) up through major software development programmes. The one thing I’ve learned is that it’s rarely applied the same way twice, and that people rarely follow its basic values (see link above for source):
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Skunkworks teams, by their very nature, should be agile. However, how the work that comes out of a skunkworks effort is then rolled into the organisation can be another matter altogether. As you can imagine, a skunkworks team can roll out some small live applications, websites and enhancements, but when it comes to large-scale services development, the best it can hope to achieve is to do some proof of concept work, prototype, and inform the larger project that will follow. And that is where the many varied applications of the Agile process will show varied results.
Still, though I’m quite baffled by what a Government skunkworks team hopes to achieve – and from the looks of it in quite a public way (keeping in mind that most skunkworks projects are secret with some percentage of the ones that succeed becoming a product we might one day see, and the rest buried deep in a basement vault never to be heard from again) I fully intend to watch this space and see what comes out of it.
I also wonder what roles the Parliament skunkworks team, Directgov | innovate, dotgovlabs, and the shadowy Alphagov team might play in the short to medium term in working with Mr. O’neill’s skunkworks team in the digital space.
I think it promises to be an interesting next twelve months for UK Government digital.
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.
Over the last 15 years UX has grown from being an adjunct to someone’s day job, into a profession with its own associations, conferences, university degrees, specialist agencies, and recognition as a fundamental part of the process.
It has taken a long time to get to a place where there is wider recognition of UX as a profession.
Which is why recently, I’ve been following with great curiosity a path that UX seems to be taking. A proliferation of UX Strategy and UX Engineering roles, along with the intersection of Agile and UCD, appears to be pushing the traditional UX professional to begin considering multidisciplinary paths.
A simple response to this is that User Experience has never been limited to just us. It affects, and is affected by, all of the other disciplines in digital, by our client’s business and internal stakeholders, by their customers, and their competitors, the economy, the Government, and many other factors that extend well beyond the general purview of the individual UX professional.
While we were churning out process flows, wireframes, prototypes and specifications, and encouraging our clients to conduct user research to inform all of their activities, we were training them in the value of informing their digital strategies with a broad range of input and thinking.
And as our work came to contain more research, methodological review, competitive analysis, and white paper recommendations, we slowly moved into the realm of strategists, who were using their own tools – PEST, VRIO and Porter’s 5 Forces among others – to analyse a client’s environment and business.
Disparate analysis is not enough. Clients need to make the most of the knowledge gained from both disciplines to create opportunity for their businesses and customers.
In a similar way, UX has driven prototype development as a means of demonstrating functional design. This has driven the proliferation of tools like Axure that enable UX professionals to develop rapid – or often overly complex – prototypes to give a client an indication of the end product.
These prototypes can be used in user testing, as demonstrations to stakeholders, and work in Agile and Waterfall environments to inform the developers in their work.
In some ways we are victims of our own success. Agencies and clients are now looking for UX professionals who can prototype – and more than that – UX professionals who are also developers, who can write CSS, develop HTML templates, write JavaScript, and far more.
All of which brings me back to my original question, and the title of this post: Is UX returning to being a multidisciplinary role?
I believe – as probably many of you do – that UX has always been a multi-disciplinary role. I think that we are seeing some of the strands of UX develop and evolve in quite a natural way at this point. I’d like to think that the situations I’ve described above are only a couple of many strands of development for UX professionals – as there are others we’ve not talked about like the UX/designer, UX/programme manager or the UX/content strategist.
I would be wary of a future where all UX professionals are required to also be developers or strategists. I think some people naturally evolve down some of these paths – in the same way that some people like to stay in the trenches and wireframe, while others like to run teams and develop overall frameworks.
I think going forward it is going to be a challenge to both the UX profession and other professions to understand how to handle these intersections. They present interesting opportunities and challenges, not least of which is the sense of dissolution they sometimes bring when they happen. I think it is also important to understand that there is a core UX profession that is now established, and these intersections can represent new paths for growth.
I have my own thoughts on the paths I’m interested in. I’d be very curious to know what others think.
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.
So then you need to create programmes to get people onto the Internet – because ‘digital exclusion’ would be counter-productive to a progressively digital society – and mean the Government now had to maintain both digital and face-to-face services, not realising any savings at all.
In all of this, the main issue is one of an anticipated reduction in effort and cost to Government. Such a strategy would have to look at value over the:
- Short term: The quick win solutions where Government can make information available to Citizens in low cost ways. This might include a slimmer, more efficient Directgov. It might encompass other efforts such as the data.gov.uk initiative, or even providing support to My Society, where a bit of investment could build on existing successful efforts to inform Citizens.
- Mid term: Creation of a strategy that focuses on the development of smaller more agile services that address very niche audiences and provide for the development of simple, centralised security frameworks that would allow Government to roll out these services quickly and efficiently.
- Long term: A revisit of all existing services, rating their effectiveness, rationalising them, and building them using user-centric methodologies that ensure they encompass the needs of the department and expectations of the users.
Of course, in evaluating the benefit of moving to digital, Government needs to be honest with itself about the amount of success it ‘allows’ users of digital services to have when using them.
For example, if a Government department responsible for providing a benefit to Citizens had a budget that could only pay that benefit to a percentage of all those who are eligible for it, would that department want to make the online application process quick and efficient, potentially resulting in over subscription to the benefit – or might it design something that is so complicated that only those with incredible patience and endurance might get through it?
In this particular instance, the issue is not about a choice to go digital – it is a strategic choice in how accessible you make the benefit. Under this circumstance you’d have to ask: is there any real benefit to going digital at all?
But allowing that not all services suffer from this potential complication, to realise some value from digital, Government needs to understand:
- Does the service belong online? There should be an assessment as to whether the service solves a problem that Citizens need solving, making access to information or benefits useable and simple, beyond the current mechanism for doing so.
- How big does the service need to be? Rule of thumb is that you should design the minimum amount required to complete the service or access the information – each incremental, low priority requirement built into the service reduces its chance of completion.
- Is your project led by technology, departmental requirements, the needs of the users, or all of the above? The reality is that the larger and more complicated the service, the more likely it is to be technology driven – driving out the needs of the business and the users. You need to find balance to be successful. Delivering something doesn’t always equal success.
- Can it be made simpler? Projects always get larger before they can be rationalised. Everyone’s requirements are thrown in, technology insinuates itself, stakeholders complicate things and somewhere along the way the end user has been forgotten – they are mentioned in meetings, and in people’s heads they believe they are representing the users, but in reality the complexity of the project has intervened and marginalised the people for whom it was originally intended.
Digital services will ultimately be accessible to all. We are in a period of transition from pre-Internet users to digital natives. In this interstice we have created a belief that it is ‘our duty’ to get everyone online so that they can experience the benefits that online has to offer.
I worry that Government forcing people online is not the answer – enabling can sometimes lead to bullying.
In a couple of generations this argument will have passed. Access to digital will be ubiquitous. All Government services will be made available online. And Citizens and Government will feel empowered to collaborate with one another to make this a better experience.
Really?
← Older posts