Working well within an Agile is hard. I’d like to start by dispelling some myths; Agile is NOT about:
- Getting stuff done faster
- Getting stuff delivered cheaper
- Getting stuff done with the least amount of input
I have been lucky enough to work with some amazing product owners and managers; but I’ve also been unlucky enough to work with some in the past who have taken on the role of benevolent dictator. Even so, if agile is hard to do well, good UX in agile is even harder.
If there is a perception that the least amount of effort to get the most amount of impact is required to demonstrate value to the business, then UX is often (and potentially increasingly so) reduced to the most basic elements, which is effectively is interface design. If the interface is all that the business considers to be the ‘User Experience’, then all an organisation really needs is a pattern library. It gives the developers the ability to implement a design in a consistent way that creates familiarity for the user. If that is what matters to the business then this ultimately constitutes as the user experience; de facto.
At a recent conference a colleague (a product owner) asked how was the best way to resolve the conflict between User Experience and Product Ownership. The answer was surprising in that it didn’t answer the question; ‘Let designers design, that’s they are employed for and that’s what they love doing’, sic.
Firstly, UX is not primarily, as a starting point anyway, about the activity of designing; if you are asking for designers who can use Sketch, then you aren’t employing people who ‘do’ UX. (Yes, the user interface is your user experience, but as above, that is a response for another post). Design IS about solving existing problems, granted; but without a meaningful context, how can you define the problem or remove the pain point that creates additional revenue?
Though, it IS absolutely the responsibility of the product owner or manager to own and prioritise what gets the most amount of value for the business. However, in the context of User Experience, it is forging this working relationship in the context of unknown problems to be resolved, not problem statements which should become the focus for the UX’er. It is often even harder to show that something is a problem without the ability to demonstrate that it is; this is why the vehicle for proving this is usually down to small manageable changes to the interface rather than identifying the bigger issues.
This is my point; in this kind of environment, we often have to explore problems that we are not sure are problems to resolve. The absolute difference here being that there are known problems, there are problems that we know we don’t know about, and there are problems that we don’t know we don’t know about. There is nothing worse for a UX’er to be told to explore a crap idea that, with then benefit of years of experience, isn’t the issue at hand but that someone else thinks is a problem. More often the problem is being caused by something somewhere else.
Without context, metaphorically, you are sat in front of a huge mixing desk of dials twisting them a little or a lot without not understanding what impact one dial has on another. So, in the context of agile development, real user experience must be about a closer working relationship with product ownership to show, develop and bring about that understanding. In the role of UX, it comes about through testing, learning and exploring; it is about that which must come before and not only about design.
In the words of one product owner who I’ve not only learnt a lot from, and who has constantly and constructively challenged my thinking, it is about ‘being on the right side of wrong’ then, learning from that. Rather than trying to design your way out of a ‘hole’, even though you might end up using the same tools along the way, the emphasis is on discovery and not about design for the sake of design. It is not about ‘what if’ it is about ‘if that, then what’ and answering those questions.
Frazer Cooper 