One of the challenges I've found is ensuring that the user experience and therefore impact is placed at the right location to ensure the best value.
I was recently in discussions with a colleague expressing frustration that myself as a UX designer, wasn't being taken full advantage of. Their comment was that I should be influencing more of our overall capabilities (core large feature sets), rather than the "placement of a button" on a page.
And they're right.
A post written by Jonathan Courtney three years ago made reference to the fact that UX designers needed to be transitioning from simply making things look good and work well (even though still important), to understanding the business and product strategy. This, he argued, is a way to improve job prospects and gain important skills for the future.
I'd take it one step further. My opinion is it also ensure UX is placed at the right time in the design and development process.
My role essentially boils down to wanting to ensure these key items (in order) work together:
The danger I've found happening far too often, is that my engagement doesn't occur until such a point where I can't achieve the above. I can barely squeeze the business outcomes in (placing a button or element that ensures something can be sold or delivered), let alone make it work for the customer or make it work nicely together.
The further pit fall which follows this, is trying to make my life easier by taking away some of my decisions by dictating how something will work, so that I only have to "make it look good." This ignores the core premise of making it work together and making it work into the future. The rework required for short term thinking far outweighs any delay in a build process by ensuring you get the core elements correct.
This brings me to the point of this article: ensure experience designers are engaged early in the process- when a problem is first discussed. In fact, some would argue that if a company doesn't have workshoppers or agile coaches, the UX person should be running these sessions. And these sessions should be run several weeks ahead of build, to ensure the right amount of time to nail down the research, business and customer outcomes and therefore the way these can be made to work best together.
Following successful build, a designer should be enabled to give a go/no go decision based on the agreed definition of ready with an appropriate QA environment.
Now, don't get me wrong. We aren't about adding time to fast moving builds. We are about streamlining it. With the right amount of upfront research and thinking, it avoids countless hours of rework, rejection, confusion, "alignment" sessions and miss-matched data.