The broad focus of agency life — moving from one business sector to another as you work on a multiple projects — can generate insights. Agency life is opportunistic. You work for whoever will hire you and you provide them with the best service to address their needs. A good agency is looking for the right opportunities, a chance to make an impact in people’s lives by doing what you can do well through projects that match the design team’s interests and skills to the client’s goals. But whether you get that dream project or not, as you shift your focus from one client to another you start to see things. You see things that your clients don’t see or care about. You see how a problem in one sector that clients believe to be special to their business alone is a lot like a problem in another sector. Sometimes you can apply those insights to see problems differently.
I see this as an information designer, one of my pseudo-professional titles. I look at problems through an information design lens, to borrow an Experience Design trope. I have an affinity to reducing problems to differences and patterns of use.
CRMS ARE LIKE EMRS
For example, I noticed a similarity between sales people and brokers working in financial services and physicians working in hospitals: they are both unhappy and frustrated with the systems they have to work with. I was interviewing a lot of internal sales people for a financial sector client. These people got their job done using many different software systems, but the main system they had to use was the CRM. Most companies of any size use CRM (customer relationship management) systems as a repository to collect information about their customers. The CRM is the system of record, the information authority that everyone has to contribute to and rely on. Nearly everybody disliked it. Nearly everybody who has to enter information into it wants to change it. Everyone who owns it or has to maintain it wants to leave it alone. Everybody entering information mitigates their frustration through work-arounds and short cuts, which often undermine the authority of the information they contribute, which leads to more frustration and more work-arounds, etc.
The Customer is the primary unit of information in the CRM. That Customer has attributes — names, addresses, phone numbers — that are essential for sales people. They contact or “touch” customers by grabbing an attribute — clicking on a phone number or an email address, or sending an order to a fulfillment house. Sales people and brokers love this part of the CRM because it’s fast. Touching a customer creates a customer relationship event, which needs to be recorded so the next sales person, broker or software process can see what happened. However, sales people, who spend their time talking to customers don’t especially like the recording part because it’s slow, awkward and redundant. They are forced to rethink what they are doing in terms the software requires. Report generators don’t talk to customers; they generate reports from the information sales people and brokers enter into the CRM. Sales managers don’t talk to customers either, but they do look at dashboards generated by CRMs that summarize reports and measure performance. Then they talk to their managers, who looks at dashboards that summarize reports and measure performance, etc.
So why do financial services companies adopt large monolithic CRM applications? They need to control customer relationships to sell more and better products, which is what CRMs promise to do. How does a system that people dislike accomplish this? By forcing everyone to gather every attribute and transaction with a customer into one system, CRMs make sales people and brokers interchangeable. Each person inside the company has access to the same record of the relationship. This can also benefit the customer — when giving people access to the best quality information about the customer is in the customer’s best interest. But it doesn’t benefit anyone if the person using the CRM can’t fit the recording process into his workflow or find what others recorded. Yet these systems are often justified because they create performance measurements on a wide variety of attributes tied to customer relationships.
This made me think about physicians working in hospitals. I made the connection while practicing my favorite experience design research technique, watching people do their job. While projects do give us the chance to observe healthcare professionals at work, I do most of my observation of healthcare professionals when I am the patient. I watch doctors and medical assistants balance their laptops on chairs, or walk over to the keyboard and screen on a stand, or carry their tablet into the room and fumble with the software they have to use to record whatever they’re doing. There are myriad reasons why every doctor in every hospital and medical practice has to use an EMR (electronic medical record) system. It is similar to a CRM, except that the Patient is the primary unit of information. That Patient has attributes — name, date of birth, addresses, phone numbers — that are essential for identifying and contacting her and connecting to her medical record: that list of every visit, lab test and prescription. Each time a doctor “touches” the Patient, a transaction needs to be added to the Patient’s medical record. When you ask doctors about this, they tell you about their frustrations. They’ll tell you that their EMR makes simple things complicated. It takes forever to click through all the screens and find all the boxes to check. As one of my colleagues recently wrote on his Facebook page “I need to stop telling doctors that I work in #UX. Appointments typically become EMR therapy sessions.”
I have seen that the more effort a doctor puts into structuring the record of her actions — coding, classifying, tagging, clicking, scrolling, paging — the more that recording process detracts from her primary job — focusing on her patients. As a result, everybody does the best they can and finds the work-around to make it bearable, at a cost to the completeness of the record. The three main sources of frustration are 1) having to re-formulate work to get it into the record — the difficulty of classifying things; 2) having to use a complex monolithic system to manage text and lists and tables and images when everybody knows how to manage them better in other software programs; 3) having to spend time putting stuff into a complex monolithic system and having a very hard time getting anything out of it.
I don’t have a simple strategy for transforming these negative feelings into productive euphoria, but seeing the unexpected connection between financial professionals working for investors and doctors working for patients can help us rethink the problem. There is a common thread in the jobs brokers and doctors are doing. They are both transacting with their customers — investors and patients. They both have to share information about those transactions in order to get paid for what they do. They both need to become interchangeable for the benefit of their employer — the financial service/health service — and their customer — the investor/patient. All of them would benefit from a user-centered redesign of their respective repositories, a redesign whose goal should be to adapt these systems to a broker/doctor’s struggle to get his job done. And that job is to help people lead healthy lives.
TRAVEL APPS AND MEDICAL BILLS
Today I excited to be working on an open challenge to redesign medical billing. How we are billed for medical expenses is different from other billing processes. It is based on the Triangle Trade fundamental to the US healthcare system: patients pay insurers who pay most of the costs charged by providers except for the part paid to the provider by the patient. Every transaction always involves three parties. That’s just the way it is. It involves many different sources, many different rules, many competing interests and no financial incentive among the players to share information.
I read an essay about Information and Mobility by my friend and former colleague in France, Giuseppe Attoma. What he said made me think that if CRMs are like EMRs, then multimodal travel is a lot like medical billing in the United States. I will translate and paraphrase the start of Giuseppe’s essay:
“In a journey, there is a point of origin and a destination, and between the two, something changes, the position of an individual in space and in time. This results in the trace of a path and an estimated time for the transition. The key information design issue in this case is the staging of these differences. The staging must make them understandable and actionable to the person making a travel decision in a given context.”
Our mobility — travel by car, train, plane — is supported by some common principles. This is why I can successfully drive a car in Europe and travel by train in China. My mobility depends on a set of common rules and basic forms of literacy. I can make decisions about the route I have to take. I know where I am allowed to turn. I know when to get off the train. When we design an information system in the travel sector, we are always striking a balance between personalization and generalization. To quote Attoma again:
“The issue for mobility information today oscillates between two requirements: Adapt information to each situation and each individual and produce uniform information that everybody can understand everywhere.”
In an instructive way, some aspects of mobility information in the US (and elsewhere) are a triumph of transparency. I can get reliable routing and travel time estimates from several mobile applications in real time, the result of aggregating data from numerous sources. I have access to a map of the territory AND I have a custom view of the territory that informs my travel decisions. In some urban areas this aggregating of data can provide equally reliable information about different modes of travel: walking, biking, trams, buses, subways.
Our daily transport system is made up of overlapping transportation modes. We walk, ride a bike, take a bus, take a subway, drive a car, take a plane, ride in a taxi. When I want to visit my family in Washington DC, I buy a plane ticket. There are software applications to help me do that. Many of them are great examples of user-centered design. They help me choose a flight at the best price, that leaves and arrives at the right time, and is operated by the airline I trust. Those applications demonstrate that it is possible to aggregate all the information about complex pricing models, schedules, and available tickets, at least for a single travel mode.
But neither my family nor I live at airports. I have to get from my home or my office to an airport and from the destination airport to my family’s home. Each stage of the journey requires choices: Order a taxi? Drive to the bus station, take the bus to the airport? Drive to the airport and park the car for several days? Stay overnight at a hotel that offers complimentary parking and an airport shuttle? What’s the plan and how much is it going to cost?
There are applications that will find me a ride and applications that tell me how many city bikes are available in my district, but nothing aggregates the time/cost/convenience trade-offs involved in multimodal transportation. As I go through these options in my head I realize this is where transparency ends and obfuscation begins. There might be a better option I have never tried (the water taxi?) or a promotional offer for a luxury service I never considered (call a limo service?). One of these options could hide a cost greater than the cost of the plane ticket. Getting to or from the airport could take longer than flight itself. Too many different sources. Too many different rules. No financial incentive among the players to share information. Too many competing interests.
A THOUGHT EXPERIMENT AND A DESIGN CHALLENGE
The confusion and obfuscation made me think of medical bills. I devised a thought experiment. Close your eyes and imagine you live in a country where you pay for travel insurance through your employer, a regular amount per month, with the expectation the insurer will pay for most of your travel costs when you need to travel.
You get a call from your brother; he needs your help; you have to visit him right away. You refer to the list of airlines and airports covered by your insurance. You call an airline on the list, an in-network airline. You tell the agent you need to fly from Boston to Washington as soon as possible and return in four days. The airline agent takes your travel insurance information and issues you a ticket on the next available flight. He charges you $50 for selling you the ticket, but he cannot tell you what the flight will cost you. That depends on your insurance, he tells you. You drive your car to the airport and park at the same lot you used the last time you went on a trip. You pay $130 for parking when you get back, and send the receipt with a reimbursement form to the travel insurance. The day after you return, you receive a bill for $46.98 for “flt inf” from a NE Meteorology Service. A week later you get a bill for $190.11 from Bilbo Jet Fuel with the explanation “89.676 g @ 2.12/g”. A month later you get a bill from the airline saying they charged $6,478.42 for the pilot and $4,232.56 for the copilot, an amount that was adjusted by your insurance company by -$10,642.34 and you owe them $68.64. Two days later you get a check for $2,698.21 from the company that manages the travel insurance for your employer with a note that says it is from your Travel Reimbursement Arrangement — you have no idea what this has to do with the cost of your trip to see your brother. Another month passes and you get a second bill for $3,190.43 for use of the plane from the same airline for the same flights. Another month passes and you get a letter from your travel insurance company saying it won’t reimburse the $130 for parking because they no longer have an agreement with that parking garage.
It has taken three months to discover that the trip to help your brother cost you $930.97. If the agent had told you this in the first place you might have thought it was fine or you might have called another airline, but now you’re surprised and you don’t know why you’re paying this amount. You don’t trust anyone. You never want to fly with that airline again, you don’t understand why you received four different bills for the same flight, and you are confused and frustrated about the benefits of your travel insurance.
The thought experiment is over. You can open your eyes. Aren’t you glad that’s not the way you’re treated by the travel industry? But that is the way patients are treated by the US healthcare industry.
We are all patients and we can all tell stories about how the current medical billing system generates confusion and ill will between our healthcare providers, our insurance companies and us. Increasingly providers and payers are also recognizing that the system undermines the very patient satisfaction they are trying to build. It is also the source of lost revenue. Patients, who are not told the cost of healthcare at the time of service, receive bills from multiple sources for the same episode of care, and those bills arrive long after the encounter with the doctor. A surprising cost is justified in incomprehensible language and code. Patients are unsure the bill is correct or complete. The results are anxiety and frustration, which frequently leads to inaction, non-payment, or incorrect payment of bills. It also leads to patient avoiding additional necessary treatment, which undermines their health, loses money for the provider and eventually means higher costs for the insurer.
This is bad Experience Design. It is bad for everybody’s health. Hopefully we can use our design challenge to find a path that leads from the current obfuscation to transparency and patient satisfaction.
Join us for “A Bill You Can Understand” Design and Innovation Challenge announced at Health Datapalooza on May 9 by reading the challenge description, reviewing the data and research created by the Mad*Pow team and pre-registering for the competition through the Design Challenge website: http://www.abillyoucanunderstand.com/. Final submissions are due on August 10, 2016.
