Once again I have wandered onto the battlefield between the entrenched armies of UX and development. This is dangerous ground in my experience. The right-brained developers fire their ordnance of logic and process and receive in return the left-brained UX bombardment of creativity.
Of course, both are absolutely vital to delivering first-class software. It’s like combining water and oil, but as any physicist will tell you, it’s difficult but not impossible with a little bit of effort to create an emulsion of the two.
My challenge was that the UX designer wanted to create pixel-perfect screen designs as input to stories. In other words, do all the design up front, which isn’t very Agile. Doing a sufficiency of design up front and expecting an iterative approach is usually more pragmatic. I prefer to take this approach and let feedback help us identify the final release.
I discussed this with a colleague who brought up another extremely valid comment. He said giving definitive designs to developers encourages poor development practices. If the developer is expecting no change to the UX design, then he or she is incentivised to deliver software that does not support the ability to absorb change inexpensively. Why bother to build it in if it’s never going to be used? That’s a good Agile principle, not to build what you don’t need. However, it’s obviously short sighted and will lead to an increased cost when change occurs, as it invariably does.
For example, why bother rendering a screen using a cascading style sheet when you could just knock up an image and show that instead? If no changes are expected because the design is ‘perfect’, bad practice looks attractive.
I think the thing I find most difficult to accept is that people actually believe they can get the UX 100% right, or close to, first time. Why is that? I think it’s fair to say that there is a general acceptance that you can’t get your technical design perfect up front. So why is UX any different? How can it be completed when everything around it is in a state of constant flux? And we shouldn’t be waiting to create the last, low value pieces of a screen design when we could be getting real feedback from an early version and applying our efforts to more valuable work.
UX is a type of design and no different from any other design needed within the project. There needs to be a sufficiency developed ‘up front’ and it should be expected to be progressed, refined and probably refactored a few times during development. We need to expect change and build with the ability to accept it inexpensively when it comes. Of course, this is a balancing act and we have to be pragmatic on how flexible we need to be, but during the project we are capable of making that call.
Two things I have found that make UX people more comfortable are: the reassurance that they can stay on the team to some degree and continue to design as the system emerges; that they can have a ‘bucket’ of points to allow them to change their mind or make refinements. Obviously, the bucket is sized offering a budget for rework.
So I am a bit confused why this is still a problem. Part of UX is ‘experience’ so why don’t people believe that experimentation and feedback is vital to the overall quality of the product? Ahh, maybe because I have one of those ‘right-sided brains’ and I simply don’t understand, but I am not convinced. I was warned by a friend that this may start a flame war with UX designers. I say open discussion is a good thing here, so happy to be burned to a crisp if it gets us closer to a common understanding. When I say common understanding, I really mean agree with me! :)
If your organisation is looking for support in taking iterative approaches to design and development, please get in touch.