ZenStorming

Where Science Meets Muse

Posts Tagged ‘design process’

How to Make Sure Prototypes are Useful, Even When They Fail

Posted by Plish on November 28, 2016

It worked flawlessly for 4 minutes and 25 seconds…

And then it didn’t.  The VP smiled and said, “I get the idea.”  After getting through the embarrassment of the failure, the team learned what went wrong, and got to work testing variations of the failed component.  The new versions didn’t fail, and the product went on to eventually make millions…

 

“Risk comes from not knowing what you’re doing.” – Warren Buffet

Risk and fear walk hand in hand with lack of knowledge.  The best way then to minimize fear and minimize risk is to understand,  to know what’s happening.  Prototypes are part of that knowledge building process.

The knowledge base that takes shape through prototyping is equally, if not more, valuable than the actual mock-up itself.

The challenge in most organizations is to make the shift from being object/success based, to process/knowledge based.  Then, even if a product never gets commercialized, the knowledge that gets created can be used for other products, other projects, and make those into money-makers.  Knowledge creates a bolder approach to the future!

What do we do to make sure we’re after knowledge, not just results?

Whether you are creating products, services, or even a new business model, don’t think of prototyping as a ‘testing an idea’ event, but instead as a learning process.   The best way to change into a process based mentality is to ask questions, and then create prototypes that will get you that knowledge.   Three basic questions guide how you get that knowledge as efficiently as possible.   Notice that nowhere are we asking,”Will this work?”  Instead, ask yourself these questions and then start prototyping!

  1. Which answers can I get to easily?  Easy translates into fast answers.  It doesn’t necessarily mean cheap, it just means  that there are few moving parts, so to speak.  The relationships are clear cut – there are anticipated outputs for each input.  Subtract a dimension from your  concept and test that.  For example, if a knob has three dimensions but you want to see how easy it is to grab,  cut it out of cardboard and build a two-dimensional model. Sketch when you can.  Is there infrastructure in place, such as test equipment, that makes it easy to test something?  Quick answers, that’s what you’re after.  You might not be able to go to the moon with your prototype, but you might be able to get more confidence that it’s possible.
  2. Which answers can I get cheaply?  Low cost doesn’t mean quick or easy, though often it does. These prototypes also often aren’t highly accurate. But that shouldn’t matter.  Can you build something out of polymer clay instead of 3D printing it, or molding it?   Find ways to duplicate function using cheap materials or techniques.
  3. Which answers  will give the greatest bang-for-the-buck?  Getting these may be neither cheap to test, nor fast to create, but, at the end of the day, they yield potential answers that could unlock future decisions.  To find these, ask what part, system or sub-system, if you eliminated it from the design, would cripple it hopelessly?  What is key?  The movie “Victor Frankenstein” is playing in the background as I type this.  The electrical charging system is key to energizing Frankenstein’s creations as none of his creations are possible without electricity. Those electrical systems are his bang-for-the-buck systems.  Those are the types of things you want to prototype!

With each of these three types of prototypes, make sure that you have back-up plans.  Make extra parts.  Make variations. Confirm that you understand why things are happening the way they are.

When do I prototype the final product?

Even though it’s often tied to ‘go/no-go’ decisions about a product, prototyping the final version is part of the prototyping process spectrum.   It’s still about knowledge creation, so if you’ve learned what you can about the systems in simple, cost effective methods, and you’ve learned about the ‘bang-for-the-buck’ systems, there shouldn’t  be many surprises.  Still, expect the best, and prepare for the worst.  Have plans in place to deal with those surprises.

Remember, prototyping is about knowledge creation!  That’s why failure is okay. (In fact,  believe it or not, you want some level of failure!)

Let’s summarize what it takes to make sure prototypes are useful.

Make various types of prototypes to answer questions:

Make easy prototypes.  Learn.

Make cheap prototypes.  Learn.

Make prototypes of your key components and sub-systems.  Learn.

Document your learnings.  Build upon what you know.  Experiment to find out what you don’t know, and document it so it can be shared.

Follow this process and your prototypes won’t just be an artifact tested in a one-time event.  They will be doorways to knowledge, and knowledge eliminates fear, allows you to deal with risk, and ultimately, leads to success.

 

Advertisements

Posted in 3D Printing, culture of innovation, Design, design thinking, innovation, Innovation Tools, problem solving, Workplace Creativity | Tagged: , , , , , , , , , , | Leave a Comment »

Obviously Hillary Clinton Will Win – Four Post Election Lessons for Designing and Launching Innovative Products

Posted by Plish on November 9, 2016

Poll after poll showed that Clinton would be the next president of the United States.  They also showed that even though Trump supporters said that they would vote for him, they still expected him to lose – they expected a Clinton victory.

Poll after poll were wrong.

What happened? Why the misleading numbers?  How do I make sure that I don’t make the same mistakes and misread the signs when designing and launching products?

Launching a successful product can seem like a crap-shoot.  You roll dice and hope for the best. In the wake of Donald Trump’s stunning presidential victory, there are four lessons that those designing product/service launches would be wise to heed. Let’s take a look.

People don’t want to feel like outsiders – they want to be in the ‘in’ crowd

People don’t like Donald Trump.  It was obvious.  Even people in his own party were against him. Heck, when is was clear that Trump had won, MSNBC host Rachel Maddow wasn’t even subtle in her dislike of the President Elect.  With this type of negative environment being prevalent, people who were pro-Trump didn’t want to be seen as supporting someone who was so hated.  The result?

They either lied and said they were voting for Hillary, or claimed they were undecided.

The lesson here, is that people need to feel welcomed and accepted if you’re going to get the truth out of them.  If you’re designing a product and the users don’t trust you, or think that somehow their participation in a research study will impact them negatively, odds are you won’t get the truth.  Build trust and give people a safe zone to say what they want.  But be careful, this is only part of the story.

People tell you what you want to hear

History is replete with products that tested well in focus groups and then failed miserably when launched.  One of the main reasons for this is that people will tell you what you want to hear.  Or, they simply don’t know what they want so they pick whatever it is you’re showing them and they say they like it.  Focus Groups can be funny things.  Are people really telling you what they think, or are they telling you what they think you think they think?

So be open to reality

Some years back I was working on a project that was a ‘next generation’ version of a medical product I had designed the first generation of.  Only two years had passed, and while the market, and the medical procedure the product served, hadn’t changed appreciably, I made sure that I wouldn’t be the only one doing research.  I called in additional researchers/designers to watch the procedure and asked for their feedback.  I was afraid that I was only going to see what I wanted to see and end up with a slanted, if not erroneous, perspective on what the doctors were doing.

In this election, pollsters anticipated reality.  Pollster John Zoghby believed that polls were too heavily slanted Democrat.  This lead to over-estimation of a Hillary Clinton lead, if it was even there at all!  You’ll never see reality if you think you already know how reality behaves.  We see what we want to see.  We may not be malicious about it, but sub-consciously we think we know what’s really going to happen, so we set up our research to prove that true.

In the world of product/service design research, we need to find out what’s going on, not prove we’re right.  The stakes are too high.  Companies, organizations, communities are investing in a product that is supposed to pay them back in some way.  Not understanding the situation is the first step to catastrophic failure of a product launch.

So at the end of the day, do what people do, not what they say

Yes, you can be the first to predict reality, but often the better route is to let things play out a little more and then jump in the game with a passionate verve!  This has the advantage of getting actual data, actual feedback.  This information is much more actionable and since everyone else is wrong, being  a little late to the game won’t be a negative, it’ll be a huge positive!

If you believe that you need to predict reality and launch at a specific time and place, then don’t pick one horse in a race.  Place multiple bets.  Have a Plan B, and Plan C…Plan(x).   Then, as reality starts revealing itself, roll the appropriate plan into action with modifications as needed.  Incidentally, the first generation product spoken about in the beginning of this article was just such a multi-plan launch.. That enabled it to launch with the right components at the right time, even though the very beginning was touch and go understanding what was truly essential to the offering and what wasn’t.  In the end, we got it right.

That’s ultimately what it’s all about – getting it right.

One way we can get it right is to learn from what others have done wrong.

So regardless of whether you’re crushed or elated with this election (or perhaps even feeling a little of both!) pay attention to these four tips based on what was done wrong, and your next product launch won’t unexpectedly fail – you will get it right!

 

 

 

Posted in Case Studies, culture of innovation, Design, design thinking, innovation, Uncategorized | Tagged: , , , , , , , , , , , , , , | Leave a Comment »

Embracing Scope Creep

Posted by Plish on July 23, 2010

We’ve all experienced it.

We’re cranking along in a project and someone comes in with a ‘brilliant’ idea or a new documentation requirement. 

AUGHH!  Time is ticking, money is being spent.  Why couldn’t this have been brought up at the beginning of the project?!?!

There are basically three responses:

  1. Ignore the request and move forward promising to fold features into the next version
  2. Agree to the request and try and get more time/money
  3. Agree to parts of the request and move the rest into the next version.

All three of these cause angst to the team, to management, and perhaps even the users.  They result in more time and money being spent.  Creativity likewise drops as people go into crunch mode trying to accomplish more with less. 

It’s Scope Creep.

So, why would anyone want to embrace this?

Let’s step back a moment.

We all have a tendency to look at projects as totally linear processes.  Everyone  agrees up front what needs to be done,  money is allotted, a timeline is set and everyone is off to the races.  The project moves into execution mode – efficient execution.

But, we also know that projects aren’t linear phenomena.  They’re a combination of fits and starts, looping back, problems and solutions.

So what happens?

When we first embark on projects, we keep our fingers crossed and hope that nothing gets in the way of launching the product  – that there is no Scope Creep.  As the project progresses we continue with the same mentality, constantly moving forward but at the same time looking over our shoulders, trying to anticipate what might occur before it does.   We hope nothing will knock us off our tenacious trek towards launch – especially no new product requirements.   Nevertheless, these new requirements seem to come and wreak havoc. 

But, there is a bright side.  

Scope Creep is more than something that should be avoided and/or grudgingly dealt with because where there is Scope Creep, there are opportunities to Read the rest of this entry »

Posted in Authenticity, Creative Environments, culture of innovation, Customer Focus, Design, design thinking, innovation, Nature of Creativity, Project Management, stress, Tactics, Team-Building, Workplace Creativity | Tagged: , , , , , , , , | 2 Comments »

Lessons in Design Process from the Egyptian Pyramids

Posted by Plish on October 26, 2009

Since the ancient Egyptians didn’t technically document their design process, I decided to do some reading and tease out the process that they used to design and construct the pyramids.  What I came up with is diagrammed below.  

pyramiddesign michaelplishka2009

Click to See Full Size

Their overarching concern was obvious: build a suitable eternal home for their ruler in a limited time

These constraints (italicized in the above sentence) bounded their design/build process.  If we agree with video game developer, Dino Dini, that the definition of a design process is, ‘the management of (negotiable and non-negotiable) constraints,” then in fact the Egyptians were indeed using a design process as they were accutely active in managing some very basic constraints:

1.  Materials

2.  Workers

3.  Guiding Perspectives on the Afterlife (Providing for the needs of the dead)

4.  Manufacturing/Construction/Artistic Techniques (Technology + Art)

5.  Time

Of the above 5 constraints,  two constraints  were non-negotiable: ‘Guiding Perspectives on the Afterlife’ and ‘Time’.

Their Perspectives on the Afterlife dictated what must be contained in the tomb from foodstuffs to boats, to how the tomb was constructed. 

Time, or rather, time to the death of the ruler, was a powerful, non-negotiable constraint.  The structure basically had to be completed in time for the entombment.

These two constraints impacted the other three constraints as is clear from the archeological record.   The materials used, the technologies chosen for building aspects of the tomb, the abandonment of various aspects of the tomb and focus on other areas, the use of more or less workers, the change in architectural layout during the course of construction, all these were done in response to the non-negotiable constraints.

While managing these constraints they were basically following the User Centered Design process as spelled out in ISO 13407 and summarized below:

Courtesy of devx.com

Only they were doing it over 5000 years ago…

Posted in creativity, Design, Funding Innovation, imagination, invention, Life Stages, problem solving, The Human Person | Tagged: , , , , | 1 Comment »

 
%d bloggers like this: