3 ms·

The author presents a strawman version of UCD and then tears it down but there is one important point in the article: UCD really hasn't fully come to grips with

The author presents a strawman version of UCD and then tears it down but there is one important point in the article: UCD really hasn't fully come to grips with the new era of web applications. Everything taught in schools about UCD leads up to the final prototyping stage but there's very little discussion about how UCD applies after a product is launched. A large part of this has to do with much of UCD research and literature being driven by academia. There's a whole host of amazing UCD stuff you can do with a live web app: A/B testing, polling, behavior tracking, logging etc. However, academics typically don't have access to applications being used by real users & companies are focused more on being effective than documenting their practices so there's a disconnect. Some of the most interesting research coming out of UCD right now comes from PhD students in HCI doing summer internships at places like facebook, Google & Yahoo. They have access to interesting sources of data yet are concerned more for scientific validity than effectiveness so they're asking different questions about it.

ThomPete 17y ago
Where is the strawman? The wikipedia version? Or the way I say it's applied? The very thing that you point out as being relevant is my point exactly. That UCD should test on customers not users in a real environment. I am not against any of the mentioned A/B testing, polling, behavior tracking, logging etc. those are the very things I would wish more would do. The problem is that I am of course stepping on a lot of peoples toes that do exactly what I am after. And there are more than you would think. That is least what my 14 years of working with hundreds of clients have shown me.
- shalmanese 17y ago
  The straw man is the "typical UCD process" diagram you put up. UCD doesn't just lump all of implementation into a black box like you imply. There's nothing in the UCD process that precludes testing on real customers. But the point of using UCD before testing on real customers is that it's a far cheaper way to provide basic realignment. Can I ask if you've ever done a paper prototyping exercise before? I've lead paper prototyping sessions both in classroom & commercial settings and it's common to find people who question their value before it's performed but rare to find anyone after they've experienced it. Often, paper prototyping sessions lead to a drastic reworking of the interface because the originally designed interface is practically unusable. It's far cheaper to get this feedback on paper than on final implementation, even as the cost of implementation continues to fall.
  - ThomPete 17y ago
    I have done paper prototyping and any other possible permutation you can imagine of prototypes including developing fully fledged prototypes. Again what metrics are you setting your "drastic reworking" up against? How do you know that it needs reworking just because you have found issues in a paper-prototype? Issues that might be addressed in the visual phase or in the final phase. That is if anything the strawman IMHO. You are solving the very problems that is created by it being a paper prototype instead of the final product.
    - pbhjpbhj 17y ago
      If the product is a website and the client decides at paper prototype stage they want 3 colums not 2, or they want a right-hand menu or a top-hand (!) search box then no amount of polish is suddenly going to add those things if they client doesn't tell you so they can be put in the design. Also producing fully finished designs for choosing between - aren't you completely ignoring economic reality there?
      - ThomPete 17y ago
        I don't want to sound rude but have you read the post? I think I answer that.
- potatolicious 17y ago
  I found the initial example to be invalid, especially having worked in "physical" industries (auto parts manufacturing, to be precise). The four choices are presented as if they are mutually exclusive - they are not - and are in fact quite often used together. Options 1 through 3 are incredibly useful for early prototyping in order to whittle down a large set of potential solutions. Certainly every design process I've ever been a part of has also gone through option 4. To present these choices as if people are blindly walking down paths 1-3 and only them, is IMHO the straw man. tl;dr version: The article brings up the classic "look what dumb people are doing!" example, but yet I don't see people doing these dumb things that are supposedly being done.
  - ThomPete 17y ago
    So let me see if I understand. You are taking in users and have them look at drawings of your products? I am not saying you shouldn't do 1-3 I am saying you shouldn't test 1-3 on users. You should test 4
    - pbhjpbhj 17y ago
      So basically you think hammer manufacturers should do all the design and testing in the dark, then finalise drawings, design and produce production processes and machinery and tool up a factory, forge hammers ... and then show them to the buyer for the first time. Buyer: "we wanted ball-pein hammers not claw hammers perhaps you could show us a product drawing next time"
      - ThomPete 17y ago
        You are confusing what kind of product the customers want with testing a product you have decided to try and make. In so far as producing the first hammer yes they should do it in dark. That have nothing to do with whether they should research if there is even market for it. But it is not done by asking the users to look at a paper prototype of the hammer.

ThomPete 17y ago

Where is the strawman? The wikipedia version? Or the way I say it's applied? The very thing that you point out as being relevant is my point exactly. That UCD should test on customers not users in a real environment. I am not against any of the mentioned A/B testing, polling, behavior tracking, logging etc. those are the very things I would wish more would do. The problem is that I am of course stepping on a lot of peoples toes that do exactly what I am after. And there are more than you would think. That is least what my 14 years of working with hundreds of clients have shown me.

shalmanese 17y ago
The straw man is the "typical UCD process" diagram you put up. UCD doesn't just lump all of implementation into a black box like you imply. There's nothing in the UCD process that precludes testing on real customers. But the point of using UCD before testing on real customers is that it's a far cheaper way to provide basic realignment. Can I ask if you've ever done a paper prototyping exercise before? I've lead paper prototyping sessions both in classroom & commercial settings and it's common to find people who question their value before it's performed but rare to find anyone after they've experienced it. Often, paper prototyping sessions lead to a drastic reworking of the interface because the originally designed interface is practically unusable. It's far cheaper to get this feedback on paper than on final implementation, even as the cost of implementation continues to fall.
- ThomPete 17y ago
  I have done paper prototyping and any other possible permutation you can imagine of prototypes including developing fully fledged prototypes. Again what metrics are you setting your "drastic reworking" up against? How do you know that it needs reworking just because you have found issues in a paper-prototype? Issues that might be addressed in the visual phase or in the final phase. That is if anything the strawman IMHO. You are solving the very problems that is created by it being a paper prototype instead of the final product.
  - pbhjpbhj 17y ago
    If the product is a website and the client decides at paper prototype stage they want 3 colums not 2, or they want a right-hand menu or a top-hand (!) search box then no amount of polish is suddenly going to add those things if they client doesn't tell you so they can be put in the design. Also producing fully finished designs for choosing between - aren't you completely ignoring economic reality there?
    - ThomPete 17y ago
      I don't want to sound rude but have you read the post? I think I answer that.
potatolicious 17y ago
I found the initial example to be invalid, especially having worked in "physical" industries (auto parts manufacturing, to be precise). The four choices are presented as if they are mutually exclusive - they are not - and are in fact quite often used together. Options 1 through 3 are incredibly useful for early prototyping in order to whittle down a large set of potential solutions. Certainly every design process I've ever been a part of has also gone through option 4. To present these choices as if people are blindly walking down paths 1-3 and only them, is IMHO the straw man. tl;dr version: The article brings up the classic "look what dumb people are doing!" example, but yet I don't see people doing these dumb things that are supposedly being done.
- ThomPete 17y ago
  So let me see if I understand. You are taking in users and have them look at drawings of your products? I am not saying you shouldn't do 1-3 I am saying you shouldn't test 1-3 on users. You should test 4
  - pbhjpbhj 17y ago
    So basically you think hammer manufacturers should do all the design and testing in the dark, then finalise drawings, design and produce production processes and machinery and tool up a factory, forge hammers ... and then show them to the buyer for the first time. Buyer: "we wanted ball-pein hammers not claw hammers perhaps you could show us a product drawing next time"
    - ThomPete 17y ago
      You are confusing what kind of product the customers want with testing a product you have decided to try and make. In so far as producing the first hammer yes they should do it in dark. That have nothing to do with whether they should research if there is even market for it. But it is not done by asking the users to look at a paper prototype of the hammer.