Psy­chol­ogy in de­sign

Rune Nørager asks why hu­man psy­chol­ogy is miss­ing in the process of user-cen­tred de­sign

net magazine - - CONTENTS - Illustration by Ben Moun­sey

Rune Nørager con­sid­ers why psy­chol­ogy is ab­sent from our de­sign process

You are prob­a­bly fa­mil­iar with the con­cept of user-cen­tred de­sign (UCD). There are many vari­a­tions, but the ba­sic el­e­ments look like this: Ex­plore > De­sign > Test/Iter­ate/Re­fine > De­ploy UCD is an in­valu­able tool that helps us un­cover un­met user needs and turn these into new de­sign so­lu­tions. How­ever, un­fold­ing UCD as it is used by prac­ti­tion­ers re­veals a strik­ing pat­tern: science-based knowl­edge of hu­man be­hav­iour is vague, if not miss­ing al­to­gether.

In­stead, the pri­mary fo­cus is on how we can gather in­for­ma­tion about user needs in the de­sign process and then, in it­er­a­tive user test­ing loops, re­fine the de­sign con­cepts un­til they are ready for de­ploy­ment. Is essence, the hu­man part of tech­no­log­i­cal de­vel­op­ment is pretty much a black box.


I find it use­ful to an­a­lyt­i­cally dif­fer­en­ti­ate be­tween a user- and a hu­man-cen­tred de­sign (HCD) ap­proach to prod­uct de­vel­op­ment. UCD is what I call a process-based dis­ci­pline, rooted in an­thro­po­log­i­cal and ethno­graphic method­ol­ogy. HCD is an ex­pert-based dis­ci­pline rooted in knowl­edge of hu­man psy­chol­ogy.

This dis­tinc­tion is not ab­so­lute, but it helps com­mu­ni­cate a crit­i­cal point: UCD does not di­rectly utilise the vast amount of knowl­edge we have ac­cu­mu­lated about hu­mans; knowl­edge that could have a big im­pact on de­sign so­lu­tions and pro­vide a foun­da­tion for in­no­va­tion.

To give an ex­am­ple of an area where HCD could im­pact on de­sign: One of the most pow­er­ful memory mech­a­nisms we have is memory for location in a spa­tial lay­out. De­vel­op­ments like re­spon­sive GUIs, de­spite de­liv­er­ing won­der­ful new fea­tures, cut off this mech­a­nism.

For some UCD prac­ti­tion­ers, the hu­man side is ad­dressed im­plic­itly through their gen­eral knowl­edge. How­ever, we need this as­pect to be more ex­plic­itly present. With­out for­mal HCD knowl­edge present in the de­vel­op­ment process, we can only ad­dress the hu­man side through the test-iter­ate loop. This is too un­cer­tain, and valu­able in­sights about hu­mans are cer­tain to be over­looked and lost.

Thus, of­ten teams will fit prod­ucts to ‘the user’ rather than to hu­mans, which means we end up with prod­ucts that gen­er­ate friction in daily use and bur­den users un­nec­es­sar­ily. Fur­ther­more, great so­lu­tions are only ex­plored by chance and in­tu­ition, rather than di­rectly guided by knowl­edge.

Miss­ing in­sights

So why is the hu­man side so un­der­rep­re­sented in prod­uct de­vel­op­ment? In my ex­pe­ri­ence, it has to do with the in­abil­ity of psy­chol­ogy to de­liver con­crete an­swers in a prag­matic fash­ion. UCD has a host of re­ally use­ful tools that help gather, struc­ture and present user in­sights. HCD has lit­tle to of­fer apart from a hand­ful of rel­a­tively ab­stract de­sign heuris­tics that of­ten don’t con­nect with the is­sue at hand – or are so spe­cific that they have limited ap­pli­ca­bil­ity. The scope of heuris­tics

may be too nar­row and the gulf be­tween psy­cho­log­i­cal the­ory and prac­ti­cal use too big. For­tu­nately, over re­cent years this gulf has started to dis­ap­pear.

A new par­a­digm

Cog­ni­tive psy­chol­ogy has un­der­gone a rev­o­lu­tion in the past 30 years, and a new the­o­ret­i­cal par­a­digm has emerged. Rather than fo­cus on the most in­tel­lec­tual learnings (and their lim­i­ta­tions) we now have an elab­o­rate un­der­stand­ing of the ba­sic cog­ni­tive skills that form the ba­sis of ev­ery­day be­hav­iour. From this shift has emerged a more con­sis­tent view of hu­man be­hav­iour that can be in­te­grated into the de­sign heuris­tics we al­ready use, as well as pro­vid­ing new guide­lines to ex­tend and sup­ple­ment UCD.

You may have read Think­ing Fast and Slow by Daniel Kah­ne­mann. The book in­tro­duces the dual-process the­ory that ba­si­cally states that peo­ple have two kinds of men­tal re­sources that un­der­lie our be­hav­iour: A ba­sic Sys­tem 1 and an ad­vanced, in­tel­lec­tual Sys­tem 2.

UCD is suited to tap­ping into the higher-level Sys­tem 2 be­havioural func­tions, where we ex­plore what peo­ple ver­bally re­port about their con­scious thoughts and needs. HCD is geared to­wards help­ing us un­der­stand what goes on down in the Sys­tem 1 en­gine room of our be­havioural thought pro­cesses.

Sys­tem 1 is im­mensely de­sir­able from a de­sign per­spec­tive – tech­nol­ogy be­comes truly in­tu­itive when it fits Sys­tem 1. Fur­ther­more, when it comes to Sys­tem 1, all hu­mans are the same, re­gard­less of age, cul­ture or lan­guage. In essence we can make univer­sal de­sign when we con­sider Sys­tem 1.

In prac­tice

A favourite test of mine is the squint test. In this, the tester looks at a de­sign through squinted eyes to re­veal the macrostruc­tures as they ap­pear in our pe­riph­eral vi­sion (which is ac­tu­ally 96-98 per cent of our vis­ual field). Pe­riph­eral vi­sion taps into Sys­tem 1, whereas fo­cal vi­sion taps into Sys­tem 2. Pe­riph­eral vi­sion can­not ap­pre­ci­ate fine de­tails of text, icons and sym­bols; only rel­a­tively coarse struc­tures.

The nat­u­ral world has both, and as we ca­su­ally nav­i­gate around in it we rarely need fo­cal vi­sion – only the oc­ca­sional road sign or bus num­ber might re­quire a bit of fo­cus. In GUIs, how­ever, there is a huge bias to­wards con­tent and mean­ing only be­ing con­veyed with fine, high-res­o­lu­tion de­tails. The macrostruc­tures present tend to be more re­lated to styling than func­tion.

Con­tem­po­rary GUIs of­ten do not pro­vide sup­port for pe­riph­eral vi­sion – if you squint, you see few mean­ing­ful macrostruc­tures. Only by con­scious, fo­cused in­spec­tion of the GUI does it makes sense. Hereby ac­cess to the vast Sys­tem 1 re­source all hu­mans share is wasted.

A good way to de­sign macro-level in­for­ma­tion that our Sys­tem 1 can ap­pre­ci­ate can be found in the legacy of Walt Dis­ney’s an­i­ma­tion prin­ci­ples. These were later pro­moted by Pixar’s John Las­seter and even­tu­ally found their way found into GUIs thanks to Steve Jobs and his tight con­nec­tion to Pixar. You might also con­sider movie edit­ing prin­ci­ples as an in­spi­ra­tion for how to de­sign for im­me­di­ate un­der­stand­ing.

Finally, word of cau­tion: do not ask users to think aloud in user tests. When we ask peo­ple to ver­balise what they do, we risk mov­ing into the realm of Sys­tem 2, and ob­scur­ing how well your de­sign con­nects with the de­sir­able prop­er­ties of ba­sic Sys­tem 1 pro­cesses. A bet­ter ap­proach is to ask users to ver­balise their thought pro­cesses af­ter­wards, while see­ing a video record­ing of their own in­ter­ac­tion.

HCD tool­box

This ar­ti­cle only ex­plores a small pre­view of the in­sights on of­fer. Take a look at our HCD tool­box (­sign

psy­chol­­sights), for more for­mal knowl­edge about psy­cho­log­i­cal mech­a­nisms. There is plenty to learn, no mat­ter what prod­uct you’re work­ing on.

The gap be­tween the­o­ret­i­cal psy­chol­ogy and prac­ti­cal ap­pli­ca­bil­ity to prod­uct de­vel­op­ment is clos­ing up. Any prod­uct de­vel­op­ment team should there­fore have ac­cess to these in­sights to help guide their de­sign de­ci­sions. It can be in the form of a trained psy­chol­o­gist, or, even bet­ter, hav­ing your de­sign team con­nect with our HCD tool­box.

With­out for­mal psy­cho­log­i­cal knowl­edge present in the de­vel­op­ment process, we can only ad­dress the hu­man side through the test-iter­ate loop. This is too un­cer­tain, and valu­able in­sights are cer­tain to be over­looked and lost

Newspapers in English

Newspapers from Australia

© PressReader. All rights reserved.