January 6, 2017 by SDesign
Improving your product’s UX via HCD (human-centered design) is not rocket science. Unfortunately, it is not utterly simple either. Whether your first step is to hire an agency or to onboard a new employee with a UX skill-set, making that first crucial step in isolation is insufficient. Creating a better user experience for your product is not a matter of inserting a process or person at a single point in time: rather, it’s about a change to the whole product lifecycle itself. (For a light introduction to the HCD process, please check out my videos on this topic).
To see this clearly, let’s investigate how adding a UX role, internal or external, affects other common roles in an existing product delivery team. The most obvious effect is that previous to this new, exogenous UX injection, some person or group was responsible for the user interface. What is the likely response of that entrenched group to hearing that they no longer own the competency of design? I can tell you from experience that it is not positive. Tearing away responsibility from a set of trusted resources is always painful, even with high-level executive buy-in. It requires active change management activities and considerable diplomatic aplomb. (See my article on this topic in UXPA’s magazine.)
Let’s turn to some of the changes that specific roles can expect.
In some UX-immature environments, Engineers are the ones that are literally responsible for the interface design. These interfaces tend to take on qualities that resemble the underlying logic of the implementation: the internal logic of the code is a reflection of how the engineers think. An external UI that represents the logic of its internal workings is usually much easier to code. The net result of adding a UX competency is that engineers are likely to feel disempowered by no longer owning the user interface; as well they are likely to resent that the new UX resource(s) is making recommendations that are much harder to implement. The engineering team might make objections based both on their material disagreement with the design direction, and on the fact that the new direction will be more complicated code-wise to realize and maintain. In my experience, these two types of objections actually become totally entangled with each other and become difficult to separate. (That is, for any given objection, does the engineer feel that the design is not good, or that the design is harder to code?)
Quality Assurance engineers are likely to find themselves needing to test to new types of documents and at a level of detail that that they are not comfortable with. The HCD process creates any number of artifacts that did not exist previously, whether they be UX specifications, style guides, usability results, or prototypes at various levels of granularity. Previous to these documents, the QA team probably had considerable leniency when it came to determining whether a particular action was considered a bug. Now many of these decisions will be up to the UX role, and in many cases specified somewhere for the QA team to test against. Furthermore, the UX designers will demand consistent, pixel-perfect renderings across multiple browsers or devices, driving both the engineers and testers crazy. Often the tester will not have any natural predisposition towards pixel-level testing and will either be resentful about it or lousy at it, or both. Numerous times have I seen the HCD process fail at QA.
The Product Manager is another person who is likely to feel that his or her authority has been curtailed. For businesses with a strong product management culture, the product manager is responsible for creating all use cases and defining all functional requirements. Sometimes, instead of the engineers, they are even the ones that created the UI-level designs. But when you introduce the HCD process, suddenly the UX team is working on central questions like “What problem is this feature trying to solve” and “Who is the user for this use case?” The product manager will question where their authority ends and UX’s ends; and indeed, this is a thorny question even for mature organizations with well-defined roles and responsibly. As with Engineering and QA, we see the twin dilemma of disempowerment and role ambiguity.
A list of affected roles would be incomplete without mentioning Sales and Marketers. By now we can take the template that we have established and simply apply it to these roles. In companies that have Sales-driven roadmaps, UX is likely to start questioning the viability of features on the roadmap and the validity of any proposed UI that a customer may request. Similarly for companies with strong Marketing organizations, the UX group will fundamentally question use case and business requirements, leading to escalating tensions and role ambiguity. These are all problems that can be solved with the requisite diligence and determination. But the key here is that any new UX discipline will have overlap with existing organizational functions, leading to conflict and role ambiguity that will take time and effort to smooth out. Adding HCD to the product lifecycle changes how the organization operates at a fundamental level.
We’ve looked at some specific job titles, and we’ve seen how the HCD affects how those roles work in significant ways. But what about the bigger picture? How does it affect the product delivery process as a whole? Unfortunately, it typically makes the process longer. Adding rigorous requirements collection and a dedicated design phase adds time. The code that the engineers develop will probably be more complicated, be buggier, and take longer to write. If a project using solid HCD process takes longer and uses extra resources (in the form of new UX specialists), then it follows that it will also cost more.
Now, I am not arguing that good HCD process should not be practiced; I believe precisely the opposite. But I am saying that business stakeholders should not be deluded into thinking the overall process will become cheaper. Overall of course the product will be superior — hopefully, far superior — and doing it right the first time is better than doing it over. But the point is business stakeholders have to understand that there is a price to getting a better product under the grinding pressure of quicker time-to-market and lower operational costs. If senior stakeholders are not on board with that reality, the HCD process will probably fail.
Coming back to my original thesis, then, I reiterate that improving the UX of a product requires substantive change to the organization: it changes how people go about their work, and it requires that senior management understand that time horizons and budget will, on balance, increase.
These are fairly uncomfortable truths for us in the UX industry. But only by reckoning with them head-on can a business succeed in transforming its vision to become User-centered. I formed Strathearn Design to help businesses make that reckoning.