Personas and user scenarios play a big role in Design for Business Value. When we first introduce the methodology, one common question we hear is, “My project doesn’t have any users, so will this still work for us?”
We were puzzled as to what type of project won’t have some impact on users, so we dug a little deeper. Typically, the project in question might be to deploy a platform or internal service, a system upgrade, or maybe some networking infrastructure. And the question we always ask in return is, “If you were to cancel this project today, is it true that nobody would care?” Most often, the answer is no.
Our operating hypothesis is that there is no business value without enhancing or preserving someone’s experience, and so far, this has held true for several years. If the purpose of a project is to shorten cycle time, deepen customer engagement, loyalty or advocacy, reduce process defects or some other business measure, then somewhere along the way, someone’s experience is probably improving. In other cases, the purpose of a project may revolve around mitigating risk, improving service reliability, increasing automation or improving corporate or regulatory compliance. For these projects, the team is trying to preserve a positive experience in the face of increasing demand or complexity of some sort.
Getting super clear about whose experience is at stake and what the hallmarks of a great experience for that person are sets the stage for great design, better project leadership and more effective decisions. For example, an integration project with SAP could support a more agile organization by lowering information latency for new hires. It’s possible that the Benefits Office or HR Recruiter would be in the best position to tell us when those business goals have been reached. Establishing clear measures of their experience, such as satisfaction, confidence, cycle time for key activities or data defect rates help keep the team focused on the important outcomes.
It turns out that when people say that their project won’t have any impact on users, what they really mean is that some other team who depends on their project will be responsible for making an impact. In these situations, the fact that business success depends on multiple, interdependent projects is even more reason to identify the key users and scenarios that will serve as a litmus test for the success of your project. They create a common, intuitive purpose for everyone involved and everyone to easily judge the success of the project.
Can you apply user design principles to projects that don’t have any users? Probably not, but then what’s the point of doing the project? In most cases, however, the assumption underlying the question turns out to be false. The better question is, “Which user experiences can we use to judge the success of our project?” If the answer really is, “none,” then it might be time to consider cancelling the project.