Has there ever been a more loaded sentence to describe the goal of User Experience design? I’ve been rehashing former process documents to present something new and interesting to interviewers. Shooting from hip isn’t working. They want to hear something clear, concise and… compelling?
After nearly 15 years of UX design leadership I find that in each situation I have adapted my process to fit the circumstances.
- At Internet Travel Network (ITN), I had a robust development team that was engaged and had good critical skills. We were trying our hardest to create the thing that would make us the travel reservations industry leader.
- At Cornell University, I had to build the team from the bottom up. The process was more pure, but the resources were harder to come by–if we wanted a content management system, we had to build a simple one or convince tight purse strings to loosen and purchase it.
- At Western Union, I had a small team and was stood up against a huge, matrixed, Borg of a development team. When I walked in the door I was told that the design for the product was due the next day.
Each one of these situations required a subtly different process. At ITN we had evolved a sort of proto-Agile work method and focused on small features and big opportunity. At Cornell we created things that were effective, sustainable and made the case for us to take on bigger and bigger projects. At Western Union, we did our best to integrate with the matrixed units while delivering designs that would add true value to the companies efforts. For each situation we were trying to deliver the right solution.
Each word in this goal is loaded with sticky implications.
- Deliver – the idea of delivering a solution is too final. Done. Check the checkbox. Move forward with other things. Aren’t we really kickstarting the engine that will move the project forward? If we create and deliver an over-determined solution, was that the right solution?
- The – can we say that only one solution is the right solution? No way. There may even be an infinite number of right solutions. Perhaps a is a better article. Of the possible sets of correct solutions, this is one.
- Right – even if the solution is the best thing for the user, if it is not sustainable, executable, or even possible for the team that will bring it to life, was it right? So, how do we determine that a solution is the right solution? Was it the right one for the CEO’s timeline? Was it the right one for the development team’s expertise? Was it the right one for the users currently understood to be our targets? What if we pivot tomorrow?
- Solution – this term is so far down the road from the design phase. Yes, the design phase is bringing a solution to a challenge. But it sounds so final. The UX process must dovetail with the other parallel processes. It must react to the needs of the teams involved. It must listen and react to the evolution of standards. Of course, it must elicit and search for user insights.
Is there a good model for a process? Does it look like a waterfall or a series of cycles? Does it look like not much at all?
Is it possible to adapt too much to the teams that surround us? Yes, but I think the process we need to bring along with us is more of a sketch than a recipe. If you have two weeks to deliver a design and your process takes three, what is the best approach? Squeeze it all in? Prioritize the most relevant steps? Say no to the project?
Okay, this was the introduction to the cup is half empty discussion of UX process. Next, I’ll lay out the process that I’ll present to people over the next few weeks. Stay tuned.