After nine years of building a robust UX consulting practice within a large software consulting firm, I sort of expect certain things. For one thing, I expect that the people in my organization understand the basic importance of what I do. I’ll bet you do, too. While we might not always get all of the time we’ve scheduled or be able to do all of the things we want to do on a project, in general, our expectation is that, at some level, most people recognize the importance of user experience these days. After all, even when some auto parts store in some remote part of the world revamps their Web site, they tout their “simplified user experience.” When you see that, you start to think that this whole UX thing has become institutionalized to some degree.
That’s why it came as a bit of a shock to me recently when I realized that the issues one of my consultants was having on a project were the result of a development team that felt a good user experience just wasn’t critical to the project’s success—or to the product’s overall user adoption.
Champion Advertisement
Continue Reading…
Doing Everything Right with the Wrong Outcome
Sometimes, no matter how much you plan for things, you start a project off on the wrong foot and things tend to quickly spiral downward. On this particular project, everything seemed to be set up for success on the project:
User Experience was involved right at the beginning.
The UX team’s expected deliverables were clearly defined.
We had a seasoned project leadership team—people who had worked with UX folks before and saw their value.
The project timeline included time for research, design, development, and testing activities. The schedule was a bit tight, but everything was reasonable.
But, despite all our best efforts, planning, and skills, we faced issues with what I have found to be the number one project killer: people. Whether team members, partners, customers, or users, it is the people who can make or break your project. That’s why, for great UX consultants, people skills are the foremost skillset in their arsenal.
On this particular project, it was our own team members who caused the biggest issues. Our Business Analyst felt that he could do his own job and user experience, too. Plus, our Lead Developer felt that all he needed to worry about was functionality—UX design was just nice to have. And, on top of everything else, our Project Manager felt that UX design, though important, was not critical, considering the timeline. All of these things contributed to an almost hostile work environment for my UX consultant. Nevertheless, every day of this project was an incredible learning opportunity—both for him and for me, in my higher-level leadership role.
One thing I tried to teach the team—with an admittedly modest success rate—is that good teams trust one another and understand one another’s skills. If you don’t have trust and understanding at the core your project team, your project will fail—even if you make your deadlines. However, trust and understanding don’t always come easily or naturally. You have to work to achieve them. For example, this means not taking things personally and understanding how to deal with what people say in a productive manner.
Dealing with Outlandish Statements
This project was a great example of all the crazy things I’ve ever heard people say about user experience—all rolled into a single experience. Throughout this project, as a UX person, when I heard people saying things about UX design, it would have been easy to get annoyed and just say, “These people don’t get it.” However, if we wanted to build the trust and understanding that we need on a project team, so UX gets support and can flourish, a dismissive attitude would have been the last one that we should take.
Let me give you some examples of comments that we heard on this project and how we dealt with them.
“I have been doing projects for years. User experience was never a focus before, and those projects went fine.”
The first thing is to try not to go on the defensive, but recognize that this is an opportunity. You must recognize that this person is resisting change. We all have resisted change at some point and know how difficult it is to accept change. Tap into the empathy that makes you a great UX professional—and this time, use it not for a customer or user, but for your own team member.
In this particular situation, we first agreed that they had, indeed, been doing projects for years, and most of them had probably gone fine. However, this project had some unique challenges because an amazing user experience was a requirement for the application we were developing. We also talked with the person about the fact that, over the years, the team had probably revisited and improved upon the design of those applications, long after their initial delivery. While UX design may not initially have been the team’s focus, should it have been?
“User experience is important, but it’s not on the critical path.”
This was an interesting sentiment to deal with, because all of our planning had shown that UX design was in the critical path. Only once we had started running into time pressures did people bring up this viewpoint. However, looking at the underlying issue here, we realized that it was not that people were criticizing User Experience, but that they were criticizing anything that seemed to block the team’s ability to execute the timeline.
To deal with this sentiment, we did a bit of ad-hoc replanning. We looked at the UX activities that we had planned and reworked our plans to fit them into the abbreviated timeline. By taking the initiative and showing that our activities were flexible enough to allow them to work within the project schedule, we also showcased our ability to value the product team. This had the desired effect of building more trust and understanding, so the team saw UX design—and the people delivering the design—as valuable.
There is room for improvement on the User Experience side of the house in this regard. There should be no preciousness associated with UX designs and the activities that support them. We, as UX professionals, need to be flexible, not only in what we do, but in how we do it and the time it takes us to do the work.
“I am a Business Analyst. I know what the users want”
It is common to hear this sentiment from Business Analysts (BAs). That’s because a BA makes a huge contribution to the process of creating a great user experience. The challenge here was that this particular BA thought he was the only one who knew what the users wanted, so needed to drive UX design.
In this case, we were unable to change from within because of the BA’s attitude. No matter how hard we tried to collaborate, he rebuffed our efforts. At this point, our strategy changed: We engaged both our internal project leadership, who remembered how valuable UX had been on other projects, as well as customers, who were incredibly supportive of our UX vision for the product we were creating and felt invested in it. By leveraging these two stakeholder groups, we effectively mitigated the negative and domineering influence of the BA.
Conclusion
User experience has come a long way in a short time, and its importance is increasing. When we adopt some of the same best practices and tactics that we would use with difficult customers, stakeholders, or even users and apply them within our own internal teams, we’re demonstrating skills that make User Experience a critical part of every project team.
Hello, I find these examples of every day work very useful. But I have a question—maybe it’s a silly question…. When you talk about:
“We looked at the UX activities that we had planned and reworked our plans to fit them….”
Could you give some examples about those activities? I keep reading stuff like this, but no one mentions what they do, in a specific way. I’m very curious to know what UX activities you consider to be the usual on a project.
Thanks for your comments. Some examples of UX activities in this particular instance were additional user research, cafe usability studies, user playback sessions, wireframing excercises to flesh out some new functional additions, and reworking some of the visual design.
We have a lot of specific activities in our toolkit, and we use them depending on the type of project we are doing. For a more general overview of UX activities, I particularly like this site.
Great article. How would repond to a statement raised by a client saying, “I’m not feeling this [UX design]. This does not excite me….”
Otherwise, a very helpful article.
Hi, I agree with all that you said, but in my opinion, at the end of the day, UX depends upon two factors: One is how efficiently and effectively your designer designs your Web page to satisfy the user. The second is how your user perceives the effort of the designer—you could say, what the user is getting from your design. These two things are closely related to each other.
Hi, thanks for the comment and question. You pose an interesting question, and I hear this a lot. Generally, when I hear “I don’t like it,” the first thing is getting to why. Is it a task thing, a color thing, an interaction thing, or what? Getting to why is necessary to address it.
At Pegasystems, Baruch helps global clients develop new ways of streamlining their operations, improving their customer experience, and creating real transformations—digital or otherwise. Previously, during his 12 years at Pegasystems, Baruch led their global User Experience team and served as the principal end-user advocate for the Pegasystems Services organization in their delivery of user-interface design and user experience to customers and partners. He has led and participated in successful efforts to improve user experience across various industries. Baruch earned his Bachelor of Arts in Professional and Technical Writing and Philosophy at the University of Hartford and his Master’s of Science in Human Factors in Information Design from Bentley University’s McCallum Graduate School of Business. Read More
