This spring I had the privilege of attending Minnewebcon – an interactive web conference. As a UX person, I wanted to hang out with “my people”, but I couldn’t help but be drawn to the development track. There was one talk in particular that was a call to action for developers to get involved with the user-experience process and provide their insight. I was warned ahead of time by the speaker that this talk wasn’t for me, but by the end of it took everything I had not to start waving my flashlight app in the air.
One of the reasons I came to RBA was the desire to be integrated with a technology team. In the same way that I can’t do my job with user input, I also can’t do my job with developer input. UX is fundamentally an interdisciplinary field that requires intense collaboration from beginning to end. We are called upon to be the bridge between people and technology. We are taught to properly define the problems before solution. And although I might love focusing on understanding people and problems, at the end of the day I still need (and want) to bring it back to solutions and technology.
That is where development comes – we must balance user goals and business goals with system constraints. It’s obvious that we need each other, but that doesn’t mean that collaboration happens when it should. Development can feel left out in the beginning of the design process because valuable insight isn’t sought during business discovery and requirements gathering. On the flip-side, as design comes to life, changes will inevitably happen without UX involvement.
So why aren’t we working together?
There are often misconceptions that get in the way of a happy and healthy UX-Dev relationship:
Dev builds what UX defines
False. As a developer begins to interact with a design, usability problems and additional use cases will come to light. This is completely natural and inevitable part of any design process, especially when no prior prototyping has been done. Having a UX person involved in a pseudo-QA role can help you evolve and adapt designs as needed.
When it comes to UI, UX only needs to work with visual design and Front-End Development
False. Back-end developers provide valuable insight into data structures, feasibility, performance and security implications. All of these factors heavily influence the user experience. Even software without an interface, still has users. Ergo, it has a user experience.
We can’t afford to have everyone working at the same time
I’m not a project manager, but as the great Tim Gunn would say “Make it work”. In an increasingly Agile and lean world, this is just the way software is made. Maybe that means juggling multiple projects, or a series of quick side conversations, but there has to be an understanding from your project steering team that you lose more than you gain by tossing things over the fence.
How can we help each other?
At the end of the day we all want the same thing. User Experience professionals might feel a sense of ownership of UX methods, but we know that all parties must buy in to user-centered design and play a part in creating great experiences.
Create not just usable, but useful things
Just because time isn’t allotted to proper envisioning, doesn’t mean it won’t have to be done. It will just happen ad-hoc during (or worse yet after) development – often leading to rework and undercutting team morale. Through proper business discovery and user research, UX can help ensure that development focuses their efforts doing the work that matters most.
Suss out edge cases and co-solution
There is often a trade off between simplicity and flexibility in application development. UX people focus on user needs first and foremost, but they often don’t know what is needed from a systems perspective. Development, on the other-hand, is a great at generating scenarios and edge cases – a critical component of interaction design. By scheduling collaborative sketching sessions and rapid iterative prototyping, UX and development can work in tandem to eliminate bad design decisions before they happens.
Determine feasibility
In this day in age anything seems possible, but deciding “is it worth it?” or “should we?” are the bigger questions a project team needs to make. UX people may not know the performance or development impact their designs might have, but they do have an intimate understanding of what users and business needs. By communicating while designs are still just concepts, we can better identify if the time spent developing a particular solution is commensurate with it’s relative importance to the user base and the business. Or if the performance hit will cause a greater impact to the users experience than the interaction itself. Unfortunately, these conversations often get pushed off until after wireframes have been signed, sealed and delivered to development – hence wasting countless UX hours. Mitigate these problems, and have the “Yeah, but” conversation with your developer early and often.