For me UX has always been about contact with real people in the process of collaboration, workshops, design, prototyping, testing and iteration. Which is why lately I’ve been thinking about the growing reliance UX has on tools like Axure in our day-to-day work.
I’ve been around long enough to watch UX grow from an adjunct to other people’s roles to a profession of some importance in the digital space (see my post ‘Is UX Returning to being a Multidisciplinary Role’.)
As we moved from site maps and simple sketches, to complex sketching, workshops, process flows and wireframes, specifications, prototypes and user testing our profession developed a set of tools by which we could express to the world the value of our contribution. But more importantly, it enabled us to give voice to the oft-forgotten or silent users who eventually are the benefactors of our engagement with the process.
In the last several years, we’ve heavily promoted the use of prototypes that can be used for testing with users, and therefore providing early stage value to a project, and also as a means of visualising requirements for stakeholders who all too often don’t understand what they are asking for – or getting – until they see it.
Building prototypes wasn’t so easy in the days of Visio. Some people used Fireworks, some used linked pages in PowerPoint, while others used paper and walked through the process with users.
While these tools were helpful, they were still often frustrating to use, didn’t really provide a level of interaction indicative of the intended design, and felt rather primitive at a time when people’s perceptions about digital were that it was quick and easy to manufacture.
So inevitably a number of automated tools, and web-based tools came along for us to use in our daily work.
I believe this change in our toolset has signalled a tipping point for UX. And I’m not sure the changes are all for the good. Yes we can now create clickable prototypes that range from simple block diagrams to fully skinned pages. We can test them with users and parade them in front of stakeholders. We have tangible interactive work that can be used to wow prospective employers.
But, at what point in the process do our UX teams become developers – and to make it worse, developers whose code isn’t capable of being used for anything other than demonstrating the possibility of what can be developed by real developers?
I’m thinking back to when I ran a product design agency. We had a full-time in-house developer who built all of our prototypes. This left the UX team with time to focus on thinking through the client’s issues, interacting with users, collaborating to share ideas, and designing – but with a lighter initial touch – before going too far down the road of final design.
When we introduced Axure, there seemed to be more focus on the tool, what it could (and couldn’t) do, and the conversations were more focussed on how to do something in Axure – and less about what the best interaction pattern might be for the situation.
Since then, I’ve observed teams struggle with finding the right balance with their UX tools. I’ve watched them spend significantly less time sketching than they used to before jumping straight into their prototyping environment.
Collaboration increasingly is about setting up master templates and dynamic panels, getting the pixel perfect template, and then using precious UX time unpicking these things to make what are often quite unsophisticated, simple changes. Keeping in mind that we’ve not been allocated some magical extra amount of time to make what amount to programming changes.
There are times, where if I didn’t know better, I’d think I was back in the world of Alan Cooper’s ‘The Inmates are Running the Asylum’.
It sometimes feels like I am not observing UX professionals doing UX work, but instead watching developers developing code, checking code in and out (in the form of shared pattern libraries), debating the ownership and attributes of the components, debating the best use of dynamic panels, etc.
I’m worried about how far all of this goes before we’re no longer representing the user, but instead doing the best we can with the software tools that we are using and within the time we have – which now includes a significant amount of time designing interactive components, changing and modifying them, de-bugging them – all of which makes us sound a bit less like UX people and a bit more like programmers.
We are already seeing a trend in agencies and clients looking for specialist UX Engineers. These technically-oriented UX professionals are essentially developers with UX capabilities. How long before we fully become the very thing we evolved from – developers doing UI?
I’m curious what new people coming into UX think about this. Generally, I’d really love to hear what people feel about the balance between practicing UX and using tools to enhance or extend what we do – and if anyone else thinks this is a problem.