3

I'm reading The Inmates are Running the Asylum, 1998, by Alan Cooper. And I get a lot out of it.

In chapter 9 there is a section, The Elastic User. It is about when developers/designers make design choices where they expect the user to adapt / fit in with any design choice they make, but assuming wrongly that the user does fit in.

In particular it is about, for the same piece of software, having very different designs for various parts of the software, and assuming that one given user can fit all of these. Cooper writes as below:

Programmers have written countless programs for this mythical elastic consumer, but he simply doesn't exist. When the programmer finds it convenient to dump the user into the Windows file system to find the information she needs, he defines the elastic user as an accommodating, computer literate power user. other times, when the programmer finds it convenient to step the user through a difficult process with a mindless wizard, he defines the elastic user as an obliging, naive, first-time user. Designing for the elastic user gives the developer license to code as he pleases while paying lip service to "the user". Real users are not elastic.

I would like a real life example of this. Perhaps some Windows functionality, or: Adobe, Word, network manager, etc.

Can anyone think of such an example.

  • rightfully, I see elastic user as a license to code. It is the escape route for the developer at times. In fact it can also be a reason given to exposing certain functionalities which need to be exposed but were never intended to be exposed willingly. Like Task Managers, Windows Registry. Windows will set up your desktop for the first time by a slow mindless wizard but leave you dumbstruck at the entrance of Windows Registry and ask you to figure stuff out yourself. – Harshal Aug 12 '15 at 7:11
2

Stretching reality for Dev's convenience

Alan Cooper wrote about the elastic user again, in his book, About Face. The elastic user is a self-serving creation of development teams, and has little to do with the goals, abilities, and contexts of real users.

enter image description here

From Chapter 3, page 65, of the 4th edition of About Face, Cooper describes a development team making a particular product:

If the product-development team finds it convenient to use a confusing tree control containing nested folders to provide access to information, they might define the user as a computer-literate "power user." Other times, when it is more convenient to step through a difficult process with a wizard, they define the user as an unsophisticated first-time user. Designing for the elastic user gives a product team license to build what it pleases, while still apparently serving "the user." Of course, our goal should be to design products that appropriately meet the needs of real users. Teal users—and the personas representing them—are not elastic, but instead have specific requirements based on their goals, abilities, and contexts.

Does the first half of this quote provide the example you seek? It's not "real life" but it is from the horse's mouth.

  • Thanks for posting from About Face. His writing is slightly different there, compared to "Inmates (...)", with an emphasis on how developers "pretend" or "fool themselves" into believing that they have designed for the user, when what they have done is defined the user or imagined the user to fit into the design that they already built og already imagined building. Do you agree with my summary/conclusion of his text? – Mads Skjern Aug 12 '15 at 8:48
  • However no, your answer, though useful for me, does not answer what I am looking for. I am looking for a very specific case of this, in a published real life piece of software. So that I can actually open a piece of software and see "Wow, this Adobe Doobedoo Suite wizard is for the retarded, and this step in the wizard is for a syadmin". Or less extreme :) – Mads Skjern Aug 12 '15 at 8:52
0

I don't accept his premise that these features are the result of conscious & thought-out design decisions.

An example of the type of feature he talks about might be a well designed form, that has been handed over to the development team by an IA. It's been thought about, discussed, and maybe even user tested. However when a user gets an error, it may say something like 'Too many parameters'.

This happens a lot, and it is almost always because there is a lack of detail in the handover process between the requirements/design team and the development/test team. Nobody has bothered to specify errors, so the programmer just writes something in, because they have a deadline to hit. The testers pass it because there's nothing documented that says it's wrong.

Result: A really good user experience if you fill in the form correctly first time. A really poor user experience if you get something wrong.

It's not about elastic users, it's about attention to detail in the software development process.

  • 2
    They are not the result of couscious and thought-out design decisions. They are the result of: Every time there is a design decision the developer thinks "I like this advanced solution, with lots of customization for the user", and then imagines the user interacting with it, and imagines a literate user doing so. In another situation he thinks "I like this supersimple wizard, so simple and nice, even my grandmom could use it, though it may not be as customizable as some would like". He forgets that in one case he is thinking of a sysadmin, and in the other case he is thinking of his grandmom. – Mads Skjern Aug 12 '15 at 11:08
  • He makes up, in his mind, a user, for each design decision he is considering. He forgets to think that the user of one feature is the same user as for another feature. This is probably only true for developers / coders (like my self) and not for people working specifically with design. – Mads Skjern Aug 12 '15 at 11:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.