Course 3: Design for the Users

Welcome to lesson four, relate tasks to design decisions. If we've done a process flow, we'll see that there are certain tasks that might be more critical than others, especially where the user gets involved in making a decision or otherwise interacting with our product. Today, we're going to explore how to further analyze those tasks from the user's headspace, what they perceive, what they know what they decide to do from that. We'll be able to mistake proof our design. Again, we're looking to design in controls and design out problems wherever possible. This is going to result in a product that is the most user friendliest product that we can possibly make. Now we've been exploring the use process for design inputs. And this lesson we're exploring the general use process of how we're going to get from A to B or how our customers are going to get from A to B. We're also exploring concepts with our cross functional team before product design. We're getting to better know the users, the use environment and the use process. We're also starting to better understand a little bit more about our product, how it might be looking what kind of specific interfaces our users could be having with it. So in this lesson, here's what we're going to learn. We're going to describe a use error and its effect on design inputs. Not everybody gets the definition of use error, right. So let's talk more about that. In this lesson, we're going to name the three basic interactions that users have with our product based on psychology. We're going to be able to analyze tasks and use errors to be able to get design inputs. And we're going to be able to do this with our cross functional team. And we can then relate task analysis with other product development activities that are going to help us further make decisions about our product. So first let's get some alignment on what a use error really is. Now as engineers, we're used to failures and problems and we design for failures and problems and causes. So we understand that we design actions around a problem. And we also know that a problem is sandwiched in between a particular cause or a factor that can lead to that kind of problem. And on the other side of it is the symptom which are the things that people notice that's wrong. But is it necessarily the problem? Well, a use error is really a problem or a failure and we design actions around the use errors, it's a deviation based on what we expect it to have happen and it's based on the user action or the lack of action. A use error also causes a result that was different from the result expected by the user, not just us and it's not caused solely by a device failure. If we can think about the use error as a deviation from what we expected the user to do. We're well on our way to better using the definition of use error for design inputs. Psychologists, human factors, engineers and usability engineers break down use errors into different levels and different categories. But for the purposes of our design inputs, we're going to look at the high level types of use failures. The three types of use errors are inadvertent action. A thinking error or a deliberate deviation and it invert in action is when our users know what to do. But because of a slip or a lapse, they didn't do what they meant to do. A thinking error is an error of judgment or they did the wrong thing, believing it to be the right thing. You can also think of a thinking error as a mistake. A deliberate deviation is that they meant to do something that way that they were doing it wrong because that's normally how everybody does it or what everybody's doing. Think about speeds on highways. Most people are going above the speed limit. That's the norm. So that would be a deliberate deviation or our users did it wrong because of a certain situation or the task was impossible. So they skipped it or had to do it a different way or they decided to take a calculated risk. The important thing to think about with use error is that its scope for design, for product design is that the use error didn't happen because of a user. The use error happened because of the use process. The use process didn't adequately account for that kind of use error. Now notice two, the term use error, it's not use er error or human error. It's a use error and the root cause that we want to look for or what was wrong with how our device works with our users. We can't fix users but we can design products. Our customers are interacting with our product. We want to avoid causes of use errors that are stated like our user did it wrong because we can't design to that. What went wrong? If we know that, then we can design for that. Even if it's a deliberate deviation. If it causes a problem, we want to explore ways that we can design for that. Use error. Here is a classic example that I think of a push lawnmower. Now a push lawnmower, you get it started and you usually push it along the ground to mow your grass. Well, there have been instances where people decide they want to trim their hedge with it. So they reach down with both hands and pick it up and try to trim their hedge with the push lawnmower and of course, fingers and digits get removed and injuries happen. Now, that is a use error kind of a problem. But if the product designers just said, well, that's just the user's problem and did nothing about it, that would be a lost opportunity. What the product designers decided to do to eliminate that use error was to add an additional switch, a push lever that the users have to pull up and hold this lever against the push handle. In order for the motor to run. If they let go of it, the motor dies, it kicks out. So that prevents the user from picking it up while it's running to use as a hedge trimmer. There's nothing to say that the user couldn't rig that up to tie the switch to the handle. But there is a built-in feature of the product design to prevent this use error from happening. Those are the kind of things that we want to look for in our own product designs and there's lots of benefits in doing so it makes our products easier to use. It decreases the support costs and the complaints that we get and like the lawnmower, it reduces risk, risk of something not performing right risk of safety and hazards and health and other kind of risks. It also makes our product more desirable if we design for the users and design for use airs it might be something more fun for our customers to be able to use. So those are use errors. We also have basic user interactions with our product. There are really three modes of a user interaction. During a task, we can think about our user and our product or system as having an interface. When our product gives an output, our users are perceiving things with their senses, they're touching, feeling, hearing, smelling, seeing all those things are perceiving the output of our product. Then they think about it and process the information and then decide how they're going to control or act and that could act as an input into our product design. Now, this kind of a framework is standard, it's called the PC A framework. And P stands for perception, C stands for cognition and A stands for action. If the users can't meet a task requirement, a use error or difficulty is likely to occur. And we can think of these as the cause of the failure. So they either don't perceive something or they don't think about something in the right way or the action that they take wasn't correct. So we can use the PC A framework to figure out the root cause of a use error that we see during a test. Maybe later in development, we have some formative studies, we have users testing out our product and giving feedback and there's some use errors. We can use the PC A framework to get to the root cause of why that error occurred? Was it something they perceived? Was it a misunderstanding or did they take the wrong action? We can also use the PC A framework as a way to explore, use errors for design inputs because we can eliminate or control causes. We can adopt the PC A framework as three task requirements for every task or function that we're asking our user to take with our product. There may be three requirements we have of them. What is the perception requirement of a particular task? What did the user perceive or not perceive with their senses that led them to make a use error? We can also look at the cognition part of it. Our users apply what they know what is their knowledge gap or a misunderstanding of this task that led them to make an error or our task could have an action requirement. What manual action did the user take that ended up leading to an error? So we can use this kind of information in a task analysis so we can get design inputs. Now, we're going to use the PC A framework to explore potential use errors so we can design for them. We first think of our high level functions and this is what we've been doing in our process flow charts. Just high level concept functions as we start developing our product, we're going to be coming up with specific tasks. These are things that we want our users to do, turn this lift this and et cetera. Then we can also think about the task requirements. This is how we can use the PC A framework as part of our task requirements. Now, we may not be talking about an observation of a user actually using a product. There is a time in development where we don't have anything for the users to manipulate. So we explore the PC A framework to better understand what design inputs we need to incorporate into our product design. And this is again, something that we want to do with our cross functional team because they have a particular viewpoint, understanding of the use space and of the users that is different from ours. So we want to be able to learn as much as we can about our product in the concept phase. So we're going to rely on our cross functional team. Now, here is what a task analysis template looks like. It's a table that we do fill in from left to right. And we are breaking our task into smaller steps. And this is where we may need to know some of the designs, some ideas of how we might be building our design as we're developing our design, our tasks are going to get more specific and we can get more design inputs from them. But for now, we think about the task as related to a function, what needs to be accomplished. And then we're empathetic to our users. And for this important task, we ask, what do our users need to perceive, understand or do for this task to be successful? Now, once we had that, we can think about what type of use error could be made at that step. Was it an inadvertent action where they forgot something? Or was it a thinking error where they thought they knew that they were doing the right thing? But they ended up making a mistake and doing something different? Or was it a deliberate deviation? And why was it a deliberate deviation from there? We can talk about the consequence that this task wasn't accomplished as we expected and we can start developing design inputs. How can we eliminate, reduce or control the error? And it's based off of the perceiving the understanding and the acted on, we can start to develop some design inputs based on the PC A model. If our task required our user to be able to perceive something and then there was a use error that was caused because they didn't perceive it. Then we can think about design inputs as reducing or removing distractions or interruptions so that they don't have a slip or lapse or we can think of pokey. Ok. Or mistake proofing where there's an inspection or an automatic inspection that's making sure that stuff is done properly or we can look at alerts, alarms or warnings to indicate that something wasn't done right? That a use error had occurred. A great example of this is the credit card readers. If a user leaves their credit card reader in the reader for too long, it starts to beep and holler at them to take their cards. They don't leave it in the reader and leave it behind. If our task required our user to have some cognition requirements, then we can help promote understanding with our design inputs. We could use embedded warnings or make it easier for the success of the task or harder to make an error. We can do that through simplifying or standardizing to other types of actions. If our task required our users to take a particular action that they didn't take, then we can look to eliminate the reasons that they took a particular action. Tasks that are unnecessary or unrealistic or inconvenient or take too much time. We can look to address those kind of reasons with our design inputs. We can also apply mistake proofing to an action task. While we're evaluating task, we want to remember the whole concept space because our process is still within this space and we want to be consistent with the inputs and the outputs. We're spending the time to do this task analysis for design inputs. But what are some of the other activities that we can use a task analysis for? Well, we can use it to analyze functions and tasks early we can focus on the priorities of the use process. And as we learn more, and as we're developing our product, we can further refine our design inputs. The whole idea is to do what you can with what you know. And then iterate. The other thing to note is that the more complex our product is the higher the likelihood that we'll get use errors as we're developing our product. If it's getting more complex, we may want to revisit or do some more task analysis to make sure that we have the appropriate design inputs. And there are a lot of other uses for our task analysis and other product development methods. We can use it to help us develop the product interface, human factors engineering and usability engineering would use it for their inputs. And part of that is part of the study planning that they'll be doing with the users. And as we're getting test results back from those studies, we do with the users being able to understand the root cause for the errors that we noticed during test can also help us with labeling and instructions with understanding what it is. Our users really need to know about our product. Is there something particular about our product that's different from the other things that are out there? A task analysis could help identify that for our labeling and instructions and even maybe some user training programs outside of some of these immediate design inputs. We think of as part of product design, we can also use it for risk analysis in a system failure mode effects analysis or a use F M E A. We can take the task analysis and put it into an F M E A to further evaluate the severity and the occurrence to evaluate the risk and further prioritize design activities. Reliability engineers can use it to help them develop test plans and to better understand the limits of a design and quality can use it to determine what features need to be monitored and how that links to usability. A task analysis is a great thing to get started in concept development and it could be shared with the rest of the team who's going to use it for a lot of their parts of the development. Also a task analysis like this can get pretty large. So I recommend choosing those parts of the process that that are critical. Again. We wanna move forward with the design, but we want to do it with information and a task analysis can give us that. So what did we talk about today? We talked about the real definition of a use error because we want to define design inputs, not place blame. We name the three basic interactions that our users have with our product and how to be able to use that PC A framework to analyze task and use errors so that we can get design inputs and finally, task analysis can be used for a lot of other things in product development activities. So it is definitely a worthwhile thing to do with the cross functional team. Thanks for joining me and I look forward to seeing you in the next lesson.

[progressally_media media_id="2"]