The Resurgence of Mechanical Turks - A Primer for True AI Based Automation

Megha Sandesh at UXDX Community: The AI Edge: Innovation in Action. Video: https://youtu.be/gwrEOwX7s6Y

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.

Introduction and what Solvedex does

[00:00:07] Thank you so much for the introduction, Rory. As mentioned, I will be talking about how we've gone back into an age where we are resorting to using the equivalents of mechanical Turks in order to almost spoof or pretend like there's AI, and what is a true solution to include humans in the loop and to make sure that we're actually innovating with UX and product design and experience in order to actually build better systems. Through that I'll also be talking about some practical examples that we've done at Solvedex which ended up solving the problems of tech.

[00:00:50] So with that, let's get started. This is our basic agenda. I'll give you a quick introduction about some of the work that we've done at Solvedex and SolveX, and essentially what are the principles that we have set up in order to make sure that we are continuously designing for the human experience, and the journey of the learnings along the way, as well as some practical examples in various industries.

[00:01:20] What we do at Solvedex is that we are leaders in the fractional space. I myself have worked as a fractional CTO and head of product for different companies, and through my work at the different partners, some of which you see here below. I started off as a software engineer before moving into product and design, which has been my true passion all along. During this work I've also managed to set up a separate entity called SolveX, which is our design agency. We work much like any other traditional agency, in that we consult with startups and medium-sized businesses, sometimes large Fortune 500 companies as well, and we try to concentrate on one single problem that they're having. Sometimes that could be holistically the entire company's product experience itself, and really innovate, work one-on-one with the company and the teams to make sure that at the end of it we deliver a product that delights the users and also solves important problems for the business.

How design systems for AI have evolved

[00:02:25] So let us talk about how design systems for AI have evolved. I think traditionally we've had design and we've moved into design ops, right about the same time ML ops came into usage in the modern parlance and practice, and this has also led to a parallel evolution of AI-backed software development and essentially AI-generated products as we see now. But I've seen through firsthand experience that we've not moved enough in the product and UX design space to actually create systems and components which are truly based for an AI-created world, or products that involve AI but with a healthy dose of human interaction as well.

[00:03:17] Obviously we see now in product design that you can use AI-generated content, you can also generate drafts of your workflows, even full-on wireframes from scratch, which get us about 90% of the way there. I've never believed that those are really the problem to begin with, nor that they take the human out of the loop. It's more so that when it comes to use cases that involve a real problem where ChatGPT is not capable enough to help, then essentially humans end up picking up a lot of that brunt of the work, and what is supposed to be AI is simply not.

[00:04:03] So let's go back to the topic of design systems, because at a glance they still remain more or less the same. At the first level you have things like your buttons, atomic designs and basic components to make your program work. Most companies do not go beyond pattern libraries, pages and a few other standards and so on. Because I truly believe that the real product innovation, as well as the payoff, comes from the strategy that you build around your evolution of the design system, and keeping in focus the users that you actually design for, as well as knowing what is the end goal of your product, as well as keeping in mind that every product has an end state and there is an end of life. So effectively planning for that and executing that has been one of the ways in which I found innovation to work better, and this is kind of where we've concentrated a lot of our work at SolveX.

What's missing, and the return of the mechanical Turk

[00:05:08] So then let's talk about what is missing. I've hinted at this before, but one of the problems that comes with the audience that we work with, which is small to medium-sized startups, think anywhere from five people to almost 250: they usually do not have a mature design team to actually man design systems and really take care of that. So you essentially end up building almost like an ad hoc design for the product to meet the goal at hand. And again and again that leaves out the user, who's almost the last in the chain, but we all know that that's actually the most important person.

[00:05:46] And with the evolution of AI and machine learning — so I'm not just talking about LLMs, I'm also talking about traditional machine learning models which truly take in a data set and learn user patterns over time, usages and behaviors, and actually help automate and cut down human effort — when these kinds of things are involved it basically magnifies this negative effect. So we are increasingly designing for AI to talk with other ML and AI algorithms, and increasingly less in a way that... essentially humans have to adapt their behavior in order to accommodate for this, and not the other way around. So we see a lot of artificial behaviors, which means that we're not able to actually create the business value and the ultimate effect. You might end up designing something pretty and something that's fast, but maybe not something that's relevant and solves a real human problem.

[00:06:52] So then let us talk about some of the core principles for AI design, and what constitutes a design delivery system that really shines and makes a difference. We start off with some of the same principles that are applicable for any AI, which is transparency, things like progressive disclosure and giving the user back control so that things can be overridden to the effect that they should achieve, and being able to adapt and build in feedback loops. As you can see it's on the screen, but I'll be going through some of them in detail.

[00:07:31] And once again, putting the human back into the focus is the biggest concern with this one, because as I mentioned, with the reemergence of mechanical Turks — for those of you who don't know what the mechanical Turk is, it is an old, centuries-old machine which was presented to others as a machine that was intelligent enough to play chess on its own, but internally it was just a man operating levers to move pieces on the chessboard. And we see that more and more, most products have to use the word AI in them even if there is no component of AI, and essentially it boils down to badly paid humans who are doing most of the work manually and serving up as a result of the AI.

[00:08:20] Now of course, with LLMs, they've evolved to a point where they're actually useful, and we have seen enough of generative and agentic AI, but there are still use cases and complex systems which are nonetheless extremely relevant, which require a higher level of effort in order to make sure that we're truly making a difference. These are the cases where, simply speaking, the fact that we use humans to do what should be machine work is simply not acceptable. And as I mentioned before, we design for machines and yet we let humans use them in a way that makes everything inefficient. That once again takes the human out of the focus, and somehow we keep the human in the loop and it's never the same.

Case study: contractor management

[00:09:12] So let's talk about a few case studies that I've worked on to make sure that we could actually put the human back in the loop, in the focus, and then design for true automation as we mentioned. One of the case studies where I was heavily involved is a product that I did for one of my partners which involves contractor management. Think about it almost like Uber for home repair contractors. If somebody has a leaky roof or requires a repair to their door, then you call up a contractor who basically visits the site, understands the issue, performs and creates what is called a field bid, which is an estimate of the repairs and the cost and so on.

[00:09:56] As you can see, there are a lot of steps involved where the contractor has to do a site visit, perform an estimate, then somebody else in the back office has to actually approve of that bid, and going back and forth with the final homeowner to make sure that they are confirming that they want to go ahead with the repair. And the other parts that make the system inefficient, or shall we say rife for automation and innovation, are the fact that each county in the United States, each state, has a different level of permitting, different requirements to do the same repair, and perhaps even the skill level of the contractor involved to make sure that they can fully perform these repairs.

[00:10:43] So essentially this is where we trained a mixture of different AI. It was a mixture of an LLM as well as a homegrown machine learning system which was trained for this specific use case, to make sure that it could learn how to automate things like getting permits, creating invoices, creating accurate bids, and making sure that we can actually truly automate this.

[00:11:08] As you can see, I think it should be pretty clear that there's no automating the human work that has to perform the repair. But what we were able to do successfully is that we allowed for contractors to make bids by things like human dictation, text-to-voice, text interfaces, and then that was all input into an LLM, which is again an actual remix of ChatGPT, which was then able to spit out standardized bids which all came in close to the same level.

[00:11:39] So one of the biggest achievements of this was consistent repair estimates. Therefore, even if two contractors visit two different sites, if they're of the same repair, we made sure that the estimates are coming in with around the same range, if not the exact same amount, if it's the same repair, which was a problem that the system was having.

[00:11:59] And then the other big innovation was that we automated the entire process of permitting in certain counties and certain states. This became even easier especially where one contractor was servicing different states. So examples included if somebody was in the state of Mississippi and they could go back and forth to Louisiana or even Alabama or sometimes Florida. They could actually service different states but make sure that they got their same permits on time and save a lot of human headache and effort in the process.

[00:12:31] Going to the next one, here are some other screenshots of that system in action. As you can see, it is a ChatGPT prompt which allowed people to actually generate consistent bids, came in at the same pricing. That means satisfied homeowners, satisfied contractors as well, because they got paid on time for repairs that they did fast and efficiently. So overall a huge win for the system.

Designing for progressive automation

[00:12:57] So then let's come back to the topic and talk about what a design delivery system constitutes in this case, using this as an example. We know that while the ultimate goal of all of this is full automation, we understand that we're quite far off in most cases from achieving that, and that's despite having all of the available off-the-shelf applications and help that we can get from AI systems. And basically we also know that not all systems will ever be fully automated. Again going back to the example of human repairs, they will still remain human repairs until we can actually get machines which are so well evolved that they can also perform the repairs.

[00:13:38] So we know that within the bounds of this problem there's not full automation, in whatever sense that we achieve. So we design for progressive automation and we work on that. That means that all the components that we do in the design system have to involve the fact that they are at a certain level of automation now, but we are looking forward to progressively automating more and more. And it's not to put the human out of the loop, it's simply acknowledging the fact that the system becomes more efficient, so it should not be held back by the UI and the experience in order to do that.

[00:14:18] And basically, by closing the need for what the customer truly desires versus what is actually delivered by the contractor in this case, by the system, by the back office staff, we make sure that we can achieve the results faster, and we can more importantly reduce unnecessary human effort and legwork by automating out repetitive tasks, by automating things that can be taken care of by computers. So in this case, things like permitting, that does not require a human.

[00:14:53] In this case one of the biggest achievements was that more contractors were actually brought into the platform, basically creating more jobs in the process, and it did not make any of the back office staff redundant. Instead it made them more efficient, because they were servicing a larger number of jobs but at a faster rate. Therefore everybody saw growth all across the board. I think that's one of the facets in which we have to use AI, to make sure that people are becoming efficient, not redundant.

Case study: checkout-free grocery shopping

[00:15:27] So for my next case study, this involves a system that we did for grocery shopping. You might have seen some of these analogous or similar systems before. Amazon had what they call Just Walk Out systems. Basically you walk into one of the Amazon stores, not necessarily Whole Foods, but one of their specific stores where they've set up cameras and other systems where they're continuously watching and recording every single shopper that walks into the store. The shopper can then walk around freely and pick up items that they want to purchase on that day, and then once they are done, they simply have to just scan in a QR code and they're ready to walk out. So it's what is called a checkout-free system.

[00:16:14] I was involved in building basically the biggest competitor to the Amazon system. One of the biggest changes that this system allowed for is the fact that, unlike an Amazon store, there was a whole lot of different actions that we knew that the humans would do and we basically coded into the system. So things like, we know that for example people don't necessarily just do grocery shopping by themselves, they also bring in family members. So we allowed for multiple family members, up to eight, to all be recorded and monitored at the same time.

[00:16:48] And when we think about a grocery trip, you can break it down into different components: you're either picking up items or you're putting down items. And then you're also doing things like weighing items which do not have a standard weight. A packet of Lay's chips is always almost the same weight, and you know what are the different weight classes, whereas a packet of meat will almost always have different weights. So you have to account for those things, and that's what the system did.

[00:17:21] So instead of putting the pressure on the user to adapt to the system, the system instead learned from human actions. There was a feedback loop that was built in, and this is one of the interfaces that allows for, again, humans in the loop, in this case who are called quality trainers, who can then correct the system and correctly identify products when required.

[00:17:45] Within the years that we were involved in the building and the evolution of the system, we created this design delivery system where we know each component has a certain level of automation. The things that I'm showing you here take into account the fact that certain components, things like a card, will initially be seen by a human but will be automated away. So how does the system look when it's automated? When we need to give in that feedback loop, when we are at an evolved point in time, we can always come back, but we plan for the level of automation and we plan for the level of precision that's present today, knowing that the system is being trained and the system gets better over time, and the UI enables that and then adapts to that.

[00:18:30] Because the UI here is not just to service the status quo and to simply enable the workflow, it is also enabling the improvement of the system. So when the system improves, the UI gets left behind, and that's kind of where we come in and say, great, now let's make sure that the UI is now ahead of the system so that it can service the level, and then it can also accommodate for where the system needs to go next and become more precise, more exact, and once again not take the human out of the loop but make humans more efficient.

[00:19:04] Now of course, with the system, the goal is to take the human out of the loop and to not have quality trainers, maybe have a quality manager that can come in and do occasional fixes. But that means that those quality trainers will have transitioned to a different spot in the system that requires that evolution. So there is always a plan for obsolescence, for the end of life and things like that.

An unexpected benefit: less tech debt

[00:19:28] So then let us talk about one of the unexpected benefits that we started seeing through efforts like this. Often we don't talk in the realm of tech debt when we're considering product and UX design. But again and again, working through especially in industries like healthcare and enterprise systems, I see that as systems evolve, UI and UX designs and releases in some way contribute to the accumulation of tech debt. It's due to the fact that the UI gets left behind and the user experience is a little previous generation compared to where the actual technical systems are.

[00:20:10] So you worked with ML scientists who designed better and better algorithms through the data and the training sets they were able to accumulate, so that the system was doing things faster, the system was being more precise, fewer false positives and false negatives and so on. And yet the user experience remains static, kind of almost trapped in the components, in the level one and level two of the components that we design, not taking into account the fact that the user has evolved and become better, and the system has done the same thing, and yet the experience often becomes the bad link in the chain that holds them down.

[00:20:50] So then, when modular systems take into account the level three and level four of what I illustrated, which is that we know that the system will get left behind, and so therefore we upgrade the user experience within, because we've already built that into the design system, so now we're actually delivering that experience which not only keeps up with the user and the system but actually outpaces it, so that it can really guide the system and the evolution in a way. That then basically gets rid of a lot of the tech debt that's accumulated.

[00:21:22] So whether it's through implementing a new system, a new backend or a new API, it also leaves behind a lot of the debt that accumulates in the user experience due to using old patterns. Because the fact that evolution is built into the pattern basically makes it possible that we can swap out whether it's individual components or entire patterns without a disruption in the experience, and it just becomes a regular part of the evolution of the system.

Conclusion

[00:21:51] So I'm coming to the conclusion of my talk and I would like to leave you with a few key ideas. We've always known that user experience should evolve, but we've often thought of it in generations or redesigns, with much of the UI remaining the same and the UX therefore lagging behind for most of a system's lifetime. I think it's time to move away from that and really start embracing this level of adaptability. Because we have to realize that we are not designing products for AI, we design products for humans, by putting them in the focus and not just in the loop, in a world that has AI and that is enhanced by AI. That's the world that we actually want to build, and that's done through transparency, progressive disclosure and giving back user control.

[00:22:43] As much as we would like automation, we have to realize that we sometimes have to be vulnerable and actually give back user control, because when the user feels in control is when they can actually achieve their goals. That's really the end goal of every business, is to solve relevant problems, not just to solve a problem faster because they can.

[00:23:06] And let us also be mindful and progressive in how we measure success, by once again keeping the humans at the center and being holistic about what kind of problems we are solving. I believe that this kind of design delivery system will actually lead to better automation, knowing that we are solving human problems, and by actually starting small and thinking about the progress of it, so that we are always learning and failing, but knowing that the system, and therefore the user experience, can actually show the better way forward and we always know we're going in a positive trajectory. As you saw through the case studies, this is possible for small and medium-sized startups and not just large organizations to evolve into, and I see actually a very, very positive way forward if we were to adapt this. So with that I will now conclude my presentation and thank you for your time, and I will be taking any questions that you might have.

Q&A

[00:24:08] Rory: Excellent, thank you very much, Megha. That was some great examples of some of the ways that we can start looking at adapting and using AI in our products. I want to launch with a first question, because one of the biggest challenges that I've seen is, I guess, there's hallucinations, there's the unpredictability. You mentioned in your first case study about permits, and it was helping to do that. Is there a risk there? I think there was an example with an airline where the AI started giving out refunds or something along those lines. Is there a risk that there's some hallucinations and you think you're legal for some jurisdiction but you end up not being? And how did you solve that kind of risk?

[00:24:53] Megha: Absolutely, that's a great question to start off with. This is kind of where the concept of the feedback system really comes into play. And I have to point out that when I mention a feedback system, I'm not just referring to a little form that we use to submit feedback. Sometimes feedback systems can be that, but sometimes it's a full human override, where if required you can completely ignore what the AI has input and you need to do something yourself. So that then becomes kind of an idealized training set for the AI to learn from as to what it is supposed to output.

[00:25:33] The second aspect of it is to set the boundaries very carefully. So we know that, for example, if the repair requires only one roof then that permit does not ask for three of them, because that's the kind of hallucinations that we see. And if we require to replace n number of components, then they shouldn't be a different number. And the other aspect that I touched upon with the specific example of the contractor management was that we also know price bands.

[00:26:00] So you have to build these systems and checks and balances in place so that it's not just one check, but it's multiple checks, and finally that also passes through the human inspection. So again, as I said, we're not taking the human out of it. There's always a human check at the end of it, but now they can actually do it better, because they're not spending about 3 hours just creating that permit. Now they're spending about 30 minutes waiting for it, so that then they can spend that last 10 minutes making sure that everything is in place.

[00:26:28] So absolutely, feedback systems, boundaries and final human intervention, in a way that's actually usable and does not try to just fit or retrofit what the AI has done into something that is more acceptable, is the way forward. Because as I said, sometimes the AI will input something that's just complete nonsense. Most of the time you start with that process, so it is up to us to train the AI. It's almost like training kids: it's better to start with good habits first and train one good habit at a time, rather than start and correct 20 bad ones.

[00:27:05] Rory: Brilliant, that's great. I'm just looking, I think that actually brings us up to time, so we've only got a few seconds left. I just want to thank you once again, Megha, for sharing. I thought that was a brilliant answer as well, particularly because I know I'm guilty of trying to get AI to do a big task. So just break it down into those small little chunks and course correct at each step of the way is a great piece of advice. Thank you.

[00:27:33] Megha: Thank you very much.