For the last several months I have convinced myself more and more completely that service system development should follow the example of software system development, and formally assign a trio of roles responsible for the desirability, feasibility and viability of what is being developed.
In software system development, the product trio is:
- The UX designer is responsible for desirability, that is, everything concerning user adoption of what is being developed. If we build it, will people adopt it?
- The software engineer is responsible for feasibility, that is, ensuring that whatever is being proposed is developed within given constraints. Given what we have to work with, can we build it?
- The product manager is responsible for viability, that is, for ensuring that the system once built and adopted by users will help the organization flourish. If we build it within constraints, and people adopt it, will it serve the organization’s strategic goals?
Of course, teams are collaborative, so they must, in IDEO’s parlance, be T-shaped. Each team member must have a general understanding of design, engineering and business sufficient to support effective collaboration. But each brings a depth of understanding in their specialty and their domain of responsibility.
Given that service systems are at least as complex as software systems – plus additional layers of organizational and logistical complication – it seems self-evident that assigning responsibility for ensuring the desirability, feasibility and viability of a service to one role guarantees that something, and likely much more than something, will be lost.
Asking one designer to specialize in and bear responsibility for all three shows a failure to appreciate either the complexity of services or of human limits. A service designer who attempted it would have to work 120 hour weeks to juggle all three of these responsibilities, or 80 hours to juggle just two of the three. And ask any designer which of the three always gets dropped first.
In service system development the service trio should be:
- The service designer is responsible for desirability, that is, everything concerning service actor participation in the service being developed. If we activate this service, will all service actors willingly participate in ways that support it?
- The service system engineer is responsible for feasibility, that is, ensuring that the service is operationalized within given constraints. Given the organization and its conditions enabling and constraining it, can we activate, maintain and evolve it?
- The service system manager is responsible for viability, that is, for ensuring that the service once activated by participation of service actors will help the organization that delivers this service flourish. If we activate it within constraints, and service actors participate as intended, will it serve the organization’s strategy?
Until we stop reducing the vast and complex domain of service system development to “service design,” the field will remain stuck in the age of the webmaster. Remember that guy? The webmaster was the guy in headquarters’ basement who figured out what an organization’s presence should be on the Information Superhighway, and then sort of hacked it all together. He was an overworked jack of all trades and master of none, especially not the design part.
Today what we call “service designer” really should be called “servicemaster” in honor of our pre-UX jack-of-all-trades predecessor.
The big hurdle, of course, is that the closest thing we have to each of these defined roles is still the overstretched, overburdened service designer. It is hard to staff roles with no existing practitioners, but my hope is that defining these disciplines might inspire enterprising, restless operations folks, process or industrial engineering types, CX professionals, or random multitalented domain-blenders to come along and fill these brand new, unclaimed shoes.
Dang. This is funny. I might post this on LinkedIn, under the disclaimer that this is my own opinion and not the opinion of my employer.
