Get Design Inputs with Flowcharts

How do we even begin a design for the user without getting into engineering prototypes? Don't we need to do lots of iterations of prototypes and physical mockups to get design inputs from other people? While these things are great and useful (and they are things we should do), my answer is, "No." We don't need to do lots of iterations of different mockups to get design inputs. In fact, we want to explore the use space with our team before we even start engineering stuff, including the mockups. So how do we get started talking with our team about a design concept without having something to show them? Let's talk more about it after this brief introduction.

Hello and welcome to Quality During Design, the place to use quality thinking to create products, others love for less. Each week we talk about ways to use quality during design, engineering, and product development. My name is Dianna Deeney. I'm a senior level quality professional and engineer with over 20 years of experience in manufacturing and design. Listen in and then join us. Visit quality during design.com.

Do you know what 12 things you should have before a design concept makes it to the engineering drawing board where you're setting specifications? I've got a free checklist for you and you can do some assessments of your own. Where do you stack up with the checklist? You can log into a learning portal to access the checklist and an introduction to more information about how to get those 12 things. To get this free information, just sign up at qualityduringdesign.com. On the homepage, there's a link in the middle of the page. Just click it and say, I want it.

We are going to be talking about design engineering and the use process, but first, let's say hello to our manufacturing friends. Our manufacturing friends use a lot of quality tools to optimize the output of their process, and our business friends also optimize their business processes with lots of other tools. I'm thinking of things like flow charts and SIPOC diagrams (which is supplier input, process output, and customer). Some of the manufacturing quality tools also include things like SPC (statistical process control) and I don't really think that applies, although as I'm saying this, there are a lot of digital products that probably use similar kind of techniques, gathering information and data about us and then offering us products or changing their products so that we're happier with it.

Now, as design engineers, we're not directly responsible for how things get made and the production of them, although our inputs affect how things get made and their production of them, so we need to keep them in mind. We're really designing a product with features to be able to do something on another level. From that is we're designing something for someone to use so that they can get from their point A to their point B, which is the whole use process, the user process.

Manufacturing process, business process, use process. What do these all have in common? There're all processes! There are a lot of quality and business tools about processes that we can borrow for product design, engineering, and it's going to allow us to communicate with our team and explore ideas before we start even engineering anything.

Let me share a story about how powerful just a simple process flow can be in a discussion with a team. Now in this case, we already had a process. We were evaluating instructions for a product. We decided we wanted to update these instructions with a few details, but it had been a while, so we decided to map it out on a process flowchart.

The simplest flow chart is going to have a beginning and an end and steps in between that are going to describe how someone uses a product to get from A to B, beginning to end. When we mapped out this process, we started with the current instructions that we had and then we gathered a team, a cross-functional team. There were manufacturing engineers and design engineers, regulatory personnel, field operations, and other customer facing experts. And we looked at what the process flow was from the instructions, not the instructions themselves, but just the graphical representation of that in a process flow diagram. And that prompted a whole bunch of discussions that I don't think otherwise we would have had an opportunity or the space or the alignment to be able to discuss without that simple process flow.

One thing is we challenged the assumptions of the use environment. What had changed? There were interfacing equipment and other products that had changed over time or were recently undergoing changes that affect how they outputted things, which affected the input to our product. That highlighted an area of investigation.

We also talked about what changed with standard procedures that users now had to comply with. They now had new reporting structures. Maybe at one point this product was only used with physicians, but now it's also used with physicians and nurses. There's new standards of anti infection care (and if you haven't caught on this was a medical device) and there were also new documentation practices that they had to record or document things about the patient and the device and have it uploaded to a secure site or noted on a paper to be able to manage the patient better. We also looked at complaints and we thought what steps were a problem and why were they a problem? And the manufacturing engineers also piped up with the limitations that came into some of the changes that were suggested.

If we didn't have that map to work from, we likely would've never had that open discussion about all of these areas about the use space and the use environment. It did take some back and forth with the teammates to figure out some of these answers, and it brought up more questions, which then needed some research and regroup. In the end, the team was aligned with a much better understanding of the use space and some directions to take with the changes that they wanted to make.

Now, I know in this story that we already had a process and a product and we were studying it for updates. What do we do if we don't have a product? There's no features. There's nothing to turn, twist, or plug into. How do we get started with a process flow diagram if we don't even have that information?

Well, we can. We start with our process boundaries. We have a point A, which is where the customer is starting, then they use our product, and then we have a point B where the user wants to go. Now again, we're going to be engineering the product and determining what features are going to help our customers get from A to B, but we don't have those yet. We are still going to do a process flow diagram and then study it for design inputs.

What could this look like? Say we're designing a portable water pump. Now, I know this is not an innovative idea, but that's what's on my mind right now with current news and situations. Let's first define our boundary. Our point A is that the customer space is flooded with standing water. The endpoint, or point B is that the customer space has no standing water. Our users are individuals, so they're not municipalities. And our assumptions about the use space is that our users have these things on standby in case of emergency and they're willing to use it for themselves or their neighbors. So this thing has to be portable. Or if they don't have one already, they're going to run to a big box hardware store in order to get one in an emergency. And let's also include in our assumptions that they are moving water from an indoor area that was lived in with all their stuff. In between A and B is going to be our new product, which is going to move vast amounts of water.

If you're like most engineers, you'll start thinking about the volume of water to move and the power source and how long it has to run.

And I get it, I'm an engineer too. But let's back up.

Let's define our use process for this sum pump. Now, picture rectangles connecting with arrows at each step and each rectangle is a process step. Our process flow for this concept idea could be step one, transport it to the flood site. Step two, connect it to the flooded area. Step three, connect to a drain area. In step four, start a pump action to move water from indoors to a drain area. Our user process flow for this concept design can be as simple as that. Now let's study it and explore some areas of it so we can better define some more design inputs. Let's look more closely at our third step, connect it to a drain area. What could be some of the difficulties that a user could have with connecting to a drain area?

Maybe their flooded area is in a basement and it has no drain. Well, in that case, they could run a hose out the window or maybe up and out a door. But what if they don't have a hose long enough? Well, we could provide one, but then that would be a really long hose and that would be a lot to store and lug around because remember, they're having this on hand in case of an emergency. What if it's their basement with standing water and flood water everywhere else? The longer it sits wet, the worse the situation. The higher the flood water, the worse the situation. So they don't want to just let it sit. They want to get that water out of there. So what do we do? How else can they connect to a drain area?

What if we give them a drain area? What if we have collapsible water pods that connects to the pump to pump the water into the pods? Now they've gotten rid of the standing water and put it in the pods. Can they put those pods to the side until the flood water recedes? If so, then they can rebump the water from the pods into the drain and finally get that water out of the house. But in the meantime, they've removed the standing water from their basement and maybe save themselves money and damage. Now we've got a change to our process flow. First they transport it to the flood site, then they connect it to the flooded area, then they connect it to a drain area. And here's where we're going to add two rectangles for two new possible steps. Going to add store drain water and connect store drain water to a drain area, and then finally start a pump action to move the water from indoors to a drain area.

Honestly, when I was drafting up this episode and thinking through this example, I really didn't expect to get here. And yet, here we are.

We haven't even started the typical engineering design yet, and it's sort of a good thing because if this pod idea works out, it would really affect our engineering features.

In this process flow, we'll likely want to extend our endpoints, too. So far we've decided to start a pump and move water. We could extend our process flow to clean up and then storage of our sub pump afterwards. We may also want to extend it further to include repair and a disposal process. People get this stuff and then they need to get rid of it. So how do they do that? If we end up going with a pause, do they get disinfected or do they get thrown away? What's the repair storage or disposal process for those?

We can explore all of that with a process flow chart. We can also take it to the next level. I mean, imagine doing this with a team of people that had different backgrounds, what problems we could solve. And I'm really curious, as we were going through this exercise, what kind of ideas were you coming up with? I bet they were different than mine. If we listen to others, we can really get a better understanding of the user and the use space. And with our engineering training, we know the possibilities and the limitations of a design.

I'm going to be hosting a workshop about process flows for product design engineers to get these inputs at concept development. If you enjoyed stepping through this example on this short podcast, imagine working with me on an online workshop where there's actually graphics and I can interact with you.

There's a lot more that we can explore with process flow charts, different ways we can look at them in order to tease out different design inputs. Because we really want to get those important design inputs so we can make the best designs by engineering products. We're providing a service to many other people. In fact, our products serve many people, so we can consider their use process as an important step in defining a great design.

If you like this topic or the content in this episode, there's much more on our website, including information about how to join our signature coaching program, the Quality during Design Journey. Consistency is important, so subscribe to the weekly newsletter. This has been a production of Deeney Enterprises. Thanks for listening.