Human factors in design

Hi,

We've all dealt with them -- products that seemed to have been designed with the only consideration given to the user being the selling price! :<

Today, I'm dealing (again) with this rotary level to mark the location of the ceiling -- probably a common application!

Device has a keyhole slot from which you can hang it on a wall -- since the tripod would never be tall enough to support it from the floor. Of course, the hole lies behind the mechanism so you can't tighten a screw placed *in* that hole. Nor is there a second such hole that you could use to "fix" the device's position AND ORIENTATION -- remember, it's a LEVEL! -- on the wall. As such, it must "hang" from that one point.

This SOUNDS like a good idea -- *if* the device could hang *freely* (so that it always "settled" to a known position). But, since it is against a wall, the drag of the wall discourages it from swinging freely -- you'd have to add a lot of mass to it to get it to overcome that friction.

The on/off/speed potentiometer appears to have drag added to it intentionally! I.e., it requires a fair bit of effort to rotate the dial to "on", "off" or adjust the speed. So, you have to exert some force on the control to effect these changes.

Did I mention that there is no way to *fix* the device's position/orientation on the wall? I.e., each time you dick with it, you change that, subtly.

The spirit levels which are intended to be used to level the device are located on the *top* of the device. So, if you have the top of the device (the "business end") up at the top of the wall, there is no way of seeing the levels (resort to a small mirror held up for that purpose).

Battery powered (exclusively). So, while many job sites don't have "installed power" available, the availability of a genset won't help you when/if the batteries fail. Would a barrel connector for an external power adaptor ("sold separately")) and a blocking diode have been *too* much to include?

Granted, this was a cheap device bought for "two time use". But, the "better" devices seem to suffer from the same design issues.

[I'm tempted to do some surgery on this one when I am done with it -- on the off chance that I need it a *third* time in the future and don't want to rediscover these problems, then!]

So, what's the process for evaluating/specifying user needs in product development at your places? Does anyone actually *talk* to a user before beginning development? Does the project manager, lead programmer, etc. simply take it upon himself to define those characteristics of the device? Is the device unveiled to select users JUST PRIOR TO RELEASE (i.e., when it is too late to make

*real* changes) for feedback?

I've only worked with IE's a couple of times in the past (usually when client had *deep* pockets -- and a "valuable reputation"). OTOH, most of the devices I've been involved with had "reasonable" user interfaces (given the constraints of the technology, packaging, pricing, etc.) so I don't know how "bad ones" come about (though I can *imagine*!)

--don

Reply to
Don Y
Loading thread data ...
[%X]

I have always been fortunate in being able to discuss my devices with the intended end user (or a representative sample of them). In my current position, I am also the end-user for the system (it is a DBO style operation).

--
********************************************************************
Paul E. Bennett...............
 Click to see the full signature
Reply to
Paul E. Bennett

I'm not convinced that users actually *know* what they want. More often, they know what they *don't* want (AFTER they see it).

I have a system that I designed a few years ago for a local non-profit. I spent a couple of *years* watching "The Process" before I proposed my first implementation. I was able to put myself into the user's "shoes" and imagine the types of problems that had to be addressed as well as the aspects of The Process that could be changed once you had "technological leverage".

I then watched *that* implementation to see the problems that I wasn't able to foresee, originally. Likewise, to be able to see new behaviors that users "stumbled onto" based on the capabilities that the technology gave them.

So, the next implementation can leverage those problems/features to refine the design to an even more usable configuration.

OTOH, *asking* those users before my first implementation resulted in incredibly "uninspired" ideas that would have been completely impractical. Too much manual "data entry", etc. for the system to have any long term "legs" (i.e., folks would quickly get tired of having to type in all this "crap" and would abandon the system -- even though it was more effective than their original one!)

I think the trick is trying to see past what the users *claim* they want and thinking about the *real* issues behind those. Then, leveraging your personal knowledge of what is possible with technology to come up with a new/better approach.

Reply to
Don Y

... and once you've made it to that point, you'll still have to convince the marketroids (yours, mainly, but also the customer's) that contrary to common "knowledge", the customer is _not_ always right. Some people absolutely cannot fathom the idea that anybody might know more about the thing they're about to acquire than they do.

Reply to
Hans-Bernhard Bröker

That's why there is such interest in the software world in rapid prototyping. Customers have to see *something* before they can make any kind of useful contribution to the design effort ... even if it's only to say "I don't like that".

George

Reply to
George Neuner

The experiences I've had with "marketing" are all over the map.

Many organizations don't have a *real* "marketing" department. Often, their "sales" department is little more than "order takers". I.e., there is either a lack of this type of expertise

*or* a lack of discipline in applying it.

At the other extreme, there have been organizations where you are

*told* what the product will be. Your "opinion" doesn't really matter.

In the overwhelming middle, it seems like Engineering formally or informally fills this role. Often with the engineer or project manager making decisions on-the-fly.

The first group has been relatively easy to deal with. They don't

*want* to stick their necks out and make those sorts of decisions. They're happy just "taking orders" and "going to trade shows". Some folks might bring hints/recon back from customers and other vendors ("Acme is offering a triple frajistat option on their new devices!").

The second group is also easy to deal with -- you have no choice! :>

The third group seems to represent the bulk of my experiences. Engineering formally or informally making the actual product design decisions AS IF they were fulfilling the Marketing role.

Sometimes, this works well. If you have folks that are intimately familiar with the application domain instead of just trying to push products into it.

I complained to my boss at one of my early jobs that the "membrane keypad" was too "stiff"... you had to *stand* on the buttons to get them to actuate (we were selecting the desired stiffness for the keypad and I obviously thought the decision should go in the opposite direction that it was headed -- I objected to the entire membrane switch concept as well!).

Thankfully, my boss was considerably more cognizant of our market and dismissed my objections. When I eventually found myself in the field with the beta product and *real* users, I understood the wisdom of his choice (though *I*, personally, still found it impossible to actuate the damn buttons!)

I can recall having heated discussions about "phone" vs "calculator" numeric keypad layouts. And, "QWERTY" vs. "alphabetic" layouts. And process flow. etc.

But, I can't ever recall meeting with *real* users/customers (other than "at beta") to discuss these issues. Nor ever formal meetings for the express purpose of deciding these issues.

OTOH, I have met people who routinely are invited to "customer forums" (for firms like big auto makers) so I know *some* folks engage in a more scientific approach...

Reply to
Don Y

But do *real* customers ever see these things? I've always produced "dog-and-pony"s just for internal review (or, for *my* customer/client). Some group of muck-a-mucks poke at it for 10 minutes, make a few nondescript grunts, then walk away acting as if they've just

*saved* a project.

I.e., rarely worth the time expended for the "show". (this was always a common gripe)

Any time (big!) customers were brought in the motive was always to get them thinking about a purchase before the product was actually on the market (perhaps to keep them from buying a competitor's product). But, I don't ever recall any of them actually being

*actively* involved in the design process -- even conceptually.
Reply to
Don Y

Always a necessity. The engineer gathering the requirements needs to be able to put themselves in the end-users shoes to determine what is the best approach.

Looks like you have dealt with the consumer gadgets field. One area I have managed to avoid being in. At least in supporting the Energy, Process and Transport industries you know the client has some clue about what they want.

[%X]

I have always maintained that the Systems Engineer should learn about the clients process before launching into testing the requirements and beginning design. That way, they can appreciate the users point of view and make more relevant proposals.

[%X]
--
********************************************************************
Paul E. Bennett...............
 Click to see the full signature
Reply to
Paul E. Bennett

It's bound to be in part a game, because conflicting human aspirations and power are always amongst the factors involved. Increased involvement of potential users means a greater risk of changes somewhere through the implementation cycle, resulting in possible cost and or schedule growth, something that a stakeholder in those areas will inevitably resist. At the moment I'm designer and implementer, and one of the things that scares me is the possibility that a nice-to-have change that arises might force a major change in my design basis. So even from my viewpoint I can't say I unequivocally welcome too much user input.

There are also countless examples of initiatives that succumb to paralysis through analysis, particularly if there are people that are benefitting from the prevarication. I can see why project managers sometimes resort to a crash through approach. In the end, the way things are done is going to be as much a result of the personalities involved, as any formal procedures.

Reply to
Bruce Varley

Ah, I was thinking in terms of "up front" involvement. Figure out what you are designing *before* you design it! :> I.e., if the feedback you get results in:

- "this is a ridiculous product idea", or

- "you need all these *other* (difficult) capabilities in order for the product to be truly useful", then, you can simply decide *not* to undertake the project.

Injecting user/customer input into a project that is already "significantly pregnant" seems the worst of both worlds -- too late for you to have avoided any Big Mistakes in the concept and too early for you to avoid reworking the existing design.

But why would that happen? Only if your process isn't disciplined enough to *prohibit* changes late in the design. Learn to say, "We'll save that for Model 2"

But, would you have *before* starting the design? Assuming *you* still had The Final Word?

The only potential "winner" I could see is someone who can too readily be tagged with "responsibility" for the design/conceptualization IN AN ENVIRONMENT WHERE SCAPEGOATING IS COMMON.

I've seen folks take the opposite attitude -- put the "kitchen sink" in the design just to cover every imaginable customer requirement or fantasy. This often cripples an implementation -- making it too expensive, buggy, long to develop, etc.

Agreed.

But, you don't seem to hear much about *real* user/customer involvement!

Reply to
Don Y

But, how do you do that without more than a casual familiarity with that application domain? Guesswork??

No, my experiences are varied -- industrial consumers, regulated industries, etc.

But, as you said, when your customer/user is one of these, they tend to know what they want (or, what they can *tolerate* given their existing other criteria/personnel -- it takes a lot longer to turn an elephant than a mouse!) and/or have processes/regulations in place that *dictate* those things.

And, you can usually extract a lot of information about "usage" just by watching (or reading) people *do* those jobs.

Other markets are more fluid. Many users can, for example, adopt new technologies and processes "overnight" -- changing paradigms that "elephants" would take years to embrace.

The "mice" tend to be harder to lump into one classification: "This is how 'they' will use the device".

So, it seems *essential* that you drag in considerably more than *one* such user/customer to get a feel for the range of requirements that they are likely to have and demands that they will place on your product.

Agreed. Thats how I deal with *my* customers/users (clients). In my case, if *that* customer isn't pleased, I'll "feel it".

But I don't see that, in general, as a common practice. It seems to be more ad hoc... hoping to get "the majority" of the design right without introducing too many "mistakes" that can't be overcome or ignored.

(Or, worse, putting lots of "configuration options" into the design and leaving it to the user to "fix")

Reply to
Don Y

My professional life would be a lot easier if I could simply design and build to a spec and deliver on that basis alone. But things aren't like that when you're in a close, ongoing alliance relationship with a client. You're part of a much bigger picture, sometimes people will consider themselves able to push the boundaries of what's been previously agreed, and sometimes I need to go with that 'for the greater good'. As I said, it's all about personalities.

Reply to
Bruce Varley

Yup. Clients are a special case... "a customer of ONE". Harder to keep them out of the kitchen while you're baking. :< I tend to keep (considerable) physical distance between myself and clients; it helps cut down on the "touchy-feely" interaction. Dog-and-pony's tend to be far less frequent and, as such, the stakes for "changes" much higher -- and much more obvious!

(If you've spent months building an infrastructure for a particular implementation but haven't "hung much fabric on it", it's too easy for people to think there's not much that will be consequential to "little changes". OTOH, when they see something that *looks* very close to "done", self-discipline seems easier to come by: "We'll put that on the wish list for the next version...")

Understood.

My real concern is for *end* user input. I.e., your client's customers. Does *he* drag them into the (*his*) process? And, if so, when and how?

Reply to
Don Y

In my experience they do, but I'll concede that my experience may be atypical. I've worked a lot in industrial QA/QC vision applications where the usability of the software mattered greatly to productivity.

It's always necessary to impress the executives because, ultimately, they will be the ones who pay the bill. But I think too many developers of industrial applications start to think of the executives as the customers.

I had a few cases where a sale involved heavy customization of an existing system. But some of those customizations were deemed useful enough that they (or a more general derivative) found their way back into the general product.

Most sales involved adapting the software to play with the local factory automation system - it seemed like everyone used a different protocol or a different database and wanted data presented in their local format. Fortunately all the external interfaces were modular ... occasionally a new module was necessary.

Most of the UI - layouts, fonts, colors, messages, etc. - was designed configurable from the beginning ... so a great amount of site "customization" really was editing setup files 8-)

George

Reply to
George Neuner

No, you've put your finger on a significant factor. Unions are involved, rollout to the troops has to be handled carefully for reasons that people at my level may not be aware of. And once they are involved, I'm unlikely to be involved with the deals that are being done in the background.

Reply to
Bruce Varley

Understood. In this case, your choice of the word "Personalities" is more than appropriate! [Not quite the same beast as "Politics"]

Reply to
Don Y

So, *how* is it presented to them? I.e., are a "select few" invited to play with it? Or, called in for a brainstorming session? (I'm sure you don't have *every* potential user "vote" on the approach...)

My experience has typically been brute force and/or "inspired" thinking about how the device will be used. It's only successful if the folks involved are actually acting on the customer's behalf and not serving their own self interests (e.g., sales droids trying to get every imaginable feature shoehorned in just so they don't have to *justify* -- to the customer -- why a particular option was NOT supported).

But that's the point -- it's the *customers* who pay the bill! Not the PHB's! They might control the *purse* but the customer actually *fills* that purse.

So, it's the *customer* that you really want to cater to -- not the PHB or bean counters. I just don't see them dragged into most design decisions -- even by proxy.

(I suspect this is different for truly *large* vendors... where they can afford focus groups, clandestine alpha releases, etc.)

Reply to
Don Y

"Programming from specs is like walking on water... it's easier to do when it's frozen."

( Found this and a few variations, attributed to both Alan Perlis and Edward Berard )

-- Roberto Waltman

[ Please reply to the group, return address is invalid ]
Reply to
Roberto Waltman

The company I worked for sold through different channels: we were an OEM for vendors of production equipment that wanted to offer integrated QC/QA, and we also designed one-off systems and special adaptations of the OEM systems for direct customers.

A new OEM system generally started with the manufacturer inviting us to see the equipment and give us some initial ideas based on requests made by its customers. Then they would arrange for us to visit some of their major customers to see the equipment in operation and talk to QA engineers about their needs. This would also give us a peek at any competing systems that might already be in use so we could get an idea of what they didn't like. Wherever possible, we would get samples from their production runs: both good ones and bad ones that displayed faults they wanted to catch.

We then would go home and start prototyping. QC/QA systems always are attached to a conveyance of some kind positioned between or after production steps. So with the manufacturer's assistance, we would set up a simulation of the conveyance and its control system in our lab. We'd work with the manufacturer to figure out where and how our cameras, lights, computer and touchscreen control panel could be mounted. As soon as the became functional, we would start to test it on real equipment at the manufacturer.

As the system started to take shape, we would solicit feedback from the customers we had spoken to. We would send them working software[*] with simulated control signals and camera inputs ... using imagery of their own parts where possible. As each new major function came online we would send them a new version to play with. We would try to accommodate everyone's UI and function suggestions as best we could though configuration options.

The simulation mode and the ability to capture live imagery for it remained in the final version of the software. This allowed customers to set up their own offline training and also let them send us real imagery of problem parts for analysis if something wasn't working to their satisfaction.

[*] Back before there were fast SIMD CPUs, we had to supply whole computers containing dedicated image processing hardware. Once there were desktops available that could run the software acceptably for demo purposes, we only needed to supply the touchscreen so they could work with the actual interface. [Try telling FedEx or UPS you want to insure a breadbox sized computer for $20K. Better yet, try collecting when they lose it or break it (which happened a few times).] The dedicated hardware was a problem. We knew that customers would only pay for what they needed - which depended on the speed of their lines - so the software had to be designed to run on the minimum necessary hardware set and to use any additional hardware sets it found for acceleration. We sent out the evaluation computers with a single hardware set. If the company subsequently bought the system, we let them keep the eval computer for training and as a temporary source of parts if a production system broke. If they didn't buy the system, we took back the computer and loaned it to somebody else who was interested.

Adaptations usually were simple: a typical request would be to make an existing system work with a different conveyance or tie it into a factory automation system. These typically didn't require a whole lot of customer input ... just the LAN protocol and data formats they needed for their FAS. If the request was for a new conveyance, we had to visit them to determine how (or if) the components could be mounted and work up specs on the signal interface. [We always retained rights to support new protocols in our general system ... and, of course, we retained knowledge of new conveyances for if we encountered them again. The customer's proprietary FA data formats were their own and we provided them with the source for the module that handled that.]

Custom jobs proceeded in much the same way as OEM jobs. Someone would see a system at a trade show or in use somewhere and want something similar. Sometimes we could salvage the UI from an existing system and place new algorithms underneath ... sometimes it was a scratch effort. In either case, we went it about it in the same way with the exception that we had to perform most testing on the line at the customer site (usually in the middle of the night 8-). Whether such a customer received source to anything was negotiated.

See, I never dealt with sales droids ... only with QA engineers and working line managers. The sales force would relay comments from trade show visitors, and in the case of OEM systems we would hear back what potential customers of the integrated system had to say about it. But we were not working to please our sales force ... we were working to please the equipment vendor that was integrating the system or the direct customer that was paying for special development.

Executives of the end-user companies always wanted to see the system work, but generally always deferred to the opinions of the engineers and managers who would actually be using it. The higher ups were more interested in price/performance ratio than in how it worked.

The executives sign the checks and thereby pay *your* bills. So you do what is necessary to make them happy.

Bean counters are a very important customer segment. They are the ones that provide price/performance support for an executive to justify a purchase.

And they don't ever care what a system looks like or how it operates. Bean counters only care how much it costs and how using it will impact production.

George

Reply to
George Neuner

Nice if/when it happens. I once worked on software for an imaging system that was being developed under contract. At the first meeting the customer's project manager presented our development team with a functional specification that, somewhat amazingly, turned out to be nearly complete ... there were no changes and only a couple of minor additions made during development.

Of course, the system's UI changed every time they held a meeting. But you can't have everything 8-)

George

Reply to
George Neuner

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.