First published on Cone Trees on Sep 29, 2012.
Summary
This article is a reproduction of my chapter in the book, UX Storytellers- Connecting the dots, edited by Jan Jursa of IATV. You can download it for free or get it for the Kindle at Amazon. Other contributing authors include Deborah Mayhew (author of Cost-Justifying Usability), Aaron Marcus (author of The Cross-GUI Handbook for Multiplatform User-Interface Design) and Cennydd Bowles (author of Undercover UX).”
In this eBook, ‘UX Storytellers – Connecting the Dots’, 42 UX masterminds tell personal stories of their exciting lives as User Experience professionals. The book brings together authors from around the world who paint a very entertaining picture of our multifaceted community.”- Amazon book description
My story, “Technical Capability is Half the Story” aims at helping User Experience professionals understand the real challenges involved when trying to introduce User-Centered Design (UCD) techniques in an organization where the goal is to ultimately integrate UCD into the organization’s Product Development Life Cycle (PDLC). It talks about how arming ones self with technical capability is only half the story, the other half being a team’s ability to effectively deal with soft issues and successfully engage with stakeholders. I hope you will learn from it and be able to put it to good use if you come across such a situation or are already in such a (tricky) situation.
A Story
Once upon a time, there were two internet companies that had recently introduced interaction design teams. Both of these companies managed to hire talented interaction designers (IxD). While they did hire some good IxDs, they were not following a User Centered Design (UCD) process.
Their process was basically as follows. The product team would come up with the information architecture (IA) of a new product and the interaction design team would come up with the user interface (UI) and iron out creases from the flow given to them at a low level (micro IA). Changes would be made to the product once it went live, based upon studying how it was performing through reports from the Management Information System (MIS) and web analytics.
Now this was not a very optimal method of doing things. It would often be the case that after going live, the IA and UI would be modified. This would have been perfectly acceptable except for the fact that these modifications were to be made on high level structures—both in IA and UI. This, of course, was not easy to do, since the entire web application or website rested on these high level structures. All of this cost the company dearly in terms of time and money, which was being spent on issues that were never anticipated.
At this time, none of the companies were conducting any form of user research or usability evaluations. The interaction design teams in both companies were aware of this and around the same time, both teams, frustrated with the state of affairs as they were, and for the good of their respective companies, decided to try and introduce UCD techniques into their organizations.
The interaction designers thought that conducting user research would help them provide product management with better inputs for developing a better IA validated by representative users. Not only that, it would also help them design a better UI by validating its ease of use throughout the Product Development Life Cycle (PDLC) through conducting usability evaluations. Both teams managed to grab opportunities for usability testing during development of new products around the same time.
After a year had gone by, one team had managed to set up a small unofficial but recognized user research group which their company was quite pleased with. Not only that, they had a pipeline of projects to keep themselves busy for the coming months. On the other hand, the second team was faring rather badly. Nobody wanted to let them conduct any usability tests. A new product was in the making and they did not get to conduct any user research for it either.
Their plan to introduce UCD techniques into the organization had pretty much failed and they were beginning to give up because of the lack of results they had seen. They were unimpressed by the response of the organization. Likewise the folks in their organization were unimpressed by the result of this group of interaction designers, who they thought would have saved time if they had simply stuck to what they were assigned to do in the first place.
Leave a Reply