When Introducing UCD in an Organization, Technical Capability is Only Half the Story

Eventually the day arrived for presenting the findings. It was presented to the VP and most of the leads from the programming and product teams, in addition to a few other programmers and product folks working on search. The presentation was well made and the recommendations were convincingly put forth. All in all, there were reluctant but agreeing nods to the findings. The report did not speak much about what was working well in the search and SERP (search engine results page), perhaps there were indeed not many positives. The report concentrated on the utter failure of the faceted search that was neither noticed nor understood by most of the participants, the excessive unused elements that cluttered each search result listing and also how the positioning of the search user interface failed to imply it was to be used for both global and local section searches.

The report also let the interaction designers vent their frustration because they had pointed out the issues with faceted search and positioning of the search UI to the product team and the VP at the time of paper prototyping, but they had not paid much attention to it at the time. This point too was made clear during the presentation quite a few times.Once the presentation was over, a bunch of programmers impressed with the empirical findings went over and congratulated the interaction designers on their work, although they now had a lot more UI fixes to make, thanks to the usability test recommendations that were agreed upon. And this was all the praise the interaction designers got.

They barely received any praise from any of the senior folks on the project.The report did not make the VP look good in any way. In fact it made him look bad. And so was his experience interacting with the interaction designers from the first day of planning for the usability test right up to the end with the report. The findings criticized most of the project at a structural level, constantly reinforcing the message that related risks had been pointed out but nothing has been done about them. What started out with a positive outlook towards usability had transformed into a bad exercise for him.The VP’s final take was that the project could be seen as a waste of time since it took up a week and most of the findings they agreed upon were very minor changes they could have done without. At this stage, the plan could not accommodate structural changes and the VP, along with other heads, dismissed the results and quickly agreed that the sample size was too small.

And this made it easy for them stuck to their gut feeling that the faceted search would do just fine. The same was the case for the search UI positioning in the page. The VP also managed to get the product leadership’s consensus that the data was skewed and was bent towards supporting the viewpoint of the interaction designers.That was pretty much the end of their UCD gig as long as they were on this project under the VP. He spread the word about how difficult they were to work with, how they were not being aligned with project goals and that they could do with more professionalism. The VP also cancelled his earlier agreed plan to let them perform usability tests in the next iteration when they worked on CQA. With the VP spreading such a negative influence, it was not going to be easy for them to get opportunities to conduct usability tests or user research on other projects in the future either.

Takeaway

Who are the key keepers? Those who give you or your team the opportunity to implement UCD techniques, some form of usability evaluation or user research on a product are the key keepers. Usually higher up the organization chart and very influential, they hold the keys to the kingdom—the kingdom where you can get to keep yourself busy improving the user experience of products by incorporating UCD techniques in not just a few, but all projects. While they hold the power to give you a continual list of opportunities over time, they also hold the power to close the gates and shut you down. In other words, they make or break your group. Make sure you never make them look bad in anyway at the expense of trying to achieve perfection. Because ultimately,if they decide to not like your work, it will not look good, however good you may think it is or it actually be.

Looking back at the story, there was nothing really the interaction designers had actually done wrong, but they could have made a few concessions for the VP. They could have sent over a one page email plan as the VP had requested, they could have allowed him to attend any usability test session he wanted and let him ask questions in one of them before they requested him to hold them till the end, and they could have provided him with a summary of findings at the end of the day, just the way he wanted. When it came to the report, cushioning in hard findings with a lot of good stuff to say about the project, even if it was superficial, would have harmed nobody.They should also have avoided venting their frustrations about how the findings were in line with what they had pointed out as risks earlier.If they had done this, it would have been much more likely that they would not have been shut down.

By capitalizing on the VP’s initial positive outlook, the same exercise would have come to a very fruitful end. So if there is anyone you should use your soft skills on across your range of stakeholders, the key keepers are the ones you should use it with most, because their voice matters the most in terms of getting approval for the UCD activities you are trying so hard to introduce as a better way of executing projects in your organization.

Pages: 1 2 3 4 5