User stories imageThere’s a great blog post from last week by Kelly Lothbrook-Smith @kayelesss on twitter, ‘In defence of UX‘ that sums up just how difficult it can be to get UX and usability approaches embedded into digital development practices.  She describes the role of the UX researcher as a messenger, getting users to convey their experiences with the product and then interpreting and sharing that in the form of insight with the product management.  It’s a great description.  It resonated with me for many reasons: for the sense that all too often you come up against the view that ‘we know what users want’ and that there’s a tendancy with usability (and particularly with accessibility testing) that it is a process on a QA checklist that has to be ‘ticked’ off.  ‘We’ve done usability testing or we’ve done our UX research at the start of the project, we’ve had our focus groups, we’ve commissioned someone to do this – now we’re going to build x’.  Even in an agile environment I still get a sense that usability is perceived as being something that happens ‘after’.

And then this today from Michael Schofield, ‘The Mountain beyond the Molehill‘ identifying the challenge of what to do to turn those insights into decisions and referencing the CMMI model for UX from Coral Sheldon-Hess.  Even once you have managed to get the UX role embedded into practice how do you make sure that it is sustained and that the evidence that gets collected is used in decision-making and leads to service improvements. I’m not so sure that I entirely agree with the suggestion that “at best, failure to turn our investment in user experience design into practical return lowers the esteem of UX at work; at worst, it’s grounds to dissolve the practice entirely.”  

Libraries typically collect vast amounts of user feedback.  Surveys, comment cards, forums, whiteboards in libraries, polls, comments from help desk enquiries are just some of them.  But we struggle to make much sense of it as much of it just doesn’t give you the context to understand ‘what would make things better for the user?’   You rarely get actionable feedback – this thing is broken, please fix it.  Much of it is opinion and can give us a clue that there is something wrong with x feature, but no real idea of what is really wrong, what was the user trying to do, what do they think it should do, where does it fit in their workflow?  Even with traditional usability testing you can observe what the user is doing on your website, but you’ve designed the task and shaped the experiment and that limits what you can uncover.  But one of the attractions of many of the ethnographic UX techniques is that they lead you to a better understanding of your users and what challenges they face in using your product.  For example using cognitive mapping or directed storytelling or love-letters/break-up letters techniques (see this example from Massachusetts Libraries). Embedding that approach into the team gives a much richer picture and I’d argue actually saves the organisation time by focusing your activity on the things that make most difference to users.

So an example, from accessibility rather than UX but I’d suggest that there are parallels.  In our team we’ve manged to build up some accessibility expertise as we recognised that we needed skills in that area, we’ve also got some UX capability in the team.  Where we started with accessibility was to audit sites and then plan a programme of work to fix the issues that were identified.  But we’ve now started to try a different approach and embed accessibility expertise into the development sprints.  It means that decisions about design can take the accessibility perspectives into account at an early stage, leading to development that builds a more accessible feature from the outset.  It’s an approach that saves time as there are less things that might fail an accessibility test and have to be redone before it can go live, but it also gets a development team used to thinking about accessibility so options get brought forward that are more accessible.

There are parallels with UX practice and thinking I believe.