The CODEGIRL documentary is streaming free on YouTube through November 5, 2015.
I’ve been shipping software in various roles since I was an undergraduate student in 1997. I’ve done tech support, technical writing, software development, and user experience in the intervening years. I’ve shipped code in at least 8 languages, including Smalltalk and VAX assembler. I’ve contributed to and helped organize several tech conferences, ranging from programming languages to women in tech.
Although I had been a Mac user for some time, I officially became a part of the Mac developer community in 2005 when I joined Microsoft to work on Office:Mac. I was excited to join that team. Not only did I finally get to work on Mac applications (and with people who had been doing Apple development for 20+ years!), I was part of a vibrant community. I attended MWSF first as an engineer, and later as a speaker. I met many people who have long since crossed the line from fellow developer to friend.
I was a part of the community for the transition from PowerPC to Intel and the corresponding transition from CodeWarrior to Xcode. I was part of the community when the iPhone was announced. I was a part of the community when iOS really took off, and when being able to attend WWDC was not just a matter of getting employer approval but also the luck of a draw to get one of the relatively scant handful of available tickets.
When I started working on Office:Mac, I observed that there weren’t a lot of large Mac development shops outside of Apple. There was the Office:Mac team of ~250 at the time, and Adobe too, although I didn’t have a good estimate of how many Mac developers they had. Then there were smaller teams, like Quicken for Mac, VMware Fusion, and The OmniGroup. And then there were a lot of very small shops and single developers releasing great products. One of the challenges that the Office:Mac team had when I was there was the dearth of software engineers who had both Mac development experience and very large codebase development experience.
Both the platform and the development community have evolved, resulting in significant impacts to independent developers. As is obvious from the near-impossibility of getting WWDC tickets since it first sold out in 2008, the Apple developer community has seen an unprecedented influx. Companies large and small have added iOS developers. Independent developers have flocked to the platform.
A major point of change has been the App Store, first for iOS and then for Mac. The proliferation of apps has made app differentiation difficult for developers, whether they are a large company or an independent developer with a great idea. To attempt to gain users, not only has there been a proliferation of apps, but those apps are likely to be free.
Free apps are, of course, not free. Apps require developers, and developers have bills and a desire to keep paying those bills. For a large company, the cost of developing a free or inexpensive iOS app is often absorbed in the costs of developing other products that are well-funded and that the iOS application supports. The App Store has evolved other methods for developers to make a living, including advertisements and in-app purchases.
Which leads us to the state of the independent developer. It was possible to be an independent developer and make a decent living at it. Some developers, through a combination of skill and luck, found themselves doing more than just making a decent living. As the price tag of applications has trended towards zero, it’s been ever-harder for an independent developer to be only an independent developer. A good idea for an app, the skill to develop a great app, and a sprinkling of luck is no longer sufficient to make a decent living.
Independent developers often have to diversify their income. They might have to keep their day job and work on their app on evenings and weekends. They might have to become writers or podcasters to ensure that they have sufficient income. They might become developers in a corporate environment, taking advantage of all of the iOS developer opportunities that are available now.
I was overjoyed to see Samantha Bielefeld‘s take on the state of independent developers as she considered Marco Arment‘s move to make his iOS app Overcast available for free with an optional patronage model. Her point that he is able to try this as a result of his unique position in the community and his other income streams is one that resonated with me. If a well-known and well-regarded developer isn’t reaching an audience with a well-designed and inexpensive iOS app and thus chooses to make it free, what about everyone else?
It’s distressing to see a well-known independent developer seemingly throw in the towel on independent development. It’s doubly distressing when that independent developer doesn’t seem to understand that the model of patronage isn’t necessarily one that will work for independent developers at all, let alone ones who don’t have thousands of Twitter followers or close friendships with well-placed members of the tech press.
What is the state of our community? Are our options limited to either working for a big company or hoping that ad revenue continues to limp along? How do we have a vibrant community of world-class apps and developers creating those apps if our users have become conditioned to free apps?
These are important questions for us. Attacking Bielefeld for asking important questions is the wrong thing to do. For all of us, whether we’re in big companies or independent developers, we have to consider our place in the community and how we’re supporting both ourselves and the long-term success of the community. I’m hard-pressed to see how this constant drive to zero is going to ensure our long-term success. We must stop shying away from important and difficult questions, and we must stop attacking anyone who questions this status quo.
On the first day of MacIT, it’s traditional for the members of the advisory board to say what they’re looking forward to. Arek Dreyer went first, and he cited the hallway track as the thing that he’s most looking forward to. He’s right: even at a conference with the most amazing content, the hallway track is often one of the most useful tracks at a conference1. It’s a huge miss when conference organizers forget about the importance of the hallway track.
This afternoon, I got to be a part of the hallway track in action. I was talking to another member of the advisory board and one of the MacIT speakers. Someone came up to us, and asked what we knew about network security. She referenced a question that she had asked during the security talk this morning. None of us are network experts, nor are we security experts, but we’ve all picked up bits and pieces over the years. She explained her situation as we looked at her error logs.
We came up with a plan of attack, both short-term to address the issue that she found, and long-term to address the likely root cause of the problem. We talked about how to figure out what levers to pull within her organization to make it possible to do the long-term fixes. We shared our own war stories about our own experiences with issues and figuring out exactly what dance is needed to get something done. And we reassured her: yes, she really did have an issue, and yes, her issue is resolvable.
This is why I love the hallway track. None of us had the complete answer. Together, we were able to talk through her problem, brainstorm ideas for how to address it, and come up with what felt like the right way to address it in her environment with her team. We worked together, came up with some potential solutions, and identified more resources that she can use back home when she doesn’t conveniently run into people in the hallway. We all learned something in the process, and we helped out a member of our community.
That is the power of the hallway track.
- Now that I think about it, possibly most especially at a conference with the most amazing content. Great content creates another opportunity for great hallway conversations ↩
As I’ve been working at Genentech, one thing that has quickly become apparent to me is that healthcare is far more than the clinical experience. That clinical experience, between me and my doctor or maybe me and a x-ray tech or something like that, is only one of the pieces of healthcare. There are many aspects that are just as important as the clinical experience.
In “How hospitals hope to boost ratings on Yelp, HealthGrades, ZocDoc and Vitals”, the Washington Post says this:
When patients are asked to rate how doctor quality should be measured, clinical outcomes, such as getting cured of a disease, rarely come up, said Lisa Suennen, who advises health-care companies. Patients talk about whether a doctor or nurse was kind to them, or whether their experience was fast and convenient. It’s assumed that the doctor is going to treat their illness or condition.
The clinical experience is necessary, but not sufficient, to have a good healthcare experience. The user experience of healthcare includes the clinical experience, as well as the ease of getting an appointment, the wait time before your appointment, how test results and next steps are communicated with you, whether your doctor follows up with you.
Perhaps this is a reflection of Genentech and its treatments, but I wonder if the last sentence is actually true. Or maybe it’s true for lots of cases, and it stops being true when the diagnosis or treatment is difficult. As a patient, it can be hard to assess clinical outcomes. If I had a cold and now I don’t, how do I know if the clinical experience could have been better? If I have a chronic condition, how do I assess whether I could have gotten a better clinical experience? It’s easy to assess whether I feel like my doctor has listened to me, whether my doctor has treated me like a person and not a condition, whether my doctor is responsive to my concerns.
Healthcare is hard. We have to remember that the clinical aspect is only one part of what makes healthcare hard. We have to get the patient experience right.
In every role that I’ve had, I’ve had to remind myself and my team that we are not our users. When you’re a software engineer creating a software application, it’s very easy to see yourself as the user. It was true when I worked at IBM on databases, it was true when I worked at Microsoft on Office:Mac, and it was true when I worked at VMware on vSphere.
In each of those instances, while we as the application development team did use our applications in one way or another, we weren’t representative of our real users. We had more knowledge of how computers and software work in general. We had more knowledge of how our specific applications work, and many other related applications too. We were far more likely to use our software deeply. When I was at Microsoft, I learned that, as an organization, we sent and received significantly more email than other organizations of our size and general structure. This meant that I couldn’t project from my usage of Outlook to other users. I had more email, I had more folders, I had more events on my calendar, and I was far more likely to use deep features in that application.
I find myself having a similar conversation in healthcare user experience. We are very patient-focused. Being patient-focused is excellent. We have a lot of empathy, which is also excellent. In using the term “patient”, we can project ourselves into the situation — after all, we’ve all been patients at one time or another. My doctor refers to me as her patient, even when I’m just in for a checkup.
But I am not the patient here. When I project myself into the patient’s situation, it is easy to forget that I probably differ from the real patient. I am a reasonably healthy and well-educated 39-year-old married woman in Silicon Valley. Not only that, but I have also learned quite a lot about how healthcare works in the past few months. Most patients don’t have the benefit of the knowledge that I have acquired. And if I’m considering the user experience for the patient, they are probably not, or are no longer, a reasonably healthy person.
This point is very important. Someone who is reasonably healthy is better able to make well-informed decisions. We have a limited amount of cognitive resources available. There are only so many decisions that we can make in a day. That’s why habits are so powerful: a habit is (at least!) one fewer decision to make in a day. If you always have a latte and a banana on your train ride to work1, you don’t have to expend cognitive resources thinking about what to have for breakfast that day, and thus you have more cognitive resources to use later in the day. People who are in pain or who are stressed have fewer cognitive resources available to them than people who aren’t in pain or stressed.
In creating a healthcare user experience, I have to remember that our patients have probably had a life-altering diagnosis. They could have had a long and difficult journey to get to that diagnosis. They are probably tired, and in pain, and stressed. They are already dealing with a difficult situation. We have to create a healthcare user experience that doesn’t have an undue cost of cognitive resources at a time when the patient has few, if any, to spare.
- Yes, I have just described my morning commute. ↩
I’ve worked for software companies for my professional life. Coming to work in healthcare has been eye-opening for me.
The user experience is … well, let’s be generous. Let’s call it “challenging”. And it’s challenging for, as far as I can tell, everyone involved.
It’s challenging for the patients themselves. Getting care is no simple matter. There are decisions to be made, providers to find, waiting lists lurking. There are healthcare and wellness apps which promise to help the patient in some way.
It’s challenging for healthcare providers. We’ve seen an explosion in everything related to healthcare. There is an ever-increasing amount of data. Some of it is specific to a single visit with a patient, such as the results from blood work or an MRI. All of this data, not to mention whatever notes are jotted down or diagnoses given or prescriptions filled, are aggregated into a patient’s healthcare record. Any given patient likely has multiple of these health records, even if you only consider that a patient probably has a different health record with their primary care physician than they do with their dentist. Keeping up with all of this data is difficult and time-consuming.
And that’s just the medical side of it. We haven’t touched the administrative side of matters, which involves the patients, family members or other caregivers, the patient’s insurance company 1, administrators and office staff at the healthcare provider, and so much more.
All of this adds up to a bad user experience. Some of the bad user experience is just annoying. But, since we’re talking about healthcare, a bad user experience has risks far beyond annoyance. A patient could choose to delay treatment because navigating the system just to get an appointment is too difficult and time-consuming. A clinician could miss an important detail in the patient’s health record and prescribe the wrong treatment. A data-entry clerk in the doctor’s office could make a typo that results in the patient’s insurance company rejecting the claim.
I’m sure you can imagine that I read “Why Health Care Tech Is Still So Bad” with much interest, and I agree with almost every word of it. The only point that I disagree with is that it’s not enough for physicians to be unable to live without a given technology. There are many technologies that physicians today can’t live without. Whatever technology is part of getting the user experience of healthcare right has to make the whole process better for everyone, not just the physician. If my doctor thinks the technology that gives her my health record is something that she can’t live without, that is almost useless to me if she refers me to another doctor who can’t access that health record.
There are too many moving parts in the system, too many stakeholders. It’s not sufficient to get it right for just one of them. We’ll probably get there in a piecemeal fashion, improving experiences for different sets of stakeholders at different points. We can’t stop because we’ve gotten it right for the physician. The user experience of healthcare goes far beyond the physician.
- I’m being lazy here, there’s also public payers like Medicare or the Veterans’ Administration. ↩
I often get asked about the difference between my previous employers, all software companies, and my current employer, a biotechnology company. There are so very many differences. One that I feel every day is the knowledge that Genentech has very sensitive data. As a result, we have strict corporate policies that cover a wide range of areas like physical devices and data retention. I even have a separate corporate cell phone now.
It’s easy to see why we have such policies. Consider this article from the Washington post about healthcare hacks. It points out that some of the data loss has been from a stolen laptop or inappropriate disposal of paper records. I thought I used to be nervous about losing my corporate laptop; the stakes are a lot higher now. I was already the type who rarely printed anything out, and put anything that I did print straight into the confidential shredding bins once I was done with it.
I’m now even more careful with my devices and data. I print less than I ever did. I don’t even have a filing cabinet, which forces me to ensure that anything I do print is handled appropriately immediately. My awareness of security, both physical and data, is so much higher now. I’m also thinking more about the user experience of security and what we can do to engender better security practices.
In coming to Genentech and applying my user experience skills here, one of my first realizations was that a patient’s journey doesn’t begin with diagnosis, and it doesn’t end with the completion of treatment. It begins with the early symptoms that the person might not even recognize immediately. Getting to a diagnosis is not the start of the journey; instead, it’s one of the milestones. For some patients, especially for many of the treatments that Genentech makes, their journey is a lifelong one. For others, it ends not when treatment is completed, but when they have recovered and completed everything associated with their diagnosis and treatment.
We published an article called “Beyond the diagnosis” which explores a lot of these ideas. I’m very happy to see others here who are thinking about the whole experience of being a patient. This passage certainly resonates with a lot of the work that I have been doing in the past few months:
Sometimes the cause of a health problem is clear. Other times, it takes years to pinpoint what’s happening in a patient’s body. The uncertainty associated with noticing early symptoms but not understanding their causes can be as debilitating as a disease itself.
This article is a great way to think about what it means to be a patient, and what we in healthcare can do to improve the experience and the outcome for the patient.
A couple of weeks ago, I had the opportunity to attend an event hosted by the US Digital Service. I got a last-minute invitation to attend, I didn’t have any plans, I didn’t really know what the US Digital Service is but I rarely get email with the seal of the White House on it, so I figured I might as well attend. It was so very much worth my time. I learned that USDS are my people, which is something that I’ve been kind of lacking at Genentech.
My new role is pretty awesome. I work on Genentech Access Solutions, which is a program where we help patients get access to the medicines that they need. At first gloss, this doesn’t necessarily sound like it’s a good fit for someone with a UX background. It’s actually a perfect fit. We’ve got people who understand how to deliver great services to patients and their healthcare providers. We’ve got people who understand how to run such services internally. We’ve got an IT team to deliver the software that’s necessary for patients, their healthcare providers, and our internal team. What they don’t have is an understanding of the overall user experience for each of the different types of people who use our system and services.
On the other hand, I don’t exactly fit in with my direct team, who are all very focused on business and operations. I don’t exactly fit in with the IT team either, who are very focused on delivering a solution to my team. I’m the one who’s tasked with understanding the experience of everyone who comes in contact with our system and services, and ensuring that we’re delivering the right user experience for each of those groups. Patients have different needs than healthcare providers, and both have different needs to our various internal users.
From a UX perspective, this all makes perfect sense. As a UX professional, it’s my job to understand not just what people do (or don’t do) with our software and services, but the context in which they do it. I have to understand what they’re really trying to accomplish, and what else they’re using to accomplish it, what works and what doesn’t about their current method, and design a solution that meets their needs.
I’ve spent my time so far getting up-to-speed on Genentech and Access Solutions: what we do, how we do it, who interacts with us. I’ve spent some time in the offices of healthcare providers, talking to everyone from doctors to nurses to office managers to front office staff to billing managers. I’ve learned so much in the past few months. It’s been amazing. And I’ve shared what I’ve learnt with my team, to help them see our services through the lens of UX, and to consider ways we can better meet the needs of our patients.
I get to use my UX skills in a way that we often don’t get to. It’s been fun, it’s been eye-opening, and I have high hopes for the future. But I also don’t have a built-in UX community that I can turn to.
And then I got to meet the US Digital Service team and hear about projects that they’ve worked on, and suddenly I realized that I’d found my people. They understood the challenges of doing UX in an organization that hasn’t exactly considered UX before. They understood the challenges of doing UX in an organization that has deep ties to processes and technology that are often considered outdated elsewhere. They understood the challenges of communicating about UX in an organization that knows they’re missing something but isn’t quite sure what it is. And they understood how deeply satisfying it is to improve the UX of something that is used by people not because they want to, but because they have a very different driver behind their usage.
There are other UX people out there who are trying to do the same thing that I’m doing. It was a great feeling. I’ve already had coffee with a couple of people that I met that night, and it was so exciting to have found my community again. Thank you, US Digital Service. You’re doing awesome work. I can’t wait to share with you the results of what I’ve been doing.
“The Discrimination Double Standard” by Liz Gannes:
In Silicon Valley, fighting homophobia is an easy issue. Instant alliances can pop up — as long as the villain is outside of ourselves. But when it comes to the harder topics here at home, and it turns out the enemy is us? That’s a problem that all these genius techies can’t seem to grok quite as easily.