Learning Launch

Challenge: A short while ago, as the principle UX consultant in an organization, I was asked to lead a “tiger team” to  revamp the CRM system for a large Telco Service Provider. From the business perspective, some of the key issues were  obvious: Many unintegrated applications (23 to be exact), steep learning curve, many unresolved customer calls, too  many call transfers and a high average handling time for common tasks. However, it soon became clear from initial SUS  scores and ad-hoc interviews that users were frustrated with the system. It was unnecessarily complicated and did not  approximate the mental model of actual users in the real world.

Accordingly, we kicked of the project with discovery and fact-finding – What is… We received from the client,  operational statistics for a two-month period, previous UX studies, screen shots and user guides of the existing system,  system architecture, business processes, business requirements and the data model. Together with our due diligence,  we visited 5 client call centers where we observed users going about their tasks in passive observation or “side-by- sides”. We interviewed 8 different users and toured the call centers. The challenge was to present a solution for 3 agent  types where the delta between the existing system and our projected solution would be compelling

Selection: Once the gathered information was elicited and processed, we brainstormed our findings with a diverse  audience from the client’s business, IT and our team. This was necessary to identify actionable insight, prioritize  elements of our solution, but most significantly, to guide us to the next step of the improvement process: what are our  key assumptions/hypothesis and how will we validate these assumptions? We chose the Launch Process tool to test the  validity of our prioritized key assumptions. More specifically, we established measurable UX goals to validate, including:  a) for all frequent tasks, it must be possible to navigate from anywhere in the system to anywhere else in the system  with no more than two user actions b) All actions must be in context and What You See Is What You Need – no more and  no less c) First call resolution + call deflection will increase by 30% and average handling time per frequent task will  decrease by 30% d) User satisfaction (SUS) will increase from 56% to 85%

Application: The test we designed to validate our key assumptions (in the form of goals) was based on a mock-up of the  12 most frequent flows and scheduled a “walk through” to a large audience of diverse stakeholders in a collaborative  brainstorm/design review. We began by stating our assumptions behind our proposed (baseline) solution that needed to  be confirmed or disconfirmed – for example, for every user step, we asked, “Can this be further simplified”, “What is  wrong with the existing way of doing things” “Is there a better way of accomplishing this task”, “What are the  dependencies and constraints” “What is the learning curve for this task”.

Insight: Shortly following the testing of my hypothesis/assumptions, I became aware that I may be getting caught up in  “experimenter’s bias” (similar to confirmation bias, but in the reverse: to design a test that will confirm the  assumptions). To optimize an existing system in terms of system integration, task completion rate and task time is not  that difficult, but from a user’s perspective, that was not their focal pain point. It turns out that the cause behind so  much of users’ frustration was that “they were leading the system instead of the system leading them”. Indeed, the  most focal heuristic as far as users were concerned was “Can the system do more to alleviate the cognitive load on the  user”. As a result, we fleshed out all frequent tasks (per persona) to explore inferences where the system can do more  on behalf of users and lead users to make the correct choices in context. This had an impact not only on the UI and  interaction design, but on system integration, automation, navigation, etc.

Approach: While this project that continued for 18 months and involved over 300 people was wildly successful (savings  of >$250M in the first year after rollout and increase of user satisfaction from SUS 56% to SUS 90%), there were lessons  to be learned. My major learned lesson was to have brainstormed a lot more with the client at the discovery phase  (What Is) that would have better informed the assumptions that I tested – for example, “in the context of constraints,  the system will lead users to make the correct choices in context and perform anything and everything that users cannot  perform themselves”

