In previous years, we have been guilty on increasingly investing too much time in the UX ‘production’. In some recent cases the time taken (duration) – not effort (person-days) – exceeded the development time! And the first thing to get cut to make up the lost time? Testing.
We needed to act. We needed to stop wasting our clients’ time and both of ours money.
The ‘Why change’ is fairly obvious, but it is worth exploring how we got there, what indicated to us that it wasn’t right, and what we are now trying to do:
How we got there
We traditionally focussed on pixel perfection and big upfront design phases. Specifying every last interaction and pixel. Then, once handed over to developers – often later than the dates in the original project plan (!) – the designs and wireframes were never to be tweaked again.
Or at least, not until after they launched six months later.
We were increasingly designing and developing in isolation, which when developing complex systems that are functionality and data driven, is dangerous. We found ourselves separating out the ‘design process’ as a distinct, stand-alone phase. One that we attributed significant time and financial value to, but intrinsically isn’t the deliverable for which our clients engaged us.
We needed to take the focus away from stand-alone UX methodologies and place it on delivering business value – and perhaps more importantly bringing the end product to market faster.
We needed the design and UX phase to be more Agile, I suppose.
How we noticed the problem
Looking back there were clear indicators that this wasn’t the right approach, here are some of them that we noted:
- Mocking up a solution before defining the problem
- Arranging a lengthy interview schedule and big discovery phase before even speaking to one user
- Writing detailed research findings (we aren’t a research company….)
- Wireframes with double-digit version numbers
- No conversations about database design and the technical impact of functionality before the wireframes are drafted
- Not giving the client options on what they wanted to sign off. Were pixel-perfect wireframes even essential? Will they read a 120 page Functional Spec? Some want to, some don’t
- The UX person didn’t speak with the developer during development
- Wireframes that are a developmental cul-de-sac. All that nice HTML put in the proverbial development bin because it can’t be used
What we are trying to do now
It is not as simple as making the UX stage faster or less rigorous. It is about changing its nature from being an individual’s responsibility to making it a group one. Yes, wireframes and Functional Specifications still need to be produced, but the process of defining them now is collaborative and involves: the client; the user; development; design and project management. Drawn together by someone who understands how to strike a balance between them all and is ultimately responsible for the outcome – a type of product owner.
From a design perspective we have broken it into two stages. First is an early stage ‘Look and Feel’ in order to determine the design principles and interactions. Second is ‘styling’, where we refine the front-end development from both an aesthetic design perspective and also an interaction perspective.
From a UX perspective, the involvement runs throughout. If we’ve understood the business and user goals correctly, then the role of UX is to guide and help the development team. It isn’t to specify, but to direct. It is also the responsibility of all involved.
Software development wise, we focus on ensuring the database, logic and functionality are all correct first. Getting the foundations right, early, is imperative to delivery and stability. The more complex the system or site, the more this rings true.
When I look back over it all, I guess what we are aiming to do is to work smarter, not harder. We work in a world of commercial realities and limited budgets. If we value our time, the chances we will value our clients’ time more.