Designing the Conversation: Gaining Access to Impacted People

Bujuanes Livermore at UXDX APAC. Video: https://youtu.be/zUk5b3Duj_0

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Why access to impacted people is still hard

[00:00:00] Thank you, everyone, for your patience. Thanks so much for joining this particular talk, and thank you also to UXDX for including this topic in this chapter of the UXDX conference. The fact that we are talking about designing the conversation and gaining access to impacted people is really a moment for us to pause and reflect on why it is that, after more than 20 years of digital really beginning to permeate our lives, we are still hungry to understand what other people's approaches and strategies are to ensure that those whose lives we are going to impact are part of the design and research process, from concept idea through to product release and everything in between.

[00:00:42] My name is Bujuanes Livermore, and I work with Microsoft. I'm not sure if there's something in the fact that Microsoft and Zoom were doing something behind our backs, and vdot [?] being able to access Zoom for a period of time, but we've got that sorted. I lead a team of designers and researchers in the space of human and AI experiences, and we work directly with customers on their data and AI ambitions. My team is comprised of talented designers and design researchers, and there'll be a little bit of that flavor through some of the perspectives that I share with you today.

[00:01:20] In the spirit of context setting, I'll just start with a few definitions and share some perspective on the world that we find ourselves in. Firstly, what do we mean by impacted people? I much prefer to use the language of people over users. For me, users is very reductionary and very transactionary. Just to illustrate that point a little further, a very different mental image would be conjured up if I were to say that a person was a user of a hospital bed, as opposed to a person being in critical condition requiring care in an intensive care unit. One very much engenders compassion and the other doesn't, and for that reason it's our responsibility at every stage of a process to ensure that we're really humanizing the people whose lives we are going to interfere with.

[00:02:13] Believe it or not, although we work for a technology company, we don't believe that technology is at the center of everything that we do. In fact, people are at the center of everything we do, and technology is just one aspect of their lived experience. Yet we must recognize that the power of technology is such that it can influence, both positively and negatively, someone's context: their environment, their experience, their social influences, their cultural influences. Again, it's very much our responsibility as design researchers to ensure we're modeling and understanding what kind of impact is going to be had on a person once the solutions or experiences are released to them.

[00:02:55] Further, when we talk about impacted people, it's very easy to identify those who are directly impacted. But technology has now permeated so many parts of our lives that there are many people who are consequently impacted. Sometimes people wouldn't even realize that they're being impacted at all. That's yet another level of responsibility that I believe my team has: to ensure that those people who are either directly or indirectly impacted are brought into the conversation and are a part of our design and research process.

[00:03:28] With that definition in place, I'll also go to the way in which we view those who work on digital projects in terms of structuring and work allocation. If we think of organizations out there, there are one of two ways that organizations can conduct work on their digital endeavors: either they allocate the work to in-house teams, or they bring in vendors, service providers, partners, whatever the language is that you're familiar with. It's in this particular area that we sit, and it's in this particular area that I see a lot of gaps and a lot of obstruction, really, when it comes to gaining access to people who are going to be impacted by the work that we do.

[00:04:19] It's not as though this is an industry that we can be frivolous in, or an industry that we can sniff at. In fact, Gartner's estimations suggest that the industry will be valued at 4.5 trillion by the end of 2022. Given an industry that has that kind of price tag, one might think that there would be more scrutiny, more checks and balances, across how those who are going to be affected by the output of that industry have been incorporated into the design and research process. Yet that particular number is comprised of spend on hardware, spend on software, spend on IT services, spend on general cloud consulting services. The receipts really are missing for how much, even in terms of percentages, has been apportioned to ensuring that people are part of the process.

[00:05:14] So we're left to question, at different points in time: why is it hard, and exactly who is making it hard, in this kind of setup, in this kind of environment, to access people who will be impacted by technology, by our digital solutions? In asking that question, we can't help but reflect on where we have come from. It's not as though we have been devoid of gargantuan efforts by a number of cohorts globally who have attempted to ensure that human rights take precedence over technology liberties.

[00:05:48] For example, we had WCAG, the Web Content Accessibility Guidelines, appear in the mid-1990s. They went on to become an ISO standard, and it was a remarkable moment to ensure that people could access content available digitally. In fact, the ability to access content digitally is considered a human right. We saw the emergence of digital service standards created at country levels, and those standards are a really good example of what it takes to not just define a standard, but to also back it up with criteria that will be assessed to ensure that the standard is upheld. There's so much for us to learn from countries that have done that well and who are on their journey of doing that today.

[00:06:34] We have seen data privacy laws, felt most acutely through GDPR, and in this very emergent space that we're in right now, we see the drafting of particular AI laws and guidelines. While all of those frameworks target different things, they all have one common thread, and that is that they have sought to ensure human rights are maintained over technology liberties. And yet, despite all of this, it is still difficult to gain access to impacted people.

Is there anything wrong with a technocentric approach?

[00:07:13] Like any good researcher, or simply anyone with a curious mind, we would do well to question whether there is actually anything wrong with what I would refer to as a technocentric or an algorithmic approach. These headlines are indicative of many headlines that I could have sourced across a number of industries, and I'm going to pose the question to you. Do you think that there's anything wrong with the fact that racial bias has been detected in an algorithm used to manage the health of populations? Do you find issue with the fact that job advertisements shown to men are more prestigious than job advertisements being fed to women? And do you think that there's anything problematic with something as novel as a chatbot spurting incredibly sensitive rhetoric to a group of people who have been through some critical life experiences throughout history?

[00:08:19] I'm sure that we share the same answer to those questions. But what typically happens when these headlines hit is that a company will either can the project, or suddenly they identify the need to have multiple disciplines come to the table and rethink version 2, or iteration 2, of that project. Like you, I would much prefer to be in a situation where I'm not responding to crisis, but instead am at the table up front, ensuring that we're planning the right approach from the beginning.

[00:08:55] That leads us to this point, to discuss some of the strategies that have helped us along the way to change the conversation. Those strategies for us really come down to the things that we have identified are in our control, and there are three things: the standards that we accept, the assumptions that we make, and the motivations that we design. The standards that we accept have been aided by artificial intelligence, believe it or not, and this is really a principle-level discussion. The assumptions we make are things that we can make explicit through very simple processes instituted at the beginning of projects. And the motivations that we design are arguably about persuasive design. While that has been associated with addictive behaviors, in this instance we're looking to put some of those techniques to good use.

The standards that we accept

[00:09:46] Let's get stuck into all three. Firstly, the standards that we accept. If your organization already has standards in place, fantastic, and if you were lucky enough to be part of the conversation, then you will know that standards have two parts. They're derived from principles, and these become the foundations for our actions. And they're aimed at achieving objectives, which are a demonstration of principles. They become the compass. They help us ensure that we are pitching our efforts in the right direction. Yet standards remain academic unless they are lit up by particular actions.

[00:10:28] At Microsoft we have six AI principles, and those principles include fairness, inclusivity, reliability and safety, transparency, privacy and security, and accountability. In order to identify how we can do the work that we need to do and uphold these principles on a project-by-project basis, we need to go through the process ourselves of identifying the objective that we can push by holding up a principle, and the activities, all the enablers, that help us maintain accountability.

[00:11:07] I'll just go through a little bit of that to see how one of these principles turns up. I've chosen the principle of inclusivity, and we bring that to life by seeing our role in the organization as helping with two objectives. One: inclusivity enables us to include impacted people in the process. Two is around soliciting diverse representation. Again, that's slightly academic unless we then support it with particular enablers or activities.

[00:11:40] For us, it is enacted through the creation of a research plan, a living research plan that updates itself and changes as we learn more about a space; the assignment of a research sponsor for the organization that we are collaborating with; once that sponsor has been assigned, working with them, and typically a wider group of people, to co-identify impacted people; and, through identifying those who are impacted, undertaking generative and evaluative research and design, and doing all of that in service of gathering the insights that feed into design decisions.

[00:12:23] The experience that we have had to date, and we are still very much on this journey, is that this helps us light up the ability to be better at clearly communicating our terms of engagement early on with a customer that we're about to go into a tango with. It helps us provide consistent, value-added messaging around our expectations. It helps us to have a very integrated project approach amongst disciplines, not just an engagement with a mono discipline. And we are in the process at the moment, in the same way that I mentioned has been achieved by the digital service standards, of not just having those standards supported by actions, but having them actually be accessible.

[00:13:09] Now, hopefully the standards that you have as an individual have some alignment to the standards that you have for the organization that you're working for, and if not, you may be experiencing some existential crisis on the horizon. I hope that doesn't happen to you.

The assumptions that we make

[00:13:27] Secondly, the assumptions that we make. We're going to go now from principles down to process level. Before I do that, I just want to pause for a moment and have you think about a time that something was incorrectly assumed about you. How did it feel? I often find myself in those moments where I need to interact with a service organization around customer service, and I need to provide my details, and perhaps sometimes also my partner's details. When I say the word partner, I'm often met with the reply, "Okay, let's get your husband's details." I didn't say anything about a husband. While it might have been something that I could overlook on one occasion, having 10-plus years of that happening over and over again leaves a very sour taste in my mouth about the organization I'm working with. It shows their lack of understanding about the diversity of the world that we live in.

[00:14:29] So while assumptions might not feel good for you when people make them about you, I'd say that they're also not a good idea to have on a project. Through this process of making assumptions very, very explicit, so many other good activities result. I mentioned that my team works across human and AI experiences, and in that world we could generally cluster five different aspects to which assumptions relate. Like all technology projects, we can look at who is immediately impacted and who is consequently or secondarily impacted. We can look at the data: assumptions about the data that's being used. We also have an interest in understanding what assumptions have been made around the model that's to be created. And the area that I find is often missed is assumptions around the systems being impacted. This is more of a socio-technical conversation.

[00:15:32] Now I'll present to you a bit of a fictitious scenario, just to put into effect how some assumptions might result from learning about a customer who is potentially in the health and life sciences industry. The scenario that they're interested in lighting up is improving cancer detection rates, detecting cancer earlier than it's being detected at the moment. They're interested in doing that through a machine learning model, and they're interested in this being targeted to Western males. Admittedly, that information is very scarce, and there would be much more we would actually know about that particular scenario, but I just want to pull out a couple of words from the small amount of words that are on the screen now and walk through some of our thinking about the assumptions we could extract from that.

[00:16:28] Firstly, around who is immediately impacted. I'm just looking at one very small sliver of the conversation here. We hear the word male, and we must start questioning, in a world that is very fluid, what is actually meant by male. Are we talking about cis males? Do we have to call out that we feel as though we don't have enough significant data to discuss cis females or trans males or trans females or others? This is a very real problem for technology companies: they're often asked by other industries to work on projects where those industries are yet to understand about themselves that the data that's going to be used is skewed.

[00:17:20] When we see the word Western, many other questions emerge. For example, are we talking about males born in Pacific Western countries? Have they been born in the West but are now living elsewhere? Have they been born elsewhere but are now living in the West? What then happens, from being able to explicitly state assumptions, is that we can ensure that the team works through a risk factor if those assumptions aren't verified. In this instance, at minimum, if the profile of the person the solution is to be targeted to is not understood, there will be incorrect diagnosis at best, morbidity at worst. That's just a very, very slim sliver of some of the assumptions that we could make explicit around the two words "Western male."

[00:18:14] Then we can go to the model that's being created. What we often see is companies who are looking for a proof of concept around a model when it comes to machine learning, and in that proof of concept, because they're eager to see results, they're often happy enough not to address the fact that the model has to provide transparency in its decisions to, in this instance, clinicians, or to whoever the target group is that the model is to be supporting. Also, given that there is a very specific data set for this scenario, we need to make explicit that the model will not be trained on any data outside of cis white men in the Pacific Northwest, if that was an item that we had clarified.

[00:19:03] The risk, if those two assumptions are unverified, is that if we are not providing transparency around the decision-making process of a model, a lack of trust by clinicians in the results will transpire if there's an inadequate explanation. In terms of the data being used to train the model, anyone outside of the specified group has a higher chance of being misclassified. Again, misclassification can result in missed cancer, which is a false negative, or unnecessary trauma or even unnecessary medical treatment, a false positive.

[00:19:42] What we typically see as a result of going through risk identification for an assumption, and the alignment of that risk to a responsible person, is that no one wants their name to be associated with a risk that had an opportunity to be explored. No one wants to be associated with the headlines that I referred to earlier. For that reason, this process helps us then engage in an assumptions exploration phase. It helps us think more socio-technically and undertake more holistic system design. It helps set the team up with harms and risk modeling. And all of those items are then likely to ensure we access a greater network of impacted people: all really good things, and all needed and responsible things for the kind of work we do and the kind of environments that our work affects.

The motivations that we design

[00:20:38] All right, the crescendo moment: the motivations that we design. Like any good 30-minute presentation, I'm going to force millennia of study around motivational design into about two minutes. Just for the purpose of this, let's agree that there are five components to motivational design. There are extrinsic and intrinsic factors. There's direction, which is the goal that you're heading towards. There's intensity, the amount of energy that you're going to put into achieving that goal. And there's persistence, ultimately a factor of duration.

[00:21:18] Again, if you're in that setup of being a service provider or a vendor to another customer, or even if you're in a business unit and you conduct your business in a way that makes you a service provider to other areas of the business, I'd love to hear after this talk, in the panel section, what kind of activities you undertake to consider the fit between your customers' motivations and your own. If we're going to go into partnership with a customer, it's definitely our responsibility to be thinking about what their motivations are and what our own are, and designing a way for the two to converge. If it's impossible for the two to converge, we really must have the courage to walk away from the engagement.

[00:22:09] In order to put in place a framework that helps us think about understanding motivations, and leads us toward the path of designing in ways that we can converge and negotiate, I think of it in this kind of cyclical fashion. Through those early engagement conversations, we're really trying to listen for what a customer's motivations are. In understanding what their motivations are, or circling closer to understanding, we're looking at ways that we can identify what our standards are, whether our standards can be met through their motivations, and whether we can design some level of convergence between the two. That sets us up for thinking about how we can begin negotiating: coming back to the conversation and talking about where there might originally be a mismatch and how we can get aligned. And then recognizing the very reality that sometimes there is a need to compromise, but asking how we can be strategic in our compromise. I'll walk through some of the questions and the thought processes that we might go through in order to achieve this.

Handling objections and strategic compromise

[00:23:26] Really, this is about a conversation in objection handling. We will always need to handle objections, and again, I'm very interested to hear what kind of objections you typically hear. Three that I've chosen that are relevant to our world: objection one is the customer that we're interfacing with saying something like, "We've worked with end users and have incorporated their feedback into these requirements, and therefore we don't need any additional help." Objection two: "We can't give you access to frontline staff because they're too busy and they won't have opinions." Brave is the person who says such a thing. And objection three: "To be effective, this is a technical request only, so we don't need to involve anyone else."

[00:24:10] For any of those objections, this is just our starting point. If I pick up the first one, "We've worked with end users and we've incorporated their feedback into these requirements," what I'm really trying to listen for as they're saying such things, and this is obviously a very protracted conversation around their motivations, is what they're actually expressing and what I'm detecting in what's being stated. Are they really saying that they're on a schedule, that there's a very hard stop? And if that's the case, what does that hard stop really require to be proven? Knowing that we have those standards in place, those six AI principles and the standards that we derive from them, where can we find areas that we can converge on? If the customer wants to do something fast and we want to do something right, is there a way for the two to converge?

[00:25:05] As we're starting to discuss the convergence and getting prepared to go in for negotiation, we really have to frame our objectives, frame where we want to get to, in the language of their emotional drivers. Those emotional drivers can only really be discovered through the first step of having a conversation and beginning to distill the motivating factors. And as I mentioned, there will always be a need to compromise. But if you're in this business for a considerable amount of time, and you have enough information to be able to start storming through all of the possible objections you have heard or hear of, you can begin the process of prioritizing your objections. What are the things that you absolutely will not falter on, versus the things that you could potentially compromise on in order to create strategic leverage in the future?

[00:26:02] What I mean by that: in objection area number two, around frontline staff, we'll often hear from a customer that while we can't access frontline staff, we can access managers of frontline staff. What typically happens is that through the research and discovery process there will inevitably be sound bites from that research that make a very compelling case back to the project group as to why frontline staff need to be engaged with. There's nothing more compelling than using the words and the arguments of an organization's own people in order to open access to the people who we actually have to interact with. That's an example of what I would refer to as strategic leverage and strategic compromise. You do one thing that's a little sub-optimal compared to what you would like to do, but you're doing it in the hope and the belief that it will get you a step closer to what you need to do.

Leading with statements, not requests

[00:27:09] I'm going to end all of this with something I say with some hint of reservation, and the reservation is contained in the fact that so much more needs to be understood about different cultures, both at a country level and even within organizations, to know when this is the right strategy to employ. The suggestion is to leave conversations with statements of what you expect, not requests. I'll light this up with a very small example of how I would come to the table in a conversation leading with a statement. I might say to a customer, "Okay, to get started, we need to map those likely to be impacted by this work, and we need to start with a research piece in which they're involved, so let's get started with the mapping." With that kind of directive, the customer would typically respond with, "Okay, well, what do we need to do?"

[00:28:02] That's as opposed to a conversation where I would be tentative, or I'm hearing someone else be tentative, where they would say, "Is it possible to get access to some of the frontline people?" There you're leaving the door open for a no. The customer in that instance is likely to put their own motivations ahead: "Actually, we've already collected the requirements, and our frontline people don't have time." Paternalistic. So you can see how two conversations wanting the very same outcome achieve very different outcomes because of the way that the conversation was designed.

[00:28:42] We started at the beginning of this discussion, or the monologue as it is, asking the question: why is it hard, and who makes it hard, to access people who will be impacted by technology? I wonder, after we reflect on our involvement and what we could possibly do to change things up, if it's hard, maybe we need to experiment with designing some different approaches. And perhaps part of who makes it hard is ourselves. Maybe there are things that we could do to make it a little less hard. My name is Bujuanes Livermore. There is most definitely always more that we can do, and I hope that you, like us, are part of the change that we need when it comes to digital and technology projects. Many thanks. I'm very much looking forward to hearing what's worked for you in the panel discussion afterwards.

Q&A

[00:29:41] Host: All right, that was absolutely fantastic, thank you so much. I have a few questions, if that's all right. Overall, what I've taken from your whole talk is that I could almost unpack every little aspect and ask you to do a presentation on it. It's just fascinating. I'll break it down, starting with the first. Earlier in your talk you mentioned vendors, and you work in the center, between the vendor and Microsoft. A lot of companies would be in the same boat. The majority of companies these days have, in some form, vendors that they work with. How do you manage the customer in that equation? How do you get across the depth of knowledge that Microsoft would have to that vendor, in order for them to do their job and for the customer to be at the heart of it?

[00:30:45] Bujuanes: Yeah, well, I think that last part of your sentence is the goal, and it has to be the shared objective. The customer has to be at the heart of it. There will inevitably be conversations and meetings that have to be had between Microsoft and vendors, but I would say, in the work that I personally have undertaken with vendors, I have incredible respect for the amount of talent that vendors hire and their approaches. These are serious businesses in an industry that's worth a lot of money. Microsoft's ecosystem generally provides a lot of support and training for people to be at the level of skill that they need to be at when it comes to vendors. But I guess you're ultimately alluding to the fact that there is additional engagement management required when it's not just you providing a service to a customer, but you also need to work with a range of other people in order to light up that service.

[00:31:46] Host: And that's, I guess, the essence hidden a little bit in that sentence. Yes.

[00:31:51] Bujuanes: There's a role in and of itself around engagement management for all parties. An area that we have within Microsoft, Commercial Software Engineering, has a role that is very much focused on doing that. The role is a technical project manager, abbreviated to TPM. That TPM is most definitely a crucial linchpin to all of the stakeholders that would be helping a customer at a point in time.

[00:32:24] Host: Fantastic. And just on that technical lead: do they supply documentation that's standardized throughout Microsoft, or would it be unique for each vendor? What does the onboarding process look like?

[00:32:39] Bujuanes: Do they provide documentation to the customer or to the vendor?

[00:32:41] Host: To the vendor.

[00:32:44] Bujuanes: Yeah, I'm probably not best positioned to talk about the legalities. When I'm hearing that question, I'm moving toward that being a conversation around the legalities: firstly around the selection process of the vendor, and then the working agreement between the vendor and the customer. I know enough to know that that is not my forte, and therefore I would direct that question to the legal part of Microsoft to provide very clear and very accurate answers. But generally, yes, there are a number of activities and there's paperwork involved in that entire process, both with customers and with our partners. We actually refer to them as partners, Microsoft partners.

[00:33:37] Host: Ah, okay, yes. I can just imagine, with the size of Microsoft, doing all that would be so complex. It's just fascinating, because it comes up as such a challenge for the industry, and the fact that you're sitting there in the heart of it is really interesting. I want to also move on to GDPR and the data and the human element of our data. Data is so important to everybody, and it's been jeopardized, is the only word for it. What is the future of data sharing? Is it GDPR, like Europe has done, or is it something else?

[00:34:21] Bujuanes: The future of data sharing. I guess if we look at GDPR, the essence of that conversation has been around ensuring that people have a right over their data. However, we're at a point in time where big changes in technology can only happen through a sharing of data, and that's a really fascinating model. If you think about an organization, not Microsoft, any organization in its respective industry, for a long time knowledge and data were power for them in their industry. But we're now at a moment in time where, in fact, combined data becomes, dare I say, power, but when that data is brought together for the good of something, it can become quite game changing.

[00:35:14] For example, APRA, the Australian Prudential Regulation Authority, released a standard earlier this year, or last year, around banks needing to model the way in which their portfolios could be affected if a natural disaster hit Australia. It would be really cost inefficient if those organizations needed to collect their own data around all possible natural disasters and undertake machine learning modeling in order to make such predictions. What would be more efficient, and therefore better financially for the end consumer, the people who are bank account holders, would be if the industry got together and shared a collective data set around possible natural disasters, and then undertook their modeling on that shared data set.

[00:36:08] That's just one example. There are many more examples, particularly in health and life sciences, where there's the need to combine data, and the need to actually look and question whether that history of faculties in science, or health and life science or pharmaceutical companies, controlling certain data sets is really for the good of everyone, or if we now need to emerge from that period and think very differently about it if we're to get to the next level.

[00:36:48] Host: Yep, fantastic. I have a final question here, and it's taking on from the positives that you've just been talking about, and that's on AI. We talk about diversity and race and sexual orientation, everything. Is it as easy as just removing the human element from AI in order to be more fair? Is it as simple as that? And are there any positives in the future for us?

[00:37:21] Bujuanes: I'm not sure that the word simple and AI could be in the same sentence together. I think it's an oxymoron. If we're removing the human element, what's the purpose of AI? If we're to say that AI is about looking at ways in which to augment and improve experiences of something, if it's not augmenting and improving the experiences of humans, what is its purpose? Gosh, that's yet another talk we could do: where is it most beneficial, and in it being most beneficial, for whom is it most beneficial? So many things that we could spin off from that.

[00:38:05] But what I really love about the question is that it forces people into thinking about data, essentially, and where that data has come from. I really encourage, and I don't get any royalties for this, by the way, everyone interested in this space to read Kate Crawford's book, Atlas of AI, in which there's an entire chapter about data. It's written in a way that very elegantly describes the fact that without questioning data, and with us defaulting to thinking that only technologists or only data scientists should be in that process of questioning data, it's that alone that will exacerbate the problems in the world. Because that's exactly what AI does: it requires data to be ingested in order for a model to then spin out what the general consensus of that data is. Unless we are really careful about the data that we're feeding into that model, we will inevitably, guaranteed, be perpetuating the problems that that data is already suggesting.