Shipulski On Design

Archive for the ‘Axiomatic Design’ Category

Before a design can be accused of having too much material and labor costs, it must be able to meet its functional specifications.  Before that is accomplished, it’s likely there’s not enough material and labor in the design and more must be added to meet the functional specifications.  In that way, it likely doesn’t cost enough.  If the cost is right but the design doesn’t work, you don’t have a viable offering.

Before the low-cost manufacturing process can be chosen, the design must be able to do what customers need it to do.  If the design does not yet meet its functional specification, it will change and evolve until it can.  And once that is accomplished, low-cost manufacturing processes can be selected that fit with the design.  Sure, the design might be able to be subtly adapted to fit the manufacturing process, but only as much as it preserves the design’s ability to meet its functional requirements. If you have a low-cost manufacturing process but the design doesn’t meet the specifications, you don’t have anything to sell.

Before a product can function robustly over a wide range of operating conditions, the prototype design must be able to meet the functional requirements at nominal operating conditions.  If you’re trying to improve robustness before it has worked the first time, your work is out of sequence.

Before you can predict when the project will be completed, the design must be able to meet its functional requirements.  Before that, there’s no way to predict when the product will launch. If you advertise the project completion date before the design is able to meet the functional requirements, you’re guessing on the date.

When your existing customers buy an upgrade package, it’s because the upgrade functions better.  If the upgrade didn’t work better, customers wouldn’t buy it.

When your existing customers replace the old product they bought from you with the new one you just launched, it’s because the new one works better.  If the new one didn’t work better, customers wouldn’t buy it.

Function first, no exceptions.

Image credit — Mrs Airwolfhound

When you see good work, say so.

When you see exceptional work, say so in public.

When you’ve had good teachers, be thankful.

When you’ve had exceptional teachers, send them a text because texts are personal.

When you do great work and no one acknowledges it, take some time to feel the pain and get back to work.

When you do great work and no one acknowledges it, take more time to feel the pain and get back to work.

When you’ve done great work, tell your family.

When you’ve done exceptional work, tell them twice.

When you do the work no one is asking for, remember your time horizon is longer than theirs.

When you do the work that threatens the successful business model, despite the anguish it creates, keep going.

When they’re not telling you to stop, try harder.

When they’re telling you to stop it’s because your work threatens.  Stomp on the accelerator.

When you can’t do a project because the ROI is insufficient, that’s fine.

When no one can calculate an ROI because no one can imagine a return, that’s better.

When you give a little ground on what worked, you can improve other dimensions of goodness.

When you outlaw what worked, you can create new market segments.

When everyone understands why you’re doing it, your work may lead to something good.

When no one understands why you’re doing it, your work may reinvent the industry.

When you do new work, don’t listen to the critics. Do it despite them.

When you do work that threatens, you will be misunderstood.  That’s a sign you’re on to something.

When you want credit for the work, you can’t do amazing work.

When you don’t need credit for the work, it opens up design space where the amazing work lives.

When your work makes waves, that’s nice.

When your work creates a tsunami, that’s better.

When you’re willing to forget what got you here, you can create what could be.

When you’re willing to disrespect what got you here, you can create what couldn’t be.

When your work is ignored, at least you’re doing something different.

When you and your work are derided, you’re doing it right.

Image credit — Herry Lawford

When your most important product development project is a year behind schedule (and the schedule has been revved three times), who would you call to get the project back on track?

When the project’s unrealistic cost constraints wall of the design space where the solution resides, who would you call to open up the higher-cost design space?

When the project team has tried and failed to figure out the root cause of the problem, who would you call to get to the bottom of it?

And when you bring in the regular experts and they, too, try and fail to fix the problem, who would you call to get to the bottom of getting to the bottom of it?

When marketing won’t relax the specification and engineering doesn’t know how to meet it, who would you call to end the sword fight?

When engineering requires geometry that can only be made by a process that manufacturing doesn’t like and neither side will give ground, who would you call to converge on a solution?

When all your best practices haven’t worked, who would you call to invent a novel practice to right the ship?

When the wheels fall off, you need to know who to call.

If you have someone to call, don’t wait until the wheels fall off to call them. And if you have no one to call, call me.

Image credit — Jason Lawrence

What do they want? Some get there with jobs-to-be-done, some use Customer Needs, some swear by ethnographic research and some like to understand why before what.  But in all cases, it starts with the customer.  Whichever mechanism you use, the objective is clear – to understand what they need.  Because if you don’t know what they need, you can’t give it to them.  And once you get your arms around their needs, you’re ready to translate them into a set of functional requirements, that once satisfied, will give them what they need.

What does it do? A complete set of functional requirements is difficult to create, so don’t start with a complete set.  Use your new knowledge of the top customer needs to define and prioritize the top functional requirements (think three to five).  Once tightly formalized, these requirements will guide the more detailed work that follows.  The functional requirements are mapped to elements of the design, or design parameters, that will bring the functions to life.  But before that, ask yourself if a check-in with some potential customers is warranted.  Sometimes it is, but at these early stages it’s may best to wait until you have something tangible to show customers.

What does it look like? The design parameters define the physical elements of the design that ultimately create the functionality customers will buy. The design parameters define shape of the physical elements, the materials they’re made from and the interaction of the elements.  It’s best if one design parameter controls a single functional requirement so the functions can be dialed in independently.  At this early concept phase, a sketch or CAD model can be created and reviewed with customers.  You may learn you’re off track or you may learn you’re way off track, but either way, you’ll learn how the design must change. But before that, take a little time to think through how the product will be made.

How to make it? The process variables define the elements of the manufacturing process that make the right shapes from the right materials. Sometimes the elements of the design (design parameters) fit the process variables nicely, but often the design parameters must be changed or rearranged to fit the process.  Postpone this mapping at your peril!  Once you show a customer a concept, some design parameters are locked down, and if those elements of the design don’t fit the process you’ll be stuck with high costs and defects.

How to sell it? The goodness of the design must be translated into language that fits the customer.  Create a single page sales tool that describes their needs and how the new functionality satisfies them.  And include a digital image of the concept and add it to the one-pager.  Show document to the customer and listen.  The customer feedback will cause you to revisit the functional requirements, design parameters and process variables.  And that’s how it’s supposed to go.

Though I described this process in a linear way, nothing about this process is linear. Because the domains are mapped to each other, changes in one domain ripple through the others.  Change a material and the functionality changes and so do the process variables needed to make it.  Change the process and the shapes must change which, in turn, change the functionality.

But changes to the customer needs are far more problematic, if not cataclysmic.  Change the customer needs and all the domains change. All of them.  And the domains don’t change subtly, they get flipped on their heads.  A change to a customer need is an avalanche that sweeps away much of the work that’s been done to date.  With a change to a customer need, new functions must be created from scratch and old design elements must culled.  And no one knows what the what the new shapes will be or how to make them.

You can’t hold off on the design work until all the customer needs are locked down. You’ve got to start with partial knowledge.  But, you can check in regularly with customers and show them early designs.  And you can even show them concept sketches.

And when they give you feedback, listen.

Image credit – Worcester Wired

Al Hamilton, of Axiomatic Design Solutions, wrote a good article on how Axiomatic Design can be used to evaluate multiple design alternatives.

Here is an excerpt from the article:

 

Axiomatic design breaks the design process into four domains, shown in Figure 1.  The customer domain can be thought of as the voice of the customer (VOC).

1. The functional domain is initially populated by mapping the VOC into independent measurable functions. High-level functions are driven by the customer; lower-level functions are driven by design choices. Every function must be measurable.
2. The physical domain is the domain of physics, chemistry, math and algorithms.
3. The process domain is where the specifics of how the design parameters identified in the physical domain will be implemented.

Dr. Mike Shipulski, director of engineering at Hypertherm, a manufacturer of plasma cutting systems, has made extensive use of axiomatic design. Shipulski observes, “By first defining the functions we are to achieve, we align our problem solving on the right areas and broaden possible design opportunities. With axiomatic design, we have a framework for avoiding problems that are often detected only during system-level testing.”