Solutions disguised as problem statements

Question

As UX professionals, especially in enterprise settings, we are excluded from the problem exploration and we are given solutions instead. At that point, we start our process from the middle. Depending on the company, the Product might have done some market research, tasked with developing an executive's idea/order but no one has done or thought about doing any User Research to explore the problem(s). If you're lucky, you're given a solution scope statement, if not, you're given requirements. Too late for us to add real value... And at that point, as John Biasi says "Questioning the problem make us look like the problem"

How do you fight with this? What are some tactics that worked for you?

Answer 1

Unfortunately this is the reality of the way many organisations (whether they are primarily IT based or not) think about design, and therefore the constant struggle to find the right balance between business, technology and user requirements that gets added to the product decision process.

I have two primary strategy for dealing with situations when you come into a stage of the product development cycle when you are well past the research stage.

Firstly, if you end up making a lot of assumptions during the design or build stage, make sure you capture those assumptions and assign the relative risk of those decisions. This will allow you to review things that could have been done better or earlier in the next iteration of the product. Also, you should set up the testing process that allows you to build up the questions and research topics that you can try to propose next time.

Secondly, remind them that like software development, there is also an ISO standard for doing user-centred design. That means if your organisation is compliant with any other ISO standards in terms of business or software development practice, you can immediately elevate your design practice to similar standards without needing further justification from a best practice and compliance point of view.

Finally, it is often the case that changes in organisations can take time, and that the important thing is to take steady steps towards the direction you want the design practice to strive for. Sometimes you will lose small battles but it is more important to keep the big picture in mind.