I would like to say that this well-worn approach is tried and true, but I can say only that it’s been tried and is not very true. In saying this, I’m not referring to typical implementation hiccups that occur during a project’s execution—things like delays in the timeline, sub-par user feedback, or changing requirements. We all know that following UX methods—with early UX involvement, iterative and participatory design, rapid prototyping, and close collaboration with developers—can make implementations a success. Rather, what I am referring to is the seemingly successful implementation that, upon following up a couple of years later, we come to find out that the company never adopted—for example, that SharePoint collaboration space that no one used; that SAP system that no one used, despite its automating what had been a manual process; that SiteCore CMS that no one used for updating content.
We’ve seen all of these things happen—whether to projects that we’ve worked on ourselves or to systems that our organizations rolled out. These IT designs seemed to have all the makings of a strong solution, but missed a critical and oft-forgotten element: the right purpose. The problem with that tried, but not-so-true interaction flow between a business, IT, and their external IT partners is how transactional it is.
Typically, no one digs deeper into the issues that the business originally identified to determine the root problem they really need to solve for people. But this is where experience designers can add tremendous value to IT projects, and it ultimately leads to IT’s earning a more strategic role within their organization. In the remainder of this column, I’ll share a few examples of how experience designers can help to elevate the discussion between IT and business, by helping IT to take on a more strategic role and delivering more long-term value to clients.
A Portal Would Solve Everything
One of the more common requests that IT gets from a business is the need to build a portal. One of our Engineering clients wanted to create a portal because employees in the group had their own sets of project-related documents on their individual computers and these conflicted with each other. A project manager might communicate with an external customer, giving them one date, while an engineer would give the same customer another date.
An IT client came to us and said, “We need a WordPress portal where we can display all of a project’s status information directly to our clients.” They had documented their high-level requirements and wanted to engage us for prototyping, design, and implementation. We asked them what research they had done, and they said they had spoken to their external customers about what they would want on the site. We explained that we typically do discovery research ourselves because asking customers what they want on a site isn’t usually the best approach to learning what we should recommend for a user experience. However, they felt comfortable with their insights, so we didn’t push them any further regarding our doing up-front research with their customers.
We did explain to them, however, that we needed to take a step back: For us to create a site that met their organization’s needs, we would need to get into their heads and understand more about their business, their employees, their customers, and their processes and ways of working. They agreed, and we conducted a day-long workshop with a few project stakeholders, discussing:
- customer and employee profiles
- their engineering process, including the types of communications that occurred and the tools and technologies that they used
- major touchpoints with external customers
- where they believed this new portal would be most beneficial to their process
The Need to Dig Deeper
Through this discussion, our team learned that the employees already had a boatload of portals, databases, and centralized spreadsheets at their disposal, which they were to use to manage and track project progress. We also discovered that meetings and communications happened very frequently among engineers and project managers and customers. We honestly did not understand why this new site might be necessary when they had so many existing tools and ways of communicating status. Why did they have so many problems with everyone in the group aligning on project status?
So I asked this loaded question: “You seem to have a lot of existing resources in place that should help to keep everyone on the same page. Why do you believe this new tool would be a success when these other tools already exist?” And the business responded, “Because this one will be visible to external customers, so it will have to provide the most accurate information.” I continued my questioning, “I guess I don't understand why you would even need this. What is really the root problem here? We don’t want to build something that people won’t use.” Their response: “Well, I guess one issue is that the project managers and engineers don’t trust each other.”
Aha! Now we were getting somewhere!
So I told them, “Well, I’m not sure a portal would create trust, but let’s see what we can do.” Working from this honest insight, we shifted the goal of our workshop to discussing candidly whether it really made sense to develop the portal and, if so, what would make it a success.
Everyone agreed that there were numerous, similar tools that already existed. But issues relating to a lack of trust and miscommunications were so entrenched within this group that they needed to use the creation of this new portal as a way to start addressing those problems. Because the portal would be visible to external customers, everyone had to align on dates and status. Therefore, one of the key criteria for the portal’s success was that it needed to be fully transparent in providing data, engendering trustworthiness for both external customers and employees. For example, if a project were delayed, the portal needed to show that. These goals became our anchor for the design. The team could constantly ask, “Does it feel like I can trust this information?” This was a critical area that we probed during validation testing with customers.
The other key criteria for success was that we needed to consider the portal within the greater context of the employee culture, acknowledging that there are deeper issues they needed to resolve. When doing validation research with employees, we asked not only about the portal’s ease of use, but also broader questions about employees’ ways of working, how the tool would work with their existing resources, and employees’ interactions with one another. When we provided our findings, we included a roadmap that showed how to begin addressing the other problem areas within the group.
The portal launched a year later, and feedback has been positive. The client acknowledged that this tool would not be a silver-bullet solution; and they started fixing the other issues that we had highlighted, relating to processes, group dynamics, and communications. More importantly, the business clients gained greater understanding of their people and operations—all from what was otherwise strictly an IT implementation project. The result of this was that they began thinking differently about internal IT support and external IT partners.