The scenario
The head of product is senior in the organisation. They do a good job, guiding a large and talented multi-disciplinary team. They also manage stakeholders, liaise with other parts of the business and, of course, go to lots of meetings. They are in constant demand from everybody and have little time left over to really consider ideas – in fact they need help to develop and sell ideas to the people who will want to commission them. So far, this is all vey understandable.
Who is it that can assist with this?
Well, user experience & design specialists are the most appropriate for helping take ideas and make sense of them – often to visualise them. They are brilliant at taking complex ideas and making them easy for others to digest. They can make wireframes, examples, mock-ups, walk-throughs – you name it, to help show why a vision for a product should be turned in to reality.
Call it human nature, but somehow many of us seem to think that once something is written down it is legitimised. Subconsciously, we look at the clever designs that have been produced and the perceived options narrow – our own ideas begin to fade away. Our perception of the reality to come is increasingly based around the craftsmanship of the UXD’s interpretation of the Head of Product’s idea.
Hidden problems
In my scenario, these designs are ‘signed off’. Expectations are set and the final product becomes more about bringing the visuals to life than satisfying a true business need. Eventually, they are passed to business analysts, developers and testers. This is where the problems that have been hidden so far become apparent. There are some questions which, in the complexity of getting the idea commissioned have not been pushed enough, such as:
- What is the intent behind this product?
- Who is it for?
- What outcomes do we want to see?
- What is the business vision?
- How will we know when it is done?
- What are the options we have for building it?
- What are the key features that are needed?
- What’s the best technology to use?
- How will (feature x) work?
- In which context does the user use this?
…the list goes on!
You see, the real problem is not with UXD – or any other discipline in isolation for that matter. It’s to do with team work – or the lack of it at all stages of the product development lifecycle.
We can take the scenario one step further. As requests are getting through to development teams without being properly thought through, the developers and testers especially are beset by rework – patching up product that has already been delivered, due to assumptions and badly communicated requirements that were never thought through properly to begin with. This means they are always behind and under pressure to deliver, meaning they don’t have time to get involved in working through ideas to begin with.
So how do we break the cycle?
It’s easier said than done, yet by no means impossible. Make sure your ideas and requirements are properly considered before developing them. That’s not to say you should do all the design or specification upfront but that as much as is possible, problems should be considered as a whole team, or at the very minimum with one developer, tester, business analyst and a UXD representative. Involve your product owner and any stakeholders you can, if possible too.
Always remember that to build a good solution, you need to have a good understanding of your problem first. Then remember that it is cheaper and faster to fix your understanding of a problem than it is to re-build a broken product solution.
