Yesterday I attended the 2011 London UX Camp, it follows the same format as a traditional BarCamp but only over the course of one day rather than two and focused on UX, or at least anything that could be related to UX.
I'd gone along with my Osmosoft colleague, Colm Britton, and we decided to give a joint talk on the topic of UX in the Enterprise. Neither Colm nor I would consider ourselves "UX experts" (although Colm is much more design focused than I am and has recently begun taking a lead on the design elements of Osmosoft's work - and a great job he's doing too) so we figured given the audience of UX Camp it might be interesting to talk about our perspective of pushing good UX from within an Enterprise, the challenges faced, what's happening to make improvements and some of the questions we have.
At the start of the day we put our talk post-it note up onto the grid and we were somewhat surprised to see a number of Enterprise themed talks also being proposed - in fact the two main themes of the day appeared be 'UX in Agile Development' and 'UX in the Enterprise'
I thought that I'd run through some of the main points that Colm and I talked about, and some of subsequent conversations that arose during our and others presentations. I won't go through all the slides, however the full set can be found here.
Many of the following points are based upon experiences working in BT both on the business side (I was previously responsible for some of the web innovation work for the Wholesale arm of BT) and recent experiences working with Osmosoft - given yesterday's conversations I'm confident that these points are Enterprise wide and not necessarily BT specific ...that said the usual caveat of 'these are views of my own and not of my employer' applies!
People tend not to trust what they don't know - this is especially true in monolithic organisations where rigid structures and business norms are in place. If you try and suggest a new approach you're often looked at as though you're crazy. On a project a few years ago we were discussing the need for interaction design and the suggestion that we needed to pay for experts to help ensure the application was enjoyable to use was met with horror:
...this is a business to business application, its not supposed to be fun to use
There are many views and opinions as to what skill sets make for a good UX designer - an understanding of the aesthetics of layout, typography, colour and space, the ability to communicate well with clients and developers, being able to apply the mindset and goals of multiple personas, an understanding of human behaviour. There's also a growing trend of prototyping in code so fluency in HTML, CSS, JavaScript could be expected. And with the evolution of CSS3 things like a grasp of animation and motion also come into play.
No matter what your views are as to the perfect blend of skills to make a UX designer it undoubtedly requires a unique multi-disciplined person. In contrast most Enterprises are very much role driven organisations - people fill roles of rigid pre-defined skills and anything you do which falls outside of the bucket in which you've been placed is considered wrong or ignored.
At Osmosoft we recently went through to process of writing our job standards. Here we had what could be seen as a picklist of 'things' that based on our roles we should be doing. The difficulty we had was a lot of what we actually do wasn't a part of our role - it either sat under the title of a different role or didn't exist at all. A positive outcome from completing our job standards was recognition that perhaps new job roles needed to be created and with that hopefully we can shape the skill sets required.
Perhaps the biggest challenge of all, and one that came up a lot during London UX Camp was how to justify the benefits of UX. In a world where everything requires an associated quantifiable benefit the cost of engaging a UX team is seen as an unjustifiable cost. Common sense tells you that building something that's unintuitive will lead to dissatisfaction and ultimately people not coming back to use what you've built again. As an argument for bringing in a UX team this kind of stacks up when it comes to customer facing things. But try applying this argument to internal applications and all of a sudden it becomes much more tricky.
Conversations throughout the day highlighted several approaches people have tried taking - analysis of efficiency which can then be related to a cost saving / increased revenue was common but often only possible after the fact.
As a common problem which seemed to be affecting a lot of people there was interest in continuing this discussion and come up with a robust set of metrics that'll stand up to business case reviews. I can see more posts on this topic coming soon!
Some of the challenges of UX in the Enterprise are purely cultural, and one would hope could be changed through best practise and education. However there are also challenges which are more difficult to overcome and in some cases simply cannot be removed.
BT, as you can imagine, has a huge systems estate with much of it having been built many years ago. As such there are often constraints enforced by the capabilities of legacy systems. Like a complicated jigsaw puzzle making changes can be made at the outside but ultimately dictated by what is at the centre - and getting to centre to make changes there means carefully unpicking everything else. This is slow and expensive.
Being cognisant of these architectural constraints can be frustrating especially when it forces you to compromise on the UX - but they do need to be considered. In the past where UX experts have been engaged we've often ended up in a scenario where a beautiful prototype has been produced, this has wowed the business but when it came to actually implementing it things fell apart and what we were left with was a poor resemblance of what was promised. Ultimately this does no one any favours - developers are wary of what designers will ask them to do next, and the value of engaging with a UX team is greatly reduced and questioned by the business.
In projects where a UX team is engaged they are often brought in far too late in the process. It's often at a stage where fundamental experience changes can no longer be made there's only an opportunity to make minor cosmetic changes - as Nick Dunlavey put it 'hit it with a pretty stick'.
When a UX team is engaged one of the many values they add is ensuring that the experience works from a DDA perspective. A common problem spoken about yesterday was when engaged late on in a project there are sometimes major changes that need to be made in order to achieve DDA compliance - no organisation would choose to ignore this so of course the recommended changes are made but often this is at cost to the project both in a financial and time sense. The fact that should UX have been properly considered at an earlier stage the cost and delay could have been avoided is normally overlooked and once again the UX team are seen in a bad light. Not good, huh.
There are a lot of challenges when it comes to UX in the Enterprise, and I've only touched on a few of them here. However I want to end this post (which I apologise has turned out being lengthier than expected) with some examples of how BT are taking steps to improve.
In BT we now have a team dedicated to usability. They are small in numbers and spread thinly across all kinds of projects (web based, internal applications, physical products, complete end to end processes etc). But they are in demand and being utilised more and more. In my opinion having an in house usability (or UX, design, UI, or...whatever you want to call them) team is a good move - they can understand the details of business processes better than an external agency and overtime engrain a user centred design approach to the heart of an organisation.
In Osmosoft one of our core principles to build prototypes rather than PowerPoint. Doing this allows us to more quickly build a closer relationship with the client (whether they are internal or external) giving them something that they can touch and play with helping us to get an understanding of the interaction needs. Based upon feedback we can quickly demonstrate iterative changes that can only be done in code.
Through BT's usability team, Osmosoft and other pockets of the business there are groups running regular masterclasses and awareness programmes to help raise the awareness of UX needs. These follow a ground up approach and focus on those who have an interest - something that was pointed out yesterday, and quite rightly too is that education needs to happen from the top level down as well. Unless the senior members of an organisation recognise the benefits of good UX then there'll always be issues.
Finally, a longer term goal of BT's usability team is to make UX a mandatory check point in its delivery model. As a gated checkpoint early on in the delivery process projects will only be able to proceed if they've had the necessary engagement with recognised usability experts. Inclusion in this process and its enforcement across the business is a long process, hopefully in parallel there'll be enough of a growing awareness that such a check point isn't really needed.
In summary, when it comes to UX in the Enterprise there any many challenges and there is plenty of room for improvement. Conversations at UX Camp London demonstrated there are lots of people interested in resolving these issues and that over the coming months and years there'll be increased acceptance and plenty of interesting changes afoot.
Friday, September 16, 2011 at 9:58PM 
;)
;)
;)
;)
;)
;)
;)
;)
;)
;)
;){kind=link}