Sometimes the developers I work with believe that UX extends so far as me producing a mockup or specifying how a user will perform a function. However it is so much more than that, as peers will agree.
In a meeting recently I demonstrated the preferred method for a user to find specialist content using auto-complete on the advanced search form. While on the whole, the stakeholders were happy with the process, the technical architect identified a global problem with the existing content model on which the product was built. Essentially, it meant that by using the auto-complete feature, the user could only retrieve a proportion of the content. How would the other proportion be surfaced to the user? The discussion went on for some 20 mins at which point the developer got cross. ‘This meeting has gone on a tangent, hasn’t it?’ he asked me. I reiterated that we had a content problem. ‘I don’t care about the content, as long as there’s a list, that’s all I need.’
What my colleague had failed to realise was that the ideal user experience was not possible due to a stitched together set of legacy systems containing related content. That the initial architecture of the site had fundamental problems which would need solving first in order to achieve optimal usage.
The bigger thing which my colleague had failed to identify is that the role of UX is meant to show up gaps and holes in systems and processes such as this. While he took the tangent as a waste of time, I took it as a feather in the cap for UX ! Surely that’s what it’s all about it, isn’t it?
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 2.5 License.