Thank you for joining me for today's talk and applying design thinking to how we architect A I products and algorithms to responsibly and positively impact both our businesses and our consumers. I'm Alex, I'm a data scientist and a principal investigator.I specialize in building lightly algorithms from scratch and applying A I to decision sciences, more specifically for optimization and risk modeling. So I was on the phone last week with Chris Wiggins, the chief data scientist at the New York Times and we were talking about the recommendation systems that they were building at the Times and the applied reinforcement learning study that I'm currently leading at Northwestern University. Chris.

And I arrived at this question that I think we all ask at some point, but we never ask it at the correct moment and we should be asking it, which is during early stage product conception. And this question is why do we build products that everyone else has already conceived? So her shared brief slides with me detailing the change in tech processes over the last few decades that I think answers this. Why? So old school dev starts with the founder's vision. Some someone in leadership or a project manager is dictating over product requirement that they think is useful based on prior experience or heuristics. Or as I like to call it based on bias, we machine learning engineers and scientists are then ordered to build the entire product in a waterfall methodology fashion which we all know now is outdated and has been replaced with agile methodology. But you can see the limitations are that this flow is extremely linear. The worst part of this process is that the consumer is the last thought, we may actually have zero market for this product. And then we as devs have wasted weeks on a useless product that someone with a title and a ton of bias dreamed up in a silo. So next comes lean tech or what we know is agile methodology.

Here, we as scientists and engineers build a minimum viable product and we cyclically iterate on it to get to a stable state worthy of presenting or selling it. However, we still succumb to the founder's bias in this model. The iteration is solely focused on pleasing one person's end goal who may not even be a viable user for this product. So in comes a design thinking framework and we apply this framework to the agile methodology as it cuts out the bias and lets us as scientists dictate what the stable state of a data product will be through objectivity and observation. This change to consumer research indicates that we are susceptible to our biases. During early product development, many companies suffer from developing the same products over and over again because they do not acknowledge that we have inherent bias and they ultimately do just do not design for their market.

So I think Chris's lives definitely answered the why. But that I asked the, how, how do we build products that no one else has ever conceived? And so through the lens of interdisciplinary design, I will pose my master's thesis problem that became a study I'm leading today at Northwestern. It was through this lens that I thankfully resorted to design thinking to solve an incredibly nebulous problem. So I think the only step that really cannot be ignored when hoping to design something that no one else has designed before is to think big, think grand and think disruptive. I encourage you to be someone who does not cower at the word. Disruptive. I've worked with many scientists who will outright fly a mention of that word. And quite frankly, they have a track record of just zero innovation. So I ask this extremely high risk, high reward question as I tend to deal with research in life. And the question is, how do we optimize mass casualty trauma triage in urban US health care systems? And I ask this because I identified a problem where there is no standard standardization of trauma triage policy across the US and every trauma surgeon does things their own way.

Every health care system is designed differently and every state handles emergency response differently. So I trained as an analytical biochemist for seven years and I decided to default to solving this with the scientific method. I was also specializing in operations research at the time I did this thesis and I was sort of helping in utilizing a linear programming algorithm. And that was my first and greatest mistake. What I realized was using the scientific methodology framework with a fixation on a preexisting model that I had in mind that I really wanted to build this entire framework failed epically. I was letting the end product that I wanted to, that I wanted, which is this linear gold programming algorithm drive. The way I approached the question for three months, I couldn't formulate a testable hypothesis that could be solved with that end product that Gold programming algorithm that I designed for a long time. I just thought I misunderstood the math behind both programming. But really I misunderstood that the end is not a specific algorithm. It's the ability to save first responder time and civilian lives by any means necessary.

And so then when I repeated those four words by any means necessary, I remember that I'm not only a scientist, but I'm also an artist and a designer and to make art to create a drug discovery platform, I had to iterate fast and put biases behind me if I didn't want to get ideas um left behind.

So I actually have studied interdisciplinary design under some of the brightest and most creative minds I've built and sold art and technical designs at a rather crazy pace after I graduated college, right before I turned 25 because my young naive self inherently understood that part of the process of making something useful of making something beautiful was getting the bad art and the bad design out quickly while still on the same trajectory to formulate something incredible.

So it turns out that using my interdisciplinary design background allowed me to solve the mass casualty trauma triage problem using reinforcement learning. And I put three exclamation points for three months. It took me to finally get to that formulation and then I actually built the algorithm within five days. The design framework didn't allow for a tech product to drive my question. The way the scientific method allowed it to even if both methodologies take an observational approach at the beginning to formulate that question. Concrete methodology is a requirement of the scientific methods, hypothesis generation, the hypothesis testing. While in design, it's more flexible, you just need to get to a solution by any means necessary. So I have three question marks on this slide. Well, I told you I use design thinking to solve this really nebulous problem. But I want to share the principles of design that actually contribute to developing something groundbreaking and something impactful that serves to benefit society. So my studio art mentor and my thesis advisor at Boston College Professor Alston Conley introduced me to the work of a brilliant industrial product engineer, Dedo Rams Rams was a prolific German designer who created some of the most innovative and disruptive products for braun from experience throughout the course of his career, grams established 10 principles of what he calls a good design.

Ram started the process and continued to ask this question throughout product life cycle. He asked is my design a good design. As chief of design at Bron, he managed to oversee at least 500 innovative products that unequivocally and irreversibly reshape the landscape of electrical pro product design.

While I was studying NANO engineering at Harvard, I asked myself at every stage of this development. Um I ask myself this question on every stage of development. While I'm designing algorithms, I ask myself this at every stage of A I development as well. Even today when I'm using out of the box models from car or tensor flow. So spoiler alert when it comes to the first MVP iteration of any A I or algorithm product that you're developing. The answer to is my design. A good design is always a resounding. No. So let's jump into the 10 principles that I think refutes that no and gets us towards a stable state, great long lasting product. So the first principle of Rams is good design is that good design is innovative, right? You need to think big, you need to think destructive. You need to allow for full creativity and no thought about tech. At first, you need to have a growth mindset, approaching solution with a growth mindset reassures us that failure is an important and necessary step of the process. Because then we can improve our skill set by addressing our shortcomings. It relieves us from rigid thinking of. I know what I'm doing that occurs when we've created something useful or production before we also need to be problem oriented. This is when you accept the call to unbounded innovation, knowing that you're gonna handle risk management. Next. When you're problem oriented, instead of tech oriented, you can approach solution with fearlessness. And so to achieve fearlessness, we get to the second principle which is good design is honest.

We are honest with ourselves and we have taken the time to get to know ourselves. We know that we are inherently biased and we work to understand the roots of those biases. We accept that failure is part of the process and we choose an engineering mentality of fail early and fail. Che we strive for a low cost and lean minimum viable products that we build up incrementally instead of completely tearing down or rebuilding without actually refactoring the problem and the solution. We embrace active problem solving through iteration rather than just trying to get it right on the first go, which brings us to the third principle which is that the design is unobtrusive. So we choose to enhance the quality of life with algorithmic or model development instead of creating a product for products sake, design thinking at heart is a social technology framework. We take a social approach to development, understanding how to design function through user testing and feedback.

We collaborate with not only our internal stakeholders and our engineers, we collaborate intimately with our market, our user base and our potential customers. Beyond market research, we are unobtrusive because we are empathetic. We are humanist to begin development. We want to approach algorithmic design by how the world interacts with the product. Not how we think the product will shape the world. If the world does not interact with the product, it becomes yet another piece of junk taking up space. And this is what it means to design something that's unobtrusive. So the fourth principle is that the design makes a product understandable. You have to do your research. If you don't understand your algorithm down to the functions of its elementary components, you don't understand your product and neither will anyone else during development, you have to ask yourself two things. What does the process feel like? Versus what should the process feel like?

This is how Chris and I think as systems biologists by interrogating physiological systems and interactions on a macro level, I was able to build A I products in industry and academia that drive molecular discovery on the micro or actually the nano level, the body is a system, the human body is a system but it exists within a super systems of other human bodies that can pass infection.

And all of that is driven by small molecular interactions within their own nano systemss. So we achieve understandable products just like an easy to dose small molecule that works as a drug, a large human system for an even larger system containing more human systems. And this is called developing a systems engineering mindset. We build A I products as models of our world. The world exists as a network of systems with processes and actors processes takes things in, they modify them and then they return processes are like our models or our functions.

Actors make choices and take actions. Actors are like our agents, they're humans and our actions are our inputs, actors act on processes and are affected by processes. Actors generate outputs because they act on processes and then those outputs then feed back to the actor's choices so that they can make decisions, take actions and affect processes again. And we know this because all systems are interconnected. So this broad rather in depth approach unlocks understanding of how a product affects everything, not just a tunnel vision view of the world, we make a product understandable for consumers because the sum of its parts are designed specifically for the benefit of the entire system which brings us to the fifth principle that good design makes a product useful instead of following prior knowledge and experience, which we already said is inherently biased.

The goal is to make something or to address something that we want to be useful. So we have to yourself, what does it mean to make something useful? And when you ask this question, you address poor functionality of your product. And this is exactly what you want to build towards because it's based on consumer research and the design thinking framework. And it's what our market wants and needs. And the way we get to what the market wants and needs is to observe the behaviors of the constituents of our target market through empirical objectivity or observation. This is an ethnographic technique used in social science and it's useful for removing ourselves and our biases completely out of the equation. This is how artists learn to draw realistically from simply drawing what they see. And then this is how A I scientists create disruptive innovations by observing where others products have failed due to inadequately delegated requirements for their consumer base. So good design is ethical being ethical is using as much real world experience to drive product development as possible.

And when we talk about ethics in a ina I, we talk about fairness. When we train on biased data, we are damaging the path to optimal because we are pre segmenting our user base programming bias is anti fairness to the consumer and to the business lack of ethics and product design damages entire systems by isolating or even worse, stigmatizing segments of your population.

So run your descriptive statistics, cut the data up in all the ways. Ask for more data and really broaden the demographics of your market to be inclusive is to be fair. And it only means your product will be in the hands of more people that's generating more attention and more revenue. And the more users you have means you'll gather more data to iterate towards a stable long lasting state, which brings us to the seventh principle, which is good design is long lasting. We know that model performance degrades over time. How can we interrogate the system correctly by asking the same core questions in different ways to ensure that the product continuously fulfills key functionality requirements. But it is flexible and modular enough to iterate on over time. Modularity is what allows us to test the integrity of the model of the system. But it also allows us to understand how the system then drifts over time. So the eighth principle is that good design is thorough down to the last detail. Let's ignore that. As tech developers, we need to absolutely unit test every modular component address sub optimizations in common our code. And I say ignore these because we understand that these should already be ingrained into our practices.

So being thorough down to the last detail means looking at your product, not only objectively but from different shoes back to the principle of being unobtrusive. A thoroughly designed product is based more on how the system interacts with it, not with how we think it affects the system.

Because more most products have very little effect on the world as we know it. So we must look through different lenses when drilling down a problem. And we take the system engineering approach to make a product understandable shipping lenses is the successor step to empirical objectivity because we understand that our system's constituents um or we understand the constituents well enough to empathize better with them for tailored or personalized solutions.

And in systems biology, we call this precision medicine because we have objectively observed a biological system with such encompassing breath data that we know exactly where to dive deep and where not to to make a new drug or vaccine. So one way I like to change lenses in business is instead of only focusing on the consumer base at hand or the population, you have data for think about where the population that you're missing. Start to wonder why does use or existence of your products still affect them indirectly. The out segment of your market is just as important as the segment. In fact, when you tap into the potential of your out segment, you create a truly innovative product that no one else has because you're cornering more of the population with a broadly useful product. And more importantly, you know which subsets of the out segment critically fail on.

So you don't dedicate and waste resources behind those initiatives. And the ninth principle is that good design is sustainable. When we try to be disruptive, we know that we're aiming to alter society policy and behavior at a very large scale. Touching back to ethics, fairness and longevity.

Sustainability is the culmination of those principles in how the world perceives our product. Anyone can look at the algorithm design and understand it well to iterate over and over time. But we cover, I mean we cover that with modularity and product being long lasting, but a sustainable product is not only modular and useful, it is defendable over time. A sustainable product is defendable for use in principle forever because it is just it is robust and it's maintained with a high level of care and research that is appropriate for the current time and the current user base sustainability is the essence of risk management and governance.

So we have our final principle now that good design is as little design as possible. My specialty is building lightweight highly modular data, verve resistant algorithms. These are the types of models that fit efficiently and very safely into pre-existing pipelines and lend to simple and elegant monitoring orchestration processes. These are sleek products that appeal to a large market simply because they're simple, they're easy to deploy into the hands of consumers who can easily understand the input, the processes and the output. I wanna thank you all for again for listening to my take on design thinking and how we can apply it to make better A I and algorithm products for businesses and consumers. I wanna leave you with this little image that I look at at least once a week. It says don't grow up too fast, too soon. Save some time for dreaming Because at the end of the day, the core of design thinking is can you observe the world differently enough to dream bigger for it? So I wanna thank you guys again for joining in today and listening to this talk.