UX and ways of thinking
Recently I’ve found myself once again facing what’s become a familiar old problem for me, and giving considerable thought to the way my colleagues’ brains work. I work as a UX lead, spread between half a dozen agile development teams, each tackling a different software product. After two years of experimentation I have to say we’ve gotten pretty slick at working together. We’ve cracked merging UX and agile in a way that works for us, we understand each others’ contributions and are even finding the boundaries between our roles occasionally blurring. For the most part, it’s working brilliantly.
The challenge of balancing ‘top down’ versus ‘bottom up’ thinking has come up many, many times in my career. Some people – and they are often but not always, designers – are at their best tackling problems with a ‘top down’ approach. This means starting with a big picture, or overview of a system without having specified every constituent detail. In software terms this might mean e a conceptual wireframe of how the product will be used at the next big release or further into the future. It will likely be fuzzy and uncertain in places, with some key components and over-arching characteristics clear, often details we have highlighted through user research. We then begin working down from the ‘vision’ of what is to be achieved, breaking it into smaller parts and defining details during development.
Conversely, ‘bottom up’ design means working in the opposite direction. Individual components of the system are figured out, sometimes in great detail first, and linked together to form larger components, gradually building and building until the complete system is formed. People who work better this way are often – but not always – engineers or developers. In software terms this might mean starting with technical requirements or a waterfall spec, listing features or components but with little idea yet how the end product will be to use. The difference is that a purely bottom-up approach will never form that vision, making it an ‘organic’ strategy, without much in the way of a clear goal. The agile manifesto assures us that we’ll get to where we need to go eventually, but unless everyone has a similar endgame in mind the reality is often a tangle of elements, built in isolation by different developers who all had a slightly different take on things. What I refer to as a ‘patchwork quilt.’ Naturally, this is not the way to build a cohesive, successful user experience.
Many years ago I was working with a team of mechanical and electronic engineers on the design on a handheld medical device. In this case the mechanical engineer was acting as project manager, and had elected to save time and cost by removing any research or design work from the plan – or so he thought. He advocated a ‘bottom up’ approach, whereby the engineering team would specify each component one by one and build up the device design collectively. His opinion was thus – we understand the technology, we can build an efficient, high-performance and cost-effective product (this part was mostly true). This will result in a naturally better experience and therefore any design work is an overhead to be reduced, reserved for CFM (colour, material and finish) and marketing materials. This is a misguided idea that I have heard far too many times, often exacerbated by the assumption that your users think the same as you. Unfortunately it highlights the manager’s lack of experience and probably, desperate need for contact with real users of the potential product. It’s also a shortcoming of a purely agile development process in that it assumes a bottom-up approach will deliver the goods, but speaking from experience this is not always the case. In fact it’s so rarely the case that I don’t believe agile even begins to realise its potential until you add research and design activities into the mix to get some top-down in there, too.
At the other end of the scale, there is danger in working purely top-down if you expect that beautiful design vision to be delivered as intended. I learned early on in my career that detailed, immovable design visions can be as much a hinfrance as waterfall specs unless they are continually evolving. Hire a design consultant, and unless they’re embedded in the team for the duration, there is a serious risk of them handing over a vision like this, and the dev team following it blindly even when the project has outgrown it. Sorry guys, you’ll need to stick around and muck in. A very effective aspect of agile is that it encourages conversations and doodles over detailed documents, and thus maintains our ability to change quickly.
Back to our story: the medical project went ahead without me and the end result was sadly a flop – robust, easy to manufacture, reliable, yes. Did it do what people needed in an intuitive and satisfying way? No, it did not. Did people want to buy and use it? No again. The project had to be restarted at considerable cost. They had saved some money by cutting out design in the short term, but spent much, much more in the long term by heading down a blind alley. Design and research activities would have reduced risk considerably and steered their work towards a user experience worth buying. I think there were lessons learned for all involved, including myself. I learned that I should have done a better job of convincing my colleagues of the above, so we might have all avoided the wasted time and money.
This was a fine example of a project that needed both bottom-up and top-down thinkers. Bottom-up to ensure the aforementioned efficiency and performance happened, getting the right components and figuring out the all-important details. Top-down to ensure the project was steered towards a worthy goal – an idea of the eventual user experience, informed by research and communicated clearly so that everyone involved shares the same vision. In every project, as development work proceeds, details will emerge that will better inform the vision, and so it must be updated too. This is why at DNV GL our preferred process builds iterations for that vision into the sprint cycle along with the code.
The challenge I mentioned earlier was a friendly but significant clash between myself and colleagues, discussing the long-term future for a particular software product. As bottom-up designers, my colleagues wanted to use the organic approach, convinced it would lead us in the right direction through small, iterative improvements. I was concerned about this and had, without being asked, prepared a rough storyboard detailing a possible user journey, I was trying to persuade my colleagues of the need for a well-informed but flexible vision, one that we could all agree on that might gently steer the agile process and help build something more cohesive.
My colleagues, not used to any other ways of working but bottom up, were worried that my ‘vision’ was an unnecessary distraction and would constrain their thinking. Studying my rough and ready UI mockups, they were concerned that I was worrying about icons before tackling more important issues. In reality, I had made them first for other members of the development team prefer to think top down, and for them the mockups illustrated a potential future and stimulated discussion. The colleagues I was talking to that day, were used to bottom-up and I learned, didn’t process the mockups the same way, focusing on small details without seeing the whole user journey. I needed to try communicating this in a different way for them, perhaps in more of a story map fashion. My challenge has been to find the right way to help them, whether know they know they need it or not.
It’s easy to start falling into an ‘us and them’ mentality when working with people who think differently to yourself, and any designer needs to avoid that at all costs. When everyone involved understands their colleagues’ jobs and why we need different types of thinkers, there’s no reason for animosity – and besides, when has that ever helped you? We designers are going to have to be thick-skinned and very persistent sometimes, but remain positive and perceptive. Remember that because we all think differently, we may take different approaches to the discussion and need different tools to aid it.
After many years and many projects it surprises me sometimes to still find myself defending the right of design to exist in 2015, but in many industries – often scientific and engineering focused – design is relatively young and still finding its feet. Those the designer will work with may not see the value of UX, and may even dismiss it as an overhead until they know better, so it is up to us to learn from our experiences and prove to our colleagues that together we’re stronger and our customers happier.