datasheets.com EBN.com EDN.com EETimes.com Embedded.com PlanetAnalog.com TechOnline.com  
Events
UBM Tech
UBM Tech

Design Article

Comment


Thinking_J

2/12/2013 3:52 PM EST

Old methods/assumptions.. we need to question.. right.
In keeping with this ...

More...



zkarim

2/12/2013 1:54 PM EST

That is the reason I use my children. They have this incredible ability to ...

More...

I have a screen ... now what?

Steve Tengler

2/1/2013 2:59 PM EST

Having just concluded the holiday season, I am sure many of you are vegetating on a comfortable couch and reflecting back upon the highly efficient process by which you selected and assembled the presents you gave. The vast majority of you probably selected a cardboard box first that met your budget, and then narrowed your shopping options based upon what would fit inside that magical box. Right? No?? Of course not. That behavior seems so ludicrous that your family might consider medical intervention.

Figure 1: Selecting the wrong hardware up front will cost you more than a few pennies.

Yet, this analogy closely matches the process of ~90% of corporations that have awoken to the explosion of touchscreens in the market and are seeking to define their product's user experience via embedded hardware. They pick the hardware based upon a budget driven by corporate goals, and then figure out what features may be added or (more likely) subtracted to fit within the capabilities of that processor, display, voice engine, etc. To delve into this further, let's go through three fallacies that most product owners believe, and then talk about the solution.

The Nebulous Marketplace
Probably the #1 mistake made amongst these sophomoric managers is to fix a Bill of Materials up front, but it's a well-baited bear trap. Why?

The typical program starts out like this: Marketing says "I need the next ground-breaking, eye-popping, brain-melting widget that'll include this laundry list of 'features' that'll make us competitive, and the market says the target price should be approximately $X." So the well-intentioned engineer looks at the required ingredients to provide those features, does a thumb-to-the-wind estimate on the parts and services that'll stay under the cost ceiling, creates a Request for Quote (RFQ), and sources the suppliers based upon a Statement of Work.

So here's the problem: the product's price is based upon demand (Econ 101, folks ... I'm not making this up), and the demand is based upon how well the consumers' needs are met. But the consumer has never seen a ground-breaking, eye-popping, brain-melting widget, so the price point is truly unknown.

If Henry Ford had created his allowable budget on a faster horse, the automobile would never have been and we'd be using an enhanced grain or a bioengineered, docile cheetah. If Steve Jobs had concocted the iPhone based upon previous cell phones, we'd still be using not-so-smart phones (*my apologies to flip phone owners reading this article).

In addition, some companies set this allowable budget three to five years before their product (e.g., automotive, aerospace). Considering local and global economies change daily, this can drastically affect the long-term success of a project. For instance, a friend of mine started a travel product using the aforementioned flawed process only to emerge in the post-911 travel-economy years later. Nobody wanted to fly, and thus the product was tragically over-designed for the now-reduced travel market.

Hence, the nebulous marketplace should not prognosticate in cement a customer demand or engineering budget at the start of the project.

Featuring the Features
Many parents consider the f-word to be ... well ... you know. Personally, I consider "features" to be the f-word. If I had a dime for every time a marketing person said, "Our rivals have these features, so we must include them to be competitive," I'd be golfing in Florida right now.

Why does that singular word evoke such extreme emotional responses? Features are typically divorced from the future (or current!) consumer, and are the lazy/cheap man's market research.

For instance, at the publishing of this article, I can say with high confidence that all toasters have a mechanical lever that positions the desired food and engages the heating element. Does that mean all future toasters must have the lever feature?

What if I could say "toast bagels" into my phone as I'm rising from bed (or driving home ... hands-free, of course), and, akin to the automatic icemaker, the refrigerator downstairs spits out my warm breakfast minutes later? How much would you pay for that?! If the marketer assumed upfront that a mechanical lever was a must-have feature, that breakthrough implementation would never be considered.





Battar

2/6/2013 2:08 AM EST

The most common mistake I've encountered is engineers and managers who assume that they are the average user. They can't get their heads around the fact that they are way smarter than the average user/customer, that they must assume that at least half the customers will not read the manual ("but is says in the manual to press the button..."), and that given more than one button to press someone will press the wrong one.

Sign in to Reply



tenglers

2/6/2013 3:45 PM EST

Battar -- No doubt. That's called False Consensus Effect or False Consensus Syndrome. I jokingly say to my students that many an engineer or manager has said, "I'm human. I factor. Therefore, I can do Human Factors." In my article entitled "Five User Experience Lessons from Johnny Depp" (see http://uxmag.com/articles/five-user-experience-lessons-from-johnny-depp), I explain that one lesson is a design must be for the user, not the designer who believes [s]he factors. Again, though, the only way to achieve that is to prototype it, test it, tweak it, and then produce it. If corporations start to understand that, we'll have fewer frustrations in the world. :)

Sign in to Reply



Battar

2/7/2013 6:51 AM EST

One trick I was taught and tried in the real world: I showed the graphic layout of the user interface to my wife and asked her if she understood, intuitively, how to operate it. When she said no, I realized we needed a design review. Of course, this won't work if you are married to Helen Greiner or Heather Knight.

Sign in to Reply



tenglers

2/11/2013 1:57 PM EST

I recommend against using loved ones as test subjects. Your wife may be blunt and forthright with her opinion, but many loved ones hold back true feelings since they want to appear supportive. If they saw a design and thought it was the worst thing they've ever seen, they are likely to withhold a portion of that opinion.

Sign in to Reply



zkarim

2/12/2013 1:54 PM EST

That is the reason I use my children. They have this incredible ability to express their inhibition-free opinions to me :).

Sign in to Reply



rich.pell

2/7/2013 2:01 PM EST

Here's a working version of the link given above ("Five user experience lessons from Johnny Depp"):

http://uxmag.com/articles/five-user-experience-lessons-from-johnny-depp

(Links in comments need to have spaces on either side so the system can tell where they begin and end.)

Sign in to Reply



Thinking_J

2/12/2013 3:52 PM EST

Old methods/assumptions.. we need to question.. right.
In keeping with this line of thought....

Why is everyone assuming the product being designed isn't intended for a engineer?
Indeed, why assume the product isn't intended to be a product volume of one?
By the engineer , for the engineer ("engineering team" of one, product for his/her self)
Generalities about engineering/management/design.... need to be better qualified (constrained).

Why is the development process (hardware/software/testing) being described assumed to be longer than 1 week (or 1 day)? The world is changing faster and faster... Tools and processes continue to reduce to time for delivery of a product. If you want to take improvements to the next level.... expect to produce at the next level. Using COTS for preliminary development is fine, but in the right environment (tools/people/resources) I find I can design/build/produce a custom solution (1-2 weeks), just as fast (faster?) than ordering an "off the shelf" development board and hand cobbling together the remaining pieces of a system. Same is true for simulations.. sometimes faster (and more informative) to create hardware and software than to create simulations of a product for review process.
Simply: don't limit yourself to one tool set... it limits your solutions.

Truly big , complex products.. are best developed with an evolutionary process in mind.
No individual or company can project the future with any accuracy... Even if they know the end user very very well.
Best to implement a re-iterative process , and optimize the heck out of it!

That is the point trying to be made by Steve (I think).

Sign in to Reply



Please sign in to post comment

Navigate to related information

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)