It starts innocently enough. A design mock is seen, a new feature requested out of context (under the premises of improving the user experience), and life moves on.
It’s a good call when viewed from an isolated, strictly UX design perspective. For example, surfacing a support channel sooner rather than later in the flow. Making support available is always better, right? A side effect, however, is it now opens support channels up to significant volume that we simply aren’t prepared to accommodate; not with headcount, budget, or even an intake process, as this new feature is unsupported internally. As a result, support responses are now slower on average for everyone, and the final experience is degraded.
One product design decision made out of context affects five additional teams down the line.
Service design now, instead of focusing on building the cohesive system, must force the system to adapt within constraints as elegantly as possible. At the cost of upfront user experience, the backend user experience must go through a series of changes to match the expected benefit this feature was supposed to bring — otherwise, the feature would’ve made the experience worse because it wasn’t viewed from an overarching perspective.
At larger companies, service design is brought in to streamline and improve existing processes for both front end and back end alike- user and employee, UI and all the programatic systems it relies on. At smaller companies and startups, service design seems to focus more on being the aggregator of change, weaving webs furiously in an attempt to keep — or at least not degrade — the intended functionality new systems are created to improve. This detracts from the original purpose and is not only not sustainable, but can lead to broken experiences and ‘design debt’.
As a service designer for Support @ Lyft, I work closely with all facets of all teams. Day to day, we build support processes within engineering limitations, or max out engineering limits to support the processes themselves. Our specific team, as an extension of the Voice of Customer (VOC) organization, builds the path(s) riders and drivers pass through to speak to a human, and the best paths lead to a happy end — what we refer to lovingly as “True resolution”. In a non-ideal scenario, someone may reach a “reluctant resolution”, where satisficing occurs due to inability to have there issue solved in full. Worse yet, no solution is acceptable, and the scenario shouldn’t have happened in the first place.
Using data, user research, and a highly iterative cycle with a superb product partner team, we’re able to continuously work to understand exactly what the root cause of a support issue is and help eliminate (or at least alleviate) it.
True resolution can take many shapes, from a help center article to a phone call with a support associate. With well over a million rides a day and growing, we’ll need to continue to find ways to help provide excellent support — sometimes before you know you need it.