1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Human factors in design

Discussion in 'Embedded' started by Don Y, Oct 15, 2011.

  1. Don Y

    Don Y Guest

    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! :<

    <rant>
    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!]
    </rant>

    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
     
    Don Y, Oct 15, 2011
    #1
    1. Advertisements

  2. Don Y wrote:

    [%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...............<email://>
    Forth based HIDECS Consultancy
    Mob: +44 (0)7811-639972
    Tel: +44 (0)1235-510979
    Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
    ********************************************************************
     
    Paul E. Bennett, Oct 15, 2011
    #2
    1. Advertisements

  3. Don Y

    Don Y Guest

    Hi Paul,

    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.
     
    Don Y, Oct 15, 2011
    #3
  4. .... 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.
     
    Hans-Bernhard Bröker, Oct 16, 2011
    #4
  5. 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
     
    George Neuner, Oct 16, 2011
    #5
  6. Don Y

    Don Y Guest

    Hi Hans-Bernhard,

    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...
     
    Don Y, Oct 16, 2011
    #6
  7. Don Y

    Don Y Guest

    Hi George,

    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.
     
    Don Y, Oct 16, 2011
    #7
  8. 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...............<email://>
    Forth based HIDECS Consultancy
    Mob: +44 (0)7811-639972
    Tel: +44 (0)1235-510979
    Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
    ********************************************************************
     
    Paul E. Bennett, Oct 16, 2011
    #8
  9. Don Y

    Bruce Varley Guest

    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.
     
    Bruce Varley, Oct 16, 2011
    #9
  10. Don Y

    Don Y Guest

    Hi Bruce,

    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!
     
    Don Y, Oct 16, 2011
    #10
  11. Don Y

    Don Y Guest

    Hi Paul,

    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")
     
    Don Y, Oct 16, 2011
    #11
  12. Don Y

    Bruce Varley Guest

    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.
     
    Bruce Varley, Oct 18, 2011
    #12
  13. Don Y

    Don Y Guest

    Hi Bruce,

    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?
     
    Don Y, Oct 19, 2011
    #13
  14. 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 :cool:

    George
     
    George Neuner, Oct 19, 2011
    #14
  15. Don Y

    Bruce Varley Guest

    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.
     
    Bruce Varley, Oct 19, 2011
    #15
  16. Don Y

    Don Y Guest

    Hi Bruce,

    Understood. In this case, your choice of the word "Personalities"
    is more than appropriate! [Not quite the same beast as "Politics"]
     
    Don Y, Oct 20, 2011
    #16
  17. Don Y

    Don Y Guest

    Hi George,

    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.)
     
    Don Y, Oct 20, 2011
    #17
  18. "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, Oct 21, 2011
    #18
  19. 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 :cool:. 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
     
    George Neuner, Oct 21, 2011
    #19
  20. 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 :cool:

    George
     
    George Neuner, Oct 21, 2011
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.