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

Example 2—Stakeholder Goals Over User Goals

This story is about a group of interaction designers who were newly hired by a company that had grown huge and done very well making business to business (B2B) portals in the apparel domain. As in the previous story, it was primarily the product team which shaped the information architecture (IA). The interaction designers did not have much of an influence in determining IA although their inputs were taken for micro IA. Their main task was to come up with the user interface. No form of user research or usability evaluation existed and the interaction designers saw the current product development process as a grossly inefficient process. They would often have to go back to square one from a stage where the UI was not only prototyped to high fidelity but was being developed by the programming team as well.

It was thus not surprising how much they wanted to introduce usability testing which they would like to see happening throughout the software development life cycle (SDLC) from beginning to the end. This would help not only them but the entire project teams to deliver products faster and with less time and effort wasted. A year down the line after a lot of talk, two interaction designers managed to break through with their product head. He wanted to use their help in understanding the major pain points their users faced while using one of their portals for fabric manufacturers and traders. He also wanted to know how best they could go about improving their portal in relation to the pain points that were to be figured out.

The product head gave them a week to do all they wanted as long as they did it on a zero budget. The interaction designers’ plan was to first conduct telephone interviews to understand the most common problems their users faced, after which they would follow it up with a usability test to validate those concerns. But since they had just a week,they decided to only conduct telephone interviews and present their findings to the stakeholders. Taking into assumption that things would go well and the stakeholders would be impressed with what they would uncover, they would then ask for another week to conduct usability tests. After getting a list of phone numbers out of the customer database,they began their interviews. In four days, they worked extremely hard and managed to successfully complete 100 semi-structured interview sessions. They spent another long, hard day affinity diagramming.

Once they completed data analysis, they put in a few extra hours at the cafe below their office. After many a cups of coffee and bagels, they were ready with their report which they would refine over the weekend. Monday came and they presented their report to the project stakeholders. Besides letting the stakeholders know what was working well and a number of interesting UI concerns they had uncovered, they talked about how much their users complained about the clutter on the homepage and the search engine results page which was mainly due to a lot of banner ads and featured listings. They pointed out that participants were unaware of the free registration option which was hard to to locate on the portal. The report also mentioned that participants found faceted search very difficult to understand since the portal used full page refreshes instead of partial page rendering (PPR). In addition, they let their stakeholders know how participants were taken to the portal’s registration page instead of the product details page when participants used a search engine to search for the best prices they could find for the fabrics they were interested in purchasing.

By the end of the meeting, everyone was tired and the stakeholders were not impressed. The interaction designers were not in a good mood either. What happened during the meeting was that while there was agreement on a few findings, most of the meeting went on arguing about how most of the findings directly clashed with either business and marketing goals or could not be implemented due to technical limitations. The stakeholders did find some of the findings useful but thought there was too much signal-to-noise ratio. In their opinion, the interaction designers were not aligned with business goals or the technical constraints the project was working within. In fact, the stakeholders agreed to work on certain features based on their findings that they thought made sense but asked the interaction designers to skip the usability test which the product head had earlier agreed to because they did not want them to validate concerns that could not be addressed, since they clashed with business goals and technical constraints.

The interaction designers’ hard work had gone waste and they did not get any user research opportunities thereafter for almost another year.In addition to other findings, their findings revealing clutter on the website due to ads and paid listings were actually not revealing at all to the stakeholders who had known all about it, but this was where user goals and business goals clashed. Ads and paid listings were a substantial portion of their revenue and the trial user research activity was not going to change their business model.

Takeaway

More often than not, business goals and user goals don’t align well. When trying to introduce UCD into an organization, this is something you should take note of. When you get an opportunity to conduct UCD activities,you are trying to demonstrate value. Begin by showing that you are aligned to business goals unless you want to start of on the wrong foot. When you focus on findings that are essentially user goals clashing with stakeholder goals, then you are diluting the effort and impact of your activity. So focus on and present findings that do not clash with business and marketing goals in order to get maximum mileage from your effort.

If it is of any consolation, as your stakeholders begin to trust you more and give you more UCD projects, you can then make your case down the line, after establishing credibility with them and all the data collected over multiple research activities, if you foresee an alternate business model for increasing revenue. Also, respect technical limitations. There is nothing you can do about them. Avoid making recommendations that cannot be incorporated due to technical limitations. Making the recommendation does not magically lift those limitations. An ideal solution is not a solution, a realistic one is. So concentrate on what is achievable and you will do a lot better.

Pages: 1 2 3 4 5