User Experience

Dutch Requirements Engineering And ManagementDREAMagazineWWW.DREAMEVENT.NL

SEPTEMBER 201 5

. .Thema UX

Interview with Chris Rupp

Interviews metRoos Groenewegen en

Jos Westerink van bol.com

Kano DevOps

DREAMagazine SEPTEMBER 201 52

VoorwoordRedactioneel

ColofonDREAMagazine is een ti jdschrift over Requirements Engineering. Het wil een platform zijn voor het uitwisselen en uitwerken van ideeën

over het vakgebied.

DREAMagazine verschijnt driemaal per jaar. Dit is nummer 1 0. Deze en de andere edities zi jn te vinden op www.dreamevent.nl .

Reacties en bijdragen kunnen gestuurd worden naar dreamagazine@dreamevent.nl .

Redactie: Linda Haak - van der Spek, Reinoud de Leve, Johan Oldenziel en Hans Siebering.

Deze editie is tot stand gekomen dankzij bi jdragen van: Geertje Appel, Stefan Dekker, Wopke Postuma en Piet de Roo.

Bronverwijzing afbeeldingenPagina 1 0: http: //www.qcin.orgPagina 1 3: http: //www.sl ideshare.netPagina 20: http: //steve-dale.netPagina 23: http: //artige.nl

Pagina 33: http: //fengshuiarqitect.wordpress.com/

Deze keer besteden we in het DREAMagazine aandacht

aan User Experience (UX). User Experience is een

vakgebied dat in opkomst is en dat tegen ons vakgebied

aanligt. Stefan Dekker schreef voor ons een artikelover hoe hij UX­instrumenten bij spir-it (het ICT-

bedri jf voor de rechtspraak) inzet om tot betere

requirements te komen. Dankzij UX-instrumenten komt

het verhaal van de klant pas echt tot leven. We spraken

met Roos Groenewegen over hoe ze User

experience bij de grootste webwinkel vanNederland toepassen. Zij is teamleider van het UX-

design team bij bol.com. Een UX-er is volgens haar ook

een beetje de ambassadeur van de klant. WopkePostuma schreef een artikel over hoe we in een user

interface design gebruik kunnen maken van principes uit

de Gestalt psychologie. Waarom herkennen we

dingen als bij elkaar horend of juist niet. In Versusgeven verschil lende collega’s hun mening over of we op

een UX-cursus moeten en waarom. Johan Oldenzielzocht al lerlei handige l inks over User experience op

internet voor ons op. Je kunt ze vinden in onze vaste

rubriek Net gezien.

Naar aanleiding van het vorige DREAM eventinterviewden Linda Haak ­ van der Spek en

Geertje Appel met Chris Rupp één van de

keynote speakers. Piet de Roo past in zi jn artikel het

model van professor Kano voor het categoriseren

van requirements toe op de beloningsstructuur van

medewerkers. Het geeft niet al leen inzicht in hoe je het

model van Kano kunt toepassen, maar ook hoe uw

werkgever u waardeert. Linda Haak ­ van derSpek vertelt in haar column over haar ervaringen met

DevOps. Tenslotte spraken Hans Siebering enReinoud de Leve met Jos Westerink over het

boek Mindset. Een fascinerende gedachte uit het boekis dat je meer kunt als je maar de juiste mindset hebt.

Van Jos leren we dat dit ook echt zo werkt.

In ons komende magazine gaan we weer veel aandacht

besteden aan het DREAM event van 8 oktober.We zullen praten met sprekers en bezoekers. Naast heel

veel andere interessante verhalen, zal GramLucassen (Universiteit van Utrecht) spreken over

‘Writing better User Stories’. We hebben aanGram gevraagd of hi j in het komende magazine als een

soort Mona de vragen van lezers wil beantwoorden en

dat gaat hi j voor ons doen. Als u nog niet al les over User

Stories weet, is nu het moment om het te vragen aan

een expert. Stuur uw vragen naardreamagazine@dreamevent.nl.

User Experience 3

Inhoud2 Redactioneel

Voorwoord4 Interview with Chris Rupp

Excellent analyst and communicatieveinterfaceGeertje Appel & Linda Haak ­ van der Spek

8 KanoLet Kano determine your bonusPiet de Roo

11 DevOpsEen requirements engineer in eenDevOps omgevingLinda Haak ­ van der Spek

1 4 VersusElke requiurements engineer moet opUX cursus

1 6 Programma DREAM1 5

1 8 UXSamenwerken aan goede requirementsmet UX-instrumentenStefan Dekker

24 GestaltHet leuke van UXWopke Postuma

28 Interview met Roos GroenewegenCustomer journeyReinoud de Leve & Hans Siebering

31 Interview met Jos WesterinkMindsetReinoud de Leve & Hans Siebering

34 Net gezienOntdekkenJohan Oldenziel

DREAMagazine SEPTEMBER 201 54

Stakeholder map: You explained the concept ofa stakeholder map, we like that and think itcould even be more useful if you add somemore information about stakeholders, like forinstance the attitude towards the project andthe power they have to influence it? Do youagree on that or do you keep this informationseparate from the stakeholder map (if yes, whywould you keep it separate?)

A stakeholder l ist should be publicly accessible, so thatevery person involved in the project can add comments.By handling it this way, one often discovers furtherrelevant stakeholders, when someone who is missingthese stakeholders on the l ist recommends adding them.

As the stakeholder l ist is public, you should think twiceabout which information you want to include. Informationsuch as the attitude of a person towards the project orthe decisive power in terms of that project might besensitive. However, especial ly this information is veryinteresting for us as requirements engineers. I knowabout projects in which two stakeholder l ists aremaintained. One official version which includes theuncritical information relevant for al l persons involved.The other one, the confidential stakeholder l ist, is onlyaccessible to the requirements engineers. The latter l istmight include information such as the relevance of thatperson’s opinion in the project, whether that person israther approachable or difficult in interviews, his attitudetowards the project, or what analyst he gets on well withand so on.

Excellent analyst andcommunicative interfaceChris Rupp was a keynote speaker at the DREAM event 201 4. In hertalk about el icitation she claimed that we sometimes need the methodsof Sherlock Holmes to get the best results. She told us who theadequate informants are and which witnesses we should call , whichmethods of investigation are appropriate and what the best possiblecognitive process in the case of system development should look like.After the event we asked her to explain her way of working in moredetai l .

Interview with Chris Rupp

by Geertje Appel and Linda Haak - van der Spek

User Experience 5

Personas: You told us about personas and howuseful they are. Can you mention somedisadvantages of using personas? Do you alsouse personas in projects where there is alimited group of stakeholders who are all goodaccessible?

Of course, personas also have disadvantages. To createthem in a meaningful way, for instance, takes time. Youcould as well use that time to ask a later user of thesystem directly about his expectations on the system.

When I ’m dealing with a very l imited group ofstakeholders, whose requirements I am able to el icitdirectly, I refrain from creating a persona. For me, apersona always remains only a representative for agroup of people whose needs and behavior I try to takeinto account as specifical ly as possible, since I cannotinterview them in the necessary level of detai l (as thegroup is either too big or inaccessible). A persona isalways a compromise, since I attribute the needs of anentire target group to one single persona. In doing so, Iam making lots of decisions, as a persona is astereotype, supposedly representing an entire group. Apersona is good when 80% of the members of a groupfind themselves represented in it. Every actual memberof that group wil l significantly differ from the persona incertain needs.

However, when eliciting the needs of al l individualpersons directly, I also have to make compromises whendesigning the system, as not al l requests can beimplemented simultaneously in the future system. In thiscase, however, I del iberately make compromisesregarding the expressed requests of individualstakeholders. That is, I know for a fact who I offend withmy decision when rejecting their requirements.

Personas: What is your tip to make goodpersonas? How do you prevent making toomany assumptions?

The most rel iable way of creating a good persona isprofound market research. You would have to interrogate

an empirical ly significant number of people out of yourtarget group. The next steps are subdividing thesepeople in suitable subgroups, statistical ly evaluating theirneeds and characteristics and then, based on the results,creating a persona. I f you’re now thinking “that soundsl ike a whole lot of effort”, you’re perfectly right. Thismethod is used in the consumer market when the goal isto generate high-quality goods for a highly competitivemass market. I always recommend using personas as anaddition to real stakeholders when either a certain groupof stakeholders is inaccessible, or when this particulargroup is too large to interview a representative number ofpeople.

In the first case (real stakeholders of a certain group arenot accessible), it is better to have a persona whichroughly represents the group of stakeholders, thanhaving no idea about how the stakeholders are wired. Iremember a project where we did not have access to themaintenance engineers. Therefore, we did someresearch on the occupational profi le of the maintenanceengineers working in this corporation and, based on ourgenerated insights, created the draft of a persona. Wethen discussed this persona with the other stakeholderswho knew maintenance engineers in this corporation andgathered feedback. In the end, we eventual ly found amaintenance engineer who could at least review thepersona, found himself quite well represented and couldcontribute a number of important requirements.

In the other case (an excessively large group ofstakeholders), we combine eliciting requirements fromreal stakeholders with creating requirements based onpersonas. The made-up requirements based onpersonas are then of course presented to the realstakeholders for comments and adjusted to theirrequirements.

Sherlock Holmes: We liked your comparisonwith Sherlock Holmes. Do you think goodrequirements engineers are also gooddetectives like Sherlock Holmes?

Yes! There is definitely a similarity between theseoccupational profi les. You’re searching for conscious,unconscious and subconscious knowledge. You’retalking to wil l ing and unwil l ing interview partners. Noteverybody reveals his true intention,[ As a requirementsengineer you’re gaining a better and better insight overtime, you’re able to ask more specific questions and tocompare the facts. Just l ike a skil led detective ;-)).

Chris Rupp

I always recommend using personasas an addition to real stakeholderswhen either a certain group ofstakeholders is inaccessible, orwhen this particular group is toolarge to interview a representative

number of people.

DREAMagazine SEPTEMBER 201 56

Interview

Subconscious knowledge: You told that thesubconscious knowledge is difficult to elicitate.Can you give us some tips how we improve ourskills on this subject?

Subconscious requirements are that self-evident for thestakeholders that they do not express them, they do noteven perceive them consciously. That does not mean,however, that these requirements are not important.Quite the opposite. They are so essential that thefunctions that result from them are used so often that thesystem behavior is already taken for granted.

You can elicit these requirements e.g. by observing yourstakeholder at work. When doing so, you wil l alsowitness the self-evident workflows. Why don’t you try toconduct the work of your stakeholder (who, at best,guides you as your teacher) for once? While doing so,you wil l notice that you miss the self-evident informationyour teacher forgets to provide you with. A look at thepredecessor system wil l pay off as well . Thesubconscious requirements should be implementedthere. I f you discover subconscious requirements andface your customers with them, they wil l tel l you: Ofcourse I need that[

Elicitation: You made clear that the key to goodrequirements elicitation is using the righttechniques, that is a skill that is learnable, butalso to be able to get to the unconsciousknowledge. Is that part also learnable, as itseems much more intuitive than rational?

Unconscious requirements are requirements which thestakeholders do not recognize initial ly. Whenexperiencing them using the product, however, they areimmediately fascinated and discover their need for them.You don’t el icit these requirements, you invent themtogether with the stakeholders. Hence, we’re in the fieldof innovation, creativity, intuition. In order to worksuccessful ly in this field, al l involved parties needprofound basic knowledge of the respective domain.Great ideas do not evolve from a base of ignorance. Inaddition to solid knowledge of the special field, you alsoneed broad knowledge in many other areas (in order tobe able to draw ideas for a possible transfer from them)and the skil l to cross concepts and ideas of one field withproblems of another. Thus, concepts might emerge whichcover the current needs of your stakeholders. I ’m not a

big fan of creativity techniques. They are one possibleway of creating innovative ideas. What is of moreimportance to me is the wealth of knowledge in theheads of people that you can use to work with and thepotential to wildly match these fragments of knowledge.Skil led people can do this with or without using a certaincreativity technique. However, specific creativitytechniques are advisable when running workshops withseveral participants, especial ly when certain problemsexist, for example difficult group dynamics. In this case, atechnique like the 6-3-5 method might solve the problemand help to establish a creative working cl imate.

Elicitation: In the IT business the majority ofpeople seems to be more beta (mathematical,methodical, scientific) but is requirementselicitation of business analysis the area wherethe more alpha (linguistic, creative) people canbe effective?

Phew, difficult question. In general, it is essential that arequirements engineer is, on the one hand, an excellentanalyst (as the requirements engineer has to build onemodel of a system out of 1 000 single items of informationand resolve redundancies and contradictions while doingso). The requirements engineer gathers information of agreat number of stakeholders and condenses thesedetai ls to one consistent view.

Why don’t you try to conduct thework of your stakeholder (who, at

best, guides you as your teacher) foronce?

You don’t el icit unconsciousrequirements, you invent themtogether with the stakeholders.

User Experience 7

Chris Rupp

On the other hand, requirements engineers are thecommunicative interface that connects systemdevelopment and the rest of the world. Thus, they need ahigh level of l inguistic competence and a creative mind-set, as they have to invent the future system togetherwith the stakeholders.

Compared with other IT-discipl ines (such as architects,developers, testers), they need considerably more alphafeatures.

Elicitation matrix: We can see that using thematrix with elicitation can be very useful, how

do you (at your company for instance) use thisin practice, is there a general matrix per project,or is this more personal per consultant?

We work with the matrix we have published. From thatwe draw the most suitable el icitation technique thatwould help with the specific situation. However, everyanalyst takes the l iberty of contradicting the matrix, whenthey personally do not l ike the respective technique, orwhen they have the feeling that a certain stakeholdermight be more open to another technique. The matrixshould serve as a support tool and not as a strict preceptor dogma.

Chris Rupp

SOPHIST-in-chief (formally: founder and executive partner of the SOPHIST GmbH), chief consultant, coachand trainer. Looking back over 25 years of professional experience, a lot has come up: a company, 6 books, 55employees, countless articles and presentations and a whole lot of experience. My passion for projectconsultation might account for the fact that, unti l now, I do not “only” manage, but I am sti l l directly involved inprojects and close to customers. What drives me is the vision to implement good ideas so that developers,contractual partners and users – both direct and indirect – face an intel l igent, sophisticated and beneficialproduct. In doing so, I work with a range of methods and approaches in agile and non-agile environments. Inorder to standardize qualification for requirements engineers / business analysts, I founded the IREB e.V.(International Requirements Engineering Board).

DREAMagazine SEPTEMBER 201 58

Are your employees rewardedsatisfactorily?You have probably heard about the short lasting effect ofa salary raise, about employees who are not evensl ightly happy when they receive a bonus and aboutpeople who get real ly mad when they no longer havetheir own parking place near the main entrance. Yetsome can get very excited when their boss mentionsthem as the 'employee of the year'. These actions are allpart of the reward system of the company and manytimes the effects are greatly misunderstood.

Some informal analysisLet's have a look at some rewards and the effect theyhave on employee satisfaction.

Regular salaryAt the end of a month the employee looks at his bankaccount, sees that his salary was deposited, doesn'teven smile and gets on with whatever else he had to do.Unless he discovers that he didn't receive the rightamount, but less. I f he would then contact the companyto find out that his salary was decreased intentional ly byhis manager, for whatever reason, he would probably getvery mad.

Let Kano determine yourbonusIn 1 984 Prof. Noriaki Kano published his article [Kano] about the systemto categorize requirements based on customer satisfaction. Thisclassification of requirements is often used by requirements engineersand business analysts. I t is also part of the CPRE education. Usually,though, Kano’s model is used only partly, mainly to visual ize what wil ldel ight the customers, what wil l they take for granted and what wil l theycomplain about when it is not del ivered. This article aims to il lustrate theentire approach Prof. Kano described, based on an example that wil lrelate to many of us: the reward system for employees in organizations.And for the managers among you: if you would l ike to know how toplease your employees in the cheapest way, you might learn somethingas well .

Kano

by Piet de Roo

Piet de Roo is senior consultant at Improve Quality Services, a

company of 30 employees offering high-end services in the area of

testing and quality management.

He has more than 20 years of experience in software development,

testing, test automation, requirements engineering, quality assurance

and process improvement. Initial ly Piet worked in both traditional and

agile processes mainly on technical and embedded software products at

Phil ips, Siemen and TomTom. At Improve Quality Services Piet is active

as a trainer and training developer for testing (ISTQB, TMap, Mobile

App Testing, Exploratory Testing), Acceptance Test Driven Development

and Requirements Engineering (CPRE, Agile Business Analysis). In

addition he is active as coach and consultant in both technical and

administrative organizations.

User Experience 9

Personal BonusThe salesman who checks his December salaryknowingly that he more than reached his targets -apparently his boss had noticed that too and granted hima bonus proportional to his achievements - is rathersatisfied. Last year he was disappointed, after not havingreached the targets the bonus then was very small .Apparently the extra effort he invested this year paid off.

Incidental giftAfter doing some overwork the manager calls theemployee to his office. He thanks the employee for theextra effort he put into the project and hands him anenvelope. 'Go and have a nice dinner with your wife oncompany budget. You've deserved it and so has she.Thank you for helping me out in this crisis. 'Three kinds of rewards with three kinds of effects. . .• I f you get your regular salary, it doesn't affect you, if

you get less you get mad.• I f you get more because you put in more effort,

you're satisfied. I f you get less you're disappointed,even though you may have achieved less.

• I f you get a restaurant voucher you are happilysurprised. I f you didn't get a voucher it wouldn't haveaffected you as you never expected to get one.

The Kano modelThe Kano model categorizes requirements into threetypes depending on the influence they have onstakeholder satisfaction.

Must-be requirements do not have a positiveinfluence on stakeholder satisfaction. I f they are met,the stakeholder wil l take this for granted. I f they arenot met, the stakeholder wil l be dissatisfied. This isl ike your regular salary. Must-be requirements arealso known as “basic needs”.One-dimensional requirements if fulfi l led have apositive effect on stakeholder satisfaction, if not theyhave a negative effect. This is l ike the achievementrelated bonus. One-dimensional requirements areoften called “performance needs”.Attractive requirements are l ike the restaurantvoucher, they have a satisfying effect on thestakeholder if fulfi l led. I f not fulfi l led, they have no

effect at al l . Attractive requirements are also called“del ighters”.

The degree of satisfaction for each of the requirementtypes is depicted in Figure 1 Kano model.

Applying the Kano modelApplication of the Kano model begins with identificationof the requirements. In my analogy this means identifyingthe various ways of 'rewarding' the employees, i .e. l istingthe factors that may have influence on employeesatisfaction. From the example we see the fol lowingfactors, or requirements for the reward system:• Current salary• Standard salary raise• Inflation compensation• Company bonus• Individual targets bonus• Personal bonus• Personal compliments• Public compliments• Incidental gift

Step two in the Kano process is analysis of the effectsthe degree of fulfi l lment of these requirements wil l haveon employee satisfaction. This is done by creating aKano questionnaire. The questionnaire consists of twoquestions for each of the requirements, namely aquestion in the functional form and one in thedysfunctional form. The questions look like this:• Functional: I f this requirement is met, how does that

make you feel?• Dysfunctional: I f this requirement is not met, how

does that make you feel?

And the answers can be one of:• I l ike it that way• I t must be that way• I don't care• I can l ive with it that way• I disl ike it that way

Note that 'I l ike it that way' indicates a higher degree ofcustomer satisfaction than 'I t must be that way'.

In step three we analyze the answers that thestakeholders fi l led in. As they have to answer twoquestions for each of the requirements this may lead tocontradictory statements. The table below is an

Let Kano determine your bonus

Application of the Kano modelbegins with identification of therequirements. In my analogy thismeans identifying the various waysof 'rewarding' the employees, i .e.l isting the factors that may have

influence on employee satisfaction.

Figure 1 Kano model

DREAMagazine SEPTEMBER 201 51 0

instrument to evaluate the answers.

The functional form of the requirements can now becategorized as fol lows.• M means this is a Must-be requirement.• O means this is a One-dimensional requirement• A means this is an Attractive requirement• I means this requirement is Indifferent to the

customer (so is it a requirement?)• Q means the requirement is Questionable (were the

functional and dysfunctional questions formulatedcorrectly? Did the customer understand thequestions? Double-check!)

• R means the Reverse of the functional requirementseems to be required. (Swap the functional and thedysfunctional questions and ask again).

Note that the table differs from the one in [Sauerwein]. I fboth the functional question and the dysfunctionalquestion are answered with 'I t must be that way' therequirement is considered questionable rather thanindifferent.

To get an insight of the rating of the requirements, takinginto account the answers of al l stakeholders, thefrequency of the answers is calculated. For the examplethis could look like this:

Here the category (M, O, A) is determined by the highestpercentage in the table.

According to Berger [Berger] there is another possibi l ityto categorize the requirements taking into account therating of al l stakeholders. Berger calculates the 'extent ofsatisfaction' (CS) and the 'extent of dissatisfaction' (CD)as fol lows:

CS = (A+O)/(A+O+M+I)CD = -(O+M)/(A+O+M+I)

This yields the fol lowing result:

Do you recognize this? I think it says that if you want toplease your employees you are most effective by givingthem a compliment in public or an incidental gift. And ifyou don't, they won't bother. I f people don't get theirsalary it probably is due to some administrative mistake.But if you want to encourage them to look for another job,don't give them any raise nor inflation compensation.

References[Berger] Berger, Charles; Blauth, Robert; Boger, David;Bolster, Christopher; Burchil l , Gary; DuMouchel, Wil l iam;Pouliot, Fred; Richter, Reinhard; Rubinoff, Al lan; Shen,Diane; Timko, Mike; Walden, David. 'Kano’s Methods forUnderstanding Customer-defined Quality', In: Center forQuality Management Journal, Vol. 4 (Fall 1 993), pp. 3 -36.

[Kano] Kano, N. , N. Seraku, F. Takahashi and S. Tsuji :'Attractive Quality and Must-be Quality', Hinshitsu, Thejournal of the Japanese society of quality control, apri l1 984.

[Sauerwein] Sauerwein, Elmar; Bailom, Franz; Matzler,Kurt; Hinterhuber, Hans H. “The Kano model: how todelight your customers.” Preprints Volume I of the IX.International Working Seminar on Production Economics,Innsbruck/Igls/Austria, February 1 9-23 1 996, pp. 31 3-327.

Kano

Noriaki Kano

DREAMagazine SEPTEMBER 201 511

Wat is DevOps?Om te beginnen is het belangri jk om te weten watDevOps is. Dit is ook geli jk een lastig punt, DevOps isnameli jk geen methode, maar een mindset. Er is geenprachtig manifest zoals van Agile, of een mooi handboekzoals voor Scrum. Nee op internet is er eigenl i jk weinigconcreets over te vinden. Duidel i jk is wel dat DevOps decombinatie is van Dev (development) en Ops(operations).

Wat ik onder DevOps versta is het volgende: DevOpsvloeit voort uit Agile. Waar we met Agile zi jn begonnenmet kort-cycl isch te werken, met business endevelopment bij elkaar aan een product te werken, metkorte communicatiel i jnen, wordt dat met DevOpsuitgebreid door aan de Scrumteams de OPS mensen, deoperations mensen (functioneel beheer, technischbeheer, database administrators etc.), toe te voegen. Ditmet als doel om continu (en daarmee dus nog efficiënter)werkende software te leveren. Dus eigenl i jk maken wede stap van Agile/Scrum in Dev-teams naar nog meersamenwerken in DevOps-teams. Om een DevOps-teamte worden zijn er al lerlei hulpmiddelen beschikbaar die je

daarbij kunnen helpen zoals automatisch testen endeployen.

Bij DevOps wordt naar de gehele IT cyclus gekeken, datzie je in de afbeelding hiernaast. We zijn begonnen metde stappen specificeren t/m testen te optimaliseren metbehulp van Agile/Scrum. Daarna hebben we hieraccepteren t/m run aan toegevoegd, bekend als AgileBeheer. En nu maken we de cirkel rond, en nemen dusalle aspecten mee. Dat noemen we DevOps.

Met DevOps bekijk je elke processtap en bepaal je waarverbeterpunten zitten waar de business profi jt van heeft.Daar ga je mee aan de slag. Dit resulteert in een uniekeinvul l ing van DevOps in elke organisatie.

Wat zijn de gevolgen voor eenrequirements engineer?DevOps is een logisch vervolg op Agile, daarom vergeli jkik de rol van een requirements engineer in een DevOpsomgeving met die in een Agile omgeving. Ik zie hier eenaantal belangri jke veranderingen.

Van projectlid naar lijnfunctieEen requirements engineer is alti jd gewend geweest omin projecten te werken. Met DevOps verandert dit, jekomt nameli jk in een li jnfunctie terecht. Het doel van jewerk verandert daar deels mee, want ging je eerst naareen volgende opdracht als het systeem ‘af’ was, kun jenu zomaar jaren bli jven werken aan een systeem(jarenlang één opdracht, iets waar we met Agile werkenvanaf leken te zijn).

DevOps

Een requirements engineerin een DevOps omgevingAls requirements engineer moet je met je ti jd mee gaan; wat gebeurt erin de ICT-wereld en hoe beïnvloedt dat het werk? De laatste jaren zie jedat de ICT zich vooral is gaan richten op Agile & Scrum werken. Nu is ereen nieuwe beweging in gang gezet die ook onze aandacht vraagt. Ikheb het hier over DevOps. Sommige bedri jven doen al DevOps, en veelandere bedri jven zijn aan het bedenken of ze er ook iets mee wil len. Zelfben ik van oorsprong requirements engineer, en ben momenteel ingezetals Scrummaster in een DevOps team. Ik zie dat mijn requirementscollega’s steeds vaker in DevOps omgevingen worden ingezet. Het isdus hoog ti jd om te kijken wat DevOps voor requirements engineersbetekent.door Linda Haak - van der Spek

DevOps is geen methode, maar eenmindset. Er is geen prachtig

manifest zoals van Agile, of eenmooi handboek zoals voor Scrum.

User Experience 1 2

Het betekent o.a. dat je soms wat meer bezig zult zi jnmet het verbeteren van processen om goed werkendesoftware op te leveren, omdat je hier lange ti jd baat bi jhebt. Denk hierbij aan bepaalde belanghebbenden die jemet regelmaat nodig hebt, of aan het gehelevoortbrengingsproces.

Het hergebruik van door jou opgestelde requirementswordt van groter belang. Je zult langer met dezelfdematerie bezig zi jn, dus: breng efficiëntie in je werk. Methet opstel len van requirements houd je er meer rekeningmee dat je ze later nodig hebt om weer in te kijken enher te gebruiken waar mogeli jk.

T­shaped profielMet Agile waren we al begonnen om veelzi jdiger teworden, je keek al wat vaker naar wat je buurman/-vrouwdoet en hielp elkaar zo veel mogeli jk. Met DevOps wordtdit al leen maar meer, er zitten meer verschil lendeexpertises in het team, dus je kunt je met meer dingenbezig houden. En omdat een DevOps team continu zalbl i jven bestaan, ook in ti jden waar er weinig wordtgedaan met requirements, zul je als requirementsengineer ook meer ti jd besteden aan andere taken. Denkbijvoorbeeld aan testen, functioneel beheer, maarmisschien ook incident management omdat je deapplicatie heel goed snapt.

Hier ga je de nodige cursussen voor volgen, en zoontwikkel je een T-shaped profiel . Dat betekent dat je openkele gebieden diepgaande kennis hebt (het verticaledeel van de T, vooral requirements dus) maar ook enigekennis hebt op andere gebieden (het horizontale deelvan de T). Let wel op dat je je eigen special ismebehoudt, en je daar ook in bl i jft ontwikkelen.

Leer je (OPS)buren kennenWerkend in een DevOps-team gaat je je OPS-collega’ssteeds beter begri jpen. Hoewel je deze collega’s in hetverleden al betrok in het opstel len van requirements, kri jgje nu beter inzicht in hun werk omdat je letterl i jk naasthen zit. Waar houden OPS’ers zich de hele dag meebezig, en wat voor soort tools gebruiken ze?

Als requirements engineer merk je dan wat de noodzaakis van bijvoorbeeld goede monitoring. Daar maak je jeweer hard voor bij de product owner, en daarna stel jesamen met de teamleden hier goede requirements voorop. Ook denk ik dat je meer respect kri jgt voor het brede,diepgaande en onvoorspelbare werk dat OPS’ers doen.

De klant nog beter begrijpenIn een DevOps team kun je niet om incidenten en andereverstoringen heen. Dit heeft zo z’n nadelen (bi jvoorbeeldstandby diensten draaien in het weekend), maar ookvoordelen: je ziet echt waar dingen mis gaan. Waar looptde klant tegenaan (bijvoorbeeld X keer per maand dathet systeem offl ine is), en welke gevolgen heeft dat? Datgeeft mooi inzicht in wat er verbeterd moet worden enwat hoge prioriteit heeft. Het laat soms ook pijnl i jk zienwaar je fouten in je requirements hebt gemaakt, maardaar leer je dan ook weer van.

Achtergrond

Wat ik interessant vind isbi jvoorbeeld ‘dark launching’ en‘levers & nuclear options’.

DREAMagazine SEPTEMBER 201 51 3

DevOps

Spelen met functionaliteitIn mijn zoektocht naar DevOps kom ik ook allerlei nieuwetermen tegen. Wat ik interessant vind is bi jvoorbeeld‘dark launching’ en ‘levers & nuclear options’. Hiermeekun je nieuwe functionaliteit laten schaduwdraaien, offunctionaliteit voor een bepaalde groep gebruikers actiefmaken om uit te proberen. Hoe gaaf is dat? Je test danmet echte gebruikers (die je hiervoor misschien nooit zoukunnen benaderen) en als het niet goed gaat deactiveerje de functionaliteit.

Tenslotte weet je eigenl i jk pas als de software gebruiktwordt of je requirements goed (genoeg) waren, en opdeze manier kun je ze daarna nog makkeli jk bi jstel len.

Wat misschien wel even wennen is, is dat er somsmeerdere oplossingen voor een behoefte wordengebouwd en dat de oplossing met meerdere kleinegebruikersgroepen wordt geprobeerd en getest. Maareigenl i jk is dat wel heel gaaf, want j i j wi lt toch ook dat debeste oplossing in productie wordt genomen?

Dus wat betekent het nou?Het werken in een DevOps team is voor eenrequirements engineer niet slechts ‘vanaf nu ga ik beheermeer betrekken’, nee het behelst veel meer voor dewerkzaamheden in deze rol.

Je bent nameli jk nog meer deel van de organisatiegeworden omdat je in een continu werkend li jnteamwerkt. Je wordt er veelzi jdiger van omdat je bij al levoorkomende taken in het team wordt betrokken en jeleert meer van collega’s. Wat ook erg nuttig en zinvol is,is dat je de klant veel beter gaat begri jpen door de extrainformatie die je kri jgt en dat er al lerlei techniekeningezet kunnen worden om meer met functionaliteit tespelen en je zo de beste oplossing voor de klant kuntkiezen. Eigenl i jk is DevOps dus een prachtige verri jkingvan de functie requirements engineer!

Je wordt er veelzi jdiger van omdat jebij al le voorkomende taken in hetteam wordt betrokken en je leert

meer van collega’s.

User Experience 1 4

Elke requirements engineermoet op UX cursusAls je ergens van overtuigd bent dan zal je vinden dat je geli jk hebt.Maar wat als iemand het dan totaal niet met je eens is? Dan kan het erwel eens heet aan toe gaan.

In deze rubriek zoeken we de uitersten op. We nemen een stel l ing,graven ons aan weerszijden in en verzamelen munitie om elkaar mee tebestoken. Dan kan de stri jd losbarsten. Het is aan u om een oordeel tevellen: is er een winnaar of eindigt de stri jd onbeslist? Deze keer luidt destel l ing: “Elke requirements engineer moet op UX cursus”. Bent uhet ermee eens? Of toch niet?

Versus

We vinden in grote meerderheid dat RE-ers meer vanUX zouden moeten afweten, maar of ze daarvoorverpl icht op een cursus moeten is wel een beetje devraag. Welke kennis doe je op in zo'n cursus? Kun jedie kennis niet ook in de prakti jk opdoen, misschien weldoor gewoon goed om je heen te kijken. We zientenslotte dageli jks voorbeelden van goede en slechteUser Experience.We vinden UX over het algemeen wel echt een andervakgebied dan RE. We beschouwen het niet als iets datwe er gewoon even bij kunnen doen. We hebben weleen mening. We kunnen de klant hier en daar weladviseren. Maar als het er echt op aan komt, heb je weliemand met special istische kennis nodig.Wel denken we dat een basiscursus zou kunnenbijdragen aan een bredere inzetbaarheid.

"Ik vind de stelling wat raar. Devraag is of het waardevol zou zijnvoor een requirements engineer omkennis en kunde te hebben van UXdesign. Of je dit nu via werkervaring,zelfstudie, een cursus of doormiddelvan tekenen op bierviltjes in dekroeg verkrijgt doet er niet zoveeltoe.

Los daarvan denk ik zeker dat hetbelangrijk is voor een requirementsenigneer om hier ervaring in tehebben. Vooral als je dit koppelt aanAgile waarbij multidisciplinariteitvoor elk teamlid zeer waardevol is.Tevens hangt het maken vanfunctioneel fatsoenlijk werkendesoftware niet alleen maar af vanbusiness rules, stories of wat danook. Een stukje software metfatsoenlijke gebruikersinteractie datplezierig en efficiënt werkt is net zogoed belangrijk."

Voor de komende keer kunnen jul l ie reageren op de

stel l ing:

Requirements engineerszijn onmisbaar voor iedersuccesvol IT­project

Natuurl i jk zi jn we het daar al lemaal roerend mee

eens. Toch kri jg ik zo af en toe het gevoel dat anderen

stevig aan onze poten zagen. "We zouden best wel

zonder kunnen nu we met agile de business en IT al

zo dicht bi j elkaar hebben gehaald." hoor ik ze wel

zeggen.

Reacties naar: dreamagazine@dreamevent.nl

User Experience 1 5

EENSONEENS

Versus

UX is een ander vakgebied metandere rollen dan RE. Ik vind hetwel handig om er iets vanaf teweten. Ik kan dan de klant duidelijkmaken wat de mogelijkheden enonmogelijkheden zijn. Daarvoor isvoor mij een awareness trainingwel voldoende.

Volgens mij is het wel handig omkennis van UX te hebben. Maar ofje daarvoor verplicht naar zo’ncursus moet is maar de vraag. AlsRE­er ben je vooral op zoek naarwelke functionaliteit gewenst is enUX zie ik meer als: hoe bied ik diefunctionaliteit aan de gebruikeraan.

Helemaal mee eens! Een meer dan goede

toevoeging voor een RE­er!

De acceptatie van een applicatie staat of

valt met de gebruiksvriendelijkheid

ervan. Lopen gebruikers er mee weg of

lopen ze er van weg? Dat is de vraag.

Ik vind dat elke RE­er verstand moet

hebben van UX­design. Dat is een zwaar

onderschat ontwerpgebied.

Ik denk dat het goed is om ons te

verbreden in kennis en vaardigheden.

We werken tegenwoordig vaak in kleine

Scrum teams. Dat vraagt om breed

inzetbare mensen. Wij, RE­ers zouden

dat ook moeten zijn.

Samenwerken met een UX designerlijkt me veel beter. Door samen tewerken wordt de creativiteitgeprikkeld, ontstaan er nuttigediscussies met als gevolg een veelbeter resultaat.

Je hoeft niet naar een cursus omiets over UX te leren. Je wordtdagelijks omringd door voorbeeldenvan goede en slechte UX. Door metgebruikers hierover te praten komik er wel achter wat goed en foutis. Met eigen ervaring kom ik al eenheel eind in het ontwerpen van eengoede UX.

Ik werk vooral als business analisten houd me met de hoofdlijnen vande functionaliteit bezig (needs/features en processen). Daar heb ikgeen UX kennis voor nodig.

Kennis over UX hoort zeker thuis in de

bagage van een RE­er. Mijn ervaring is

dat wireframes een goed middel zijn om

met de gebruiker te praten over de

requirements voor de user interface. Zelf

maakte ik vaak plaatjes die erg ‘windows’

aanvoelden. Kennis van html5,

bootstrap, angular, is daarom wel nuttig.

Er zijn online diverse plekken (bijv.

http://www.w3schools.com/html), waar je

er zonder iets te installeren mee kan

spelen. Dat geeft een heel goed gevoel

van de mogelijkheden.

Juist omdat UX een (relatief) nieuw

vakgebied is waarin de gebruiker en

gebruikerservaring centraal staat, is het

goed dat analisten hier ook kennis van

hebben. Al was het alleen maar om in

hun user stories rekening te houden met

UX aspecten! Zo kunnen RE­ers hun

waarde voor de klant ook in de toekomst

blijven leveren.

DREAMagazine SEPTEMBER 201 51 6

Programma8 oktober 2015

User Experience 1 7

DREAM15Registratie: www.dreamevent.nl

DREAMagazine SEPTEMBER 201 51 8

UX experts als belangenbehartiger van de gebruikerhebben goede instrumenten om (latente) behoeften vangebruikers in kaart te brengen. Dit artikel gaat over hetgebruik van die instrumenten, wat dat in de prakti jkoplevert en hoe UX experts en requirementanalistenkunnen samenwerken. Het gaat er bij die samenwerkingom te kijken vanuit de verschil lende perspectieven, wantdat levert de beste oplossingen op. Maar ik begin meteen beschri jving van de UX-instrumenten.

De UX­instrumentenUX principes, persona’s, scenario’s, klantreizen, kl ikbareprototypes, interactiepatronen en usabil itytests zi jninstrumenten die we gebruiken om voor een goedegebruikerservaring te zorgen. Gebruikerservaringbetekent hier de complete beleving van de gebruiker bijhet gebruik van een dienst of product. Dit gaat verderdan alleen zorg voor taakuitvoering (kan iemand dat

Samenwerken aan goederequirements met UX­instrumentenSamenwerking is vaak de sleutel om te komen tot IT-oplossingen waarmensen bli j van worden. Als UX Lead bij spir-it (het ICT-bedri jf voor derechtspraak) zorg ik ervoor dat het UX-team op een efficiënte maniermet andere expertisegebieden kan samenwerken. Het is belangri jkvanuit verschil lende perspectieven te kijken naar de eisen die aan ’eenIT-oplossing worden gesteld. Het perspectief vanuit het bedri jfsproceswaarin we analisten (requirementsanalisten, businessanalisten,informatieanalisten) aan het werk zien, is vaak goed vertegenwoordigd.Architecten en functioneel ontwerpers werken vanuit het perspectief vanhet systeem en de techniek. Analisten en architecten hebben primainstrumenten om requirements te achterhalen, analyseren, specificerenen valideren. Daarbij worden helaas de behoeften van de gebruiker nietalti jd goed vertegenwoordigd.

UX

door Stefan Dekker

Als UX lead behartigt Stefan Dekker de belangen van particul ieren,juridische professionals en rechtspraakmedewerkers bij het digitaal

procederen. Met een ruime ervaring in rol len als ontwikkelaar,

functioneel ontwerper, modelleur, informatieanalist en nu als UX lead

weet hi j dat samenwerking de sleutel is tot kwalitatief goede software

met een goede gebruikerservaring. De aandacht voor een goede

gebruikerservaring is een rode draad in zi jn loopbaan. Want werken aan

een goede gebruikerservaring zorgt uiteindel i jk voor lagere kosten,

efficiënter gebruik en bli jere mensen.

User Experience 1 9

doen). Het gaat zelfs verder dan alleen de IT-oplossing,aangezien ook bijvoorbeeld wat iemand te horen kri jgtaan de telefoon van invloed is op de gebruikerservaring.

UX principesUX principes zijn praktische handvatten om te komen toteen goede gebruikerservaring. Ze inspirereninteractieontwerpers tot het maken van goedeontwerpen, maar ook anderen als requirementsanalistenkunnen hiermee geholpen worden. Er zi jn vele l i jstjesvan principes in omloop. Voor de rechtspraak hebben wijhieruit 1 0 belangri jke principes geselecteerd. Alles watwe doen als UX-team toetsen we tegen dezeprincipes.  

Persona’sPersona’s zi jn gedetai l leerde archetypischepersoonsbeschri jvingen van typische leden van eendoelgroep. Onze persona’s stel len we samen op basisvan informatie verkregen uit observaties en interviews

met de klant, reviewgroepen, klankbordgroepen, usabil itytests en website rapportages. Persona's zi jn bedoeld omiedereen te inspireren om vanuit de klant te denken. Wegebruiken ze bij briefings, brainstorms en bij reviews. Zegeven hierbij richting aanons ontwerp. We gaan inonze multidiscipl inaireteams niet uit van eenindividuele interpretatievan wie de gebruiker is,maar werken met een dooral le parti jen gedeeldegebruiker. Ze zorgenhierdoor voorgebruikersinzicht, één vanonze UX principes.

Een voorbeeld van eenveelgebruikte persona bijde Rechtspraak is GeertLeenhouts, de zelfstandigeadvocaat (zie afbeelding).

KlantreizenKlantreizen zijn een visual isatie van alle ervaringen dieeen klant meemaakt in zi jn interactie met eenorganisatie(onderdeel). Hierbi j speelt niet al leen heteindresultaat, maar de hele beleving een rol. Klantreizenkomen tot stand in workshops met eindgebruikers (ziefoto). Door actief te luisteren en door te vragen zonder testuren, wordt de klantreis uiteindel i jk het verhaal van degebruiker. We zorgen er hierbi j ook voor dat eventueleknelpunten in een proces goed zichtbaar worden.

De klantreis is voor de gebruiker wat het procesmodel isvoor het proces. Het is een reis door het systeem, niethet systeem zelf. Daarmee facil iteren we denken vanuitde gebruiker in plaats van denken vanuit IT-oplossingen.

De klantreis leidt niet langs alle detai ls, maar voert langsde belangri jkste plekken. Als het systeem Parijs is, is deklantreis een dagje Pari js. We komen niet overal, maarhet Louvre slaan we niet over. De klantreis is dus vooralbelangri jk bi j visievorming over het te realiseren product.

Samenwerken aan goede requirements met UX-instrumenten

We gaan in onze multidiscipl inaireteams niet uit van een individueleinterpretatie van wie de gebruiker is,maar werken met een door al leparti jen gedeelde gebruiker.

DREAMagazine SEPTEMBER 201 520

Het is een visie in een visuele, voor iedereenbegri jpel i jke vorm die je goed aan de muur kunt hangen.

Een voorbeeld van een veelgebruikte klantreis bi j deRechtspraak is de klantreis die we maakten om deervaringen te beschri jven van een curator van hetmoment van aanvragen van een fail l issement tot hetmoment dat het fai l l issement helemaal afgehandeld is. Inde afbeelding zie je het eerste stukje van deze klantreis.

BlauwdrukkenWaar je in een klantreis de interactie en beleving van deklant beschri jft, is een blauwdruk (service blue print) eenvisual isatie van de dienstverlening, inclusief watmedewerkers doen in de interactie met klanten, en wat,onzichtbaar voor de klant, verder gebeurt terondersteuning van de dienstverlening.

Aangezien we op ditmoment te makenhebben mettoekomstige wijzigingenin processen,wetgeving endienstverlening door deintroductie van digitaalprocederen, gebruikenwe ook blauwdrukken.In het voorbeeld (zieafbeelding) zie je eendetai l waarbij verderopin het bi j de klantreisgebruikte voorbeeldeen verzoek door decurator aan derechtbank wordtbehandeld.

Scenario’sScenario’s beschri jven onderdelen van een klantreis envarianten daarop in detai l . Gaan we met de metro of taxi,regent het of hebben we onze jas laten hangen in degarderobe van het Louvre? Het maken van scenario’s isin ons agile ontwikkelproces een onderdeel van derefinement. Als we op het voorbeeld uit de klantreisverder gaan, kun je denken aan de varianten als hetverzoek wordt goedgekeurd, goedgekeurd ondervoorwaarden, afgekeurd etc.

Met persona’s, klantreizen en scenario’s wordenrequirements vanuit gebruikersperspectief steedsgedetai l leerder. Ditvertalen we in ons mantra: ‘geen story

zonder scenario, geen scenario zonder klantreis, geen

klantreis zonder persona’.

Klikbare prototypesPrototypes zijn simulaties van het product dat jeuiteindel i jk wilt gaan maken. Voordelen van het makenvan prototypes zijn onder meer dat gebruikers en anderebelanghebbenden een beter beeld kri jgen van hetproduct dan met al leen een beschri jving in woorden.Daarnaast kun je hier al vroegti jdig potentiëleusabil ityproblemen opsporen en verbeteren. Hoe eerderin je proces je fouten opspoort en verbetert, hoegoedkoper het is.

We koppelen de prototypes aan de klantreis, door tevisual iseren welke schermen de persona ziet bi j hetdoorlopen van de klantreis. We maken ze ook klikbaar,zodat je de reis echt kunt maken in het prototype.Wanneer we bezig zi jn met verbeteringen aan eenproduct laten we hiermee zien hoe de voorgesteldeoplossing het probleem wegneemt.

Verdere detai l lering van prototypes doen we bij hetuitwerken van scenario’s. Hiermee zijn prototypes eeninstrument dat we zowel bi j visievorming als bij

refinement gebruiken.

InteractiepatronenEen interactiepatroon is een abstrahering van eenbepaalde vorm van gebruikersinteractie die op meerdereplekken terugkomt. Voorbeelden hiervan zijn: eenactieknop, een header of een paginasjabloon. Om nietelke keer het wiel opnieuw uit te hoeven vinden, hebbenwe een bibl iotheek met interactiepatronen aangelegd. Ditdraagt bi j aan een consistente gebruikerservaring, maakthet maken van prototypes gemakkeli jker, en zorgt ervoor

UX

Gaan we met de metro of taxi,regent het of hebben we onze jaslaten hangen in de garderobe vanhet Louvre? Het maken vanscenario’s is in ons agile

ontwikkelproces een onderdeel vande refinement.

We koppelen de prototypes aan deklantreis, door te visual iseren welkeschermen de persona ziet bi j hetdoorlopen van de klantreis.

User Experience 21

dat front-enddevelopment efficiënter uitgevoerd kanworden.

UsabilitytestsEen usabil itytest is een test om te zien hoegebruiksvriendeli jk het product is. Met andere woorden:kunnen mensen er mee doen waar het product voorbedoeld is. We bestuderen hierbi j gebruikers terwij l zeproberen taken uit te voeren. Dit gebeurt door getraindepsychologen. Deze test gaat dus niet over of het productgebouwd is volgens specificaties of wat de mening is vangebruikers.

Inzichten die we opdoen in een usabil itytest werken weuit in klantreizen, scenario’s en prototypes, waarmee datweer verder het refinementproces in kan. Inzichtenkunnen ook leiden tot aanpassingen in de persona’s.

UX­instrumenten in de praktijkOns UX-team bij de rechtspraak bestond nog niet zovreseli jk lang toen ons vanuit een project werd gevraagdeen prototype te maken. Het ging om een vooronderzoeknaar de mogeli jkheden van toegang tot al le relevantejuridische kennis vanuit het gebruikersportaal voor hetdigitale werken. We waren natuurl i jk vereerd, zoalsiedereen dat is wanneer hem gevraagd wordt vanuit zi jnexpertise iets bij te dragen. Wel vroegen we waarommen een prototype nodig had. Het antwoord was: “Dankunnen we laten zien wat op basis van de verzamelderequirements gemaakt kan worden”. We legden uit datdat niet was hoe we werkten, en zo begonnen we metonze pogingen om de stakeholders binnen het projectervan te overtuigen dat een prototype geen visualiseringvan requirements is, maar juist een instrument om

requirements te achterhalen. Maar voorlopig waren wenog niet zo ver. De enige mogeli jkheid was te laten ziendat het werkt.

Lijstjes met requirementsHoe je requirements ook achterhaalt: verdere analyse,specificatie en validatie is lastig vanuit droge li jstjes.Li jstjes zien er alti jd heel gestructureerd uit, maar zijnjuist daardoor lastig te valideren op juistheid encompleetheid. Ook prioritering vinden de meeste mensenlastig. Dat bleek ook in dit project. Er waren vanuit eenaantal sessies met stakeholders requirements opgesteld

in de vorm van user stories. Deze user stories zouden ineen vervolgtraject in een scrumteam gerealiseerdkunnen worden.

User stories (het verhaal van de gebruiker?)User stories zijn bedoeld om requirements op te stel lenvanuit het perspectief van de gebruiker. Ze bestaanmeestal uit een zin in een formaat als ‘Als<gebruiker(wie)>, wil ik <iets kunnen met hetsysteem(wat)>, zodat <ik een doel bereik(waarom)>’.Daarnaast horen bij een user story acceptatiecriteria,omdat één zin natuurl i jk niet voldoende is om te bepalenwat een goede realisatie is van een user story.

Klantreizen (het echte verhaal)Hoewel ons gevraagd was puur op basis van opgestelderequirements een prototype te realiseren, hielden wevast aan het eerst maken van een klantreis om vandaaruit een prototype te maken. Gelukkig lukte het onsiedereen daar van te overtuigen, al was het maar omdatwe beloofden dat we ondanks dat binnen budget zoudenbli jven.

Toen we de klantreis vergeleken met de opgestelde userstories, bleek dat de user stories voornameli jkbeschreven wat gebruikers moesten kunnen doen omhet proces te kunnen uitvoeren. Wat zij hierbi j nodighadden was geregeld over het hoofd gezien.

Een voorbeeld is dat er wel gedacht was aan het kunnenaanmaken en raadplegen van kennisdossiers, maar dathet gebruik van kennis in de context van een zaakenigszins onderbelicht was.

Scenario’s en prototypes (het verhaal komtnog meer tot leven)Toen we het prototype maakten begon het al lemaal nogmeer te leven. Bij een eerste presentatie kwamen nogmeer requirements aan het l icht. Gebruikers werdenenthousiast, omdat ze iets visueels hadden waar ze opkonden reageren en waarvan het gemakkeli jker was voorte stel len of je daarmee gemakkeli jk je werk kon doen.Ook gaf het prototype meer context aan het l i jstje metuser stories. Iedereen was nu overtuigd van het nut van

Samenwerken aan goede requirements met UX-instrumenten

En zo begonnen we met onzepogingen om de stakeholders binnenhet project ervan te overtuigen dateen prototype geen visualisering vanrequirements is, maar juist eeninstrument om requirements te

achterhalen.

DREAMagazine SEPTEMBER 201 522

het prototype, niet als del iverable en middel omrequirements te visual iseren, maar als een middel omrequirements te achterhalen, prioriteren en verfi jnen.

Werken met user story mapping kan dit waarschijnl i jknog versterken, omdat ook dit meer context geeft aan jebacklog van user stories. Met een story map geef je eenoverzicht van de mogeli jkheden van het te realiserensysteem, vanwaaruit je begint met prioriteren vanonderdelen van die mogeli jkheden. We hebben inprojecten al met story mapping gewerkt (zie foto), maarnog niet gecombineerd met een UX-instrument alsprototyping.

De samenwerking tussenrequirementsanalisten en UX expertsZoals gezegd is goede samenwerking vaak de sleutel totgoede IT-oplossingen. Goede samenwerking ontstaat

helaas nooit vanzelf. Belangri jk hierbi j is jete verplaatsen in de ander, te laten zienwat je doet en te komen tot gezamenli jkeactiviteiten die meer opleveren dan deactiviteiten apart.

Door expliciet vanuit de verschil lendeperspectieven te werken komen we totbetere requirements. Door elkaar ook opelkaars perspectief te bl i jven uitdagenwordt het nog beter. Juist daar, waar deperspectieven verschil lendeoplossingsrichtingen li jken te vragen,l iggen de kansen. Door samen op zoek tegaan naar een synthese en niet te settelenvoor compromissen waar niemand bli j vanwordt.

We doen dat door de UX-instrumenten teplaatsen naast de instrumenten uit deanalyse. Aan de kant van UX staat depersona aan de basis van alles en werkenwe via een klantreis (of blauwdruk) enscenario’s. Tegenover een klantreis staateen procesbeschri jving en tegenoverscenario’s staan epics. Samen leidt dat totstories die vanuit beide perspectieven

goede acceptatiecriteria hebben. Bij prioritering isvisual isatie essentieel. Hierin komen de prototypes enhet middel van story mapping mooi bi j elkaar.

Succes komt in stapjes, dus we zijn er nog niet. Na ditproject volgden er meer, en wisten we steeds meermensen te overtuigen. Soms lukt het gemakkeli jk, soms

niet. Wel zien we dat steeds meer mensen ons mantra‘geen story zonder scenario, geen scenario zonderklantreis, geen klantreis zonder persona’ omarmen.

Een gestructureerd proces ondersteunt desamenwerking. Door te beschri jven wat UX-ers doen inprojecten, en hoe dat samenhangt met het proces vanhet UX-team en de (door)ontwikkeling van UX-instrumenten kunnen we ons nog meer focussen op deinhoud van de samenwerking.

UX

User Experience 23

DREAMagazine SEPTEMBER 201 524

Het leuke van UXGestalt

door Wopke Postuma

Het leuke van het UX-vakgebied is dat het uit al lerlei discipl ines bestaat.De een houdt zich voornameli jk bezig met grafisch ontwerp terwij l deander zich op het ontwikkelen van persona’s stort. Zelf ben ik alti jd erggeïnteresseerd geweest in de psychologische kant vangebruikersinteractie, wat ongetwijfeld te maken zal hebben met mijnalfa/bèta-achtergrond. Het raakvlak van twee vakgebieden zoals de‘harde’ ICT en de ‘zachte’ psychologie is erg interessant.

Een van mijn l ievel ingsauteurs is Jeff Johnson, die talvan boeken op dit gebied heeft geschreven. In dit artikelwil ik graag de aandacht vestigen op een van zijnbekendste titels: Designing with the Mind in Mind. Overde ouboll igheid van de titel kan men van meningverschil len, feit bl i jft dat dit voor mij een standaardwerk isover de manier waarop de mens denkt en met computerssamenwerkt.

Na het eerste hoofdstuk duikt hi j direct al de diepte inmet een interessante verhandeling over de Gestalt-principes voor het groeperen van objecten en de rol diedeze spelen in interactie-ontwerp. Voor wie het even niethelder voor de geest staat: de Gestalt-theorie houdt zichbezig met de wijze waarop we dingen waarnemen engroeperen. Klinkt vaag? In dit artikel wil ik met een aantalvoorbeelden dit verhelderen.

Proximity ­ Nabijheid

We zullen geneigd zijn om de stippen links alsonderdeel van een en dezelfde groep te zien enrechts drie kolommen met stippen waar te nemen.Van dit principe wordt dankbaar gebruik gemaaktbij het groeperen van elementen in een formulier:

De afspeell i jsten in het midden van het formulierstaan dicht bi j elkaar en horen duidel i jk bi j elkaar.Als ze verder uit elkaar zouden staan, zoudengebruikers moeite hebben ze als een geheel tezien.

User Experience 25

Similarity ­GelijkvormigheidEen groep objecten die zich onderscheidt van andereobjecten omdat ze er hetzelfde uitzien wordt ervarenals een eenheid:

Je zult duidel i jk het idee hebben dat de objecten uiteen ri j bi j elkaar horen. Dit principe is ook toegepastop een pagina met printervoorkeuren waar degebruiker de afdrukrichting kan selecteren:

De geli jkvormigheid van de printrichtingen stimuleertde indruk dat ze tot dezelfde groep van elementenbehoren.

Continuity –Continuïteitsprincipe

We zien dit principe terug bij de zogenaamdeslider. Grafisch gezien bestaat hi j uit eenhorizontale gri jze l i jn, een 5-hoekige onderbrekingen nog een gri jze l i jn.Toch nemen we hem waarals een schuif waarvan de waarde kan wordenaangepast:

Closure – InsluitingInsluiting laat ons denken dat niet-completeobjecten toch een geheel vormen. Leuke (enbekende) voorbeelden hiervan zijn de volgendefiguren:

Hoewel de eerste figuur uit drie pacmannen endrie V-vormen bestaat, wordt de indruk van eenzes-puntige ster geschapen omdat onze hersensde neiging hebben de vormen met elkaar teverbinden.

In grafische gebruikersinterfaces wordt ditprincipe vaak toegepast in stapels. Slechts éénobject wordt compleet weergegeven; van deandere wordt al leen gesuggereerd dat ze volledigaanwezig zi jn.

Het Leuke van UX

De vorige twee principes hielden zich bezig met het fysiek groeperen van objecten. De volgende wekken deindruk dat objecten bij elkaar horen. Ze maken onze hersenen als het ware wijs dat losse objecten toch eengeheel vormen.

DREAMagazine SEPTEMBER 201 526

Symmetry – SymmetrieHet Symmetry – Symmetrie-principe gaat er van uitdat we complexe figuren alti jd zul len proberen tevertalen naar eenvoudig, hapklare brokken. Zo zullenwe deze figuur:

terugbrengen tot een kubus, en niet tot een complexevorm als:

Dit komt omdat we de figuur zo makkeli jk mogeli jkproberen te interpreteren.Een complexe tweedimensionale figuur zoalsonderstaande:

zul len onze hersenen alti jd vertalen naar individueledriedimensionale objecten.

Gestalt

Figure/Ground ­ Voorgrond/AchtergrondDit principe heeft al les te maken met het idee dat we voor- en achtergrond van elkaar onderscheiden. Om ditte i l lustreren geef ik een voorbeeld van Escher die voor- en achtergrond door elkaar heen laat lopen:

In user interface ontwerpen wordt vaak gespeeld met de achtergrond. Er wordt bi jvoorbeeld subtiel eenafbeelding in verwerkt, in dit geval een afbeelding van het Afrikaanse continent.

User Experience 27

Common Fate –Gemeenschappelijkebestemming

De vorige principes waren statisch. Het volgendeprincipe is dynamisch van aard en beschri jft datobjecten die in dezelfde richting bewegen als bijelkaar behorend zullen worden ervaren.

Het leuke van UX

All together nowMeestal worden Gestalt-principes niet geïsoleerd,maar juist gezamenli jk toegepast. Op eentypische website kun je er heel wat aantreffen:

Wopke Postuma is een ontwerper / analist met een

voorl iefde voor usabil ityvraagstukken, zoals

interactie-optimalisering en toegankeli jkheid voor ál le

gebruikers (WCAG). Hij ziet al le reacties met

belangstel l ing tegemoet: wopke.postuma@atos.net.

Meer weten?Bekijk eens:http: //www.usabil ityweb.nl/2006/05/gestaltpsychologie-en-webdesign/http: //conferences.computer.org/stc/201 4/papers/5034a062.pdf

Het boek van Jeff Johnson:http: //www.bol.com/nl/p/designing-with-the-mind-in-mind/1 001 004011 028554/

DREAMagazine SEPTEMBER 201 528

We horen collega’s soms het standpuntverkondigen dat user experience design (UX)hetzelfde is als user interface design (UI). Hoezie jij dat?

UI houdt zich bezig met de interactie tussen de applicatieen de gebruiker. Dat is wel een aspect van UX, maar dekern van UX is waarde toevoegen voor de klant. Wijvoelen ons verantwoordeli jk voor de ervaring van deklant met bol.com. Binnen het bedri jf noem ik me danook nadrukkeli jk ambassadeur van de klant. Debelangri jkste taak van de UX ontwerper is te zorgen datde klant zich thuis voelt, snapt hoe het werkt, geenvragen heeft en geïnspireerd wordt. Als het lukt om deklant de website/interface niet te laten ‘voelen’, en deproducten te laten ‘shinen’, hebben wij als UXdesignteam ons werk goed gedaan. We nemen hierbij dehele customer journey als startpunt, ook als het gaat omeen kleine optimalisatie op de pixel goed uitwerken.

In het ontwerpproces kunnen ook culturele en ethischekwesties aan de orde komen. De ethiek gaat over hetantwoord op de vragen ‘Wat is goed voor bol.com?’ en‘Wat is goed voor de klant?’. Er is regelmatig discussieover wat de beste oplossing is voor de klant. We hebbende ambitie de klant zo goed mogeli jk te informeren, zodatwe teleurstel l ingen voorkomen. Tegeli jkerti jd kan je deklant hiermee ook enorm in de weg zitten. Er isgel imiteerde ruimte om alles goed uit te leggen. Daar ziteen natuurl i jk spanningsveld. Als we teveel wil lenzeggen, lopen we het risico dat de klant door de bomenhet bos niet meer ziet.

Jullie hebben jonge en oudere, hoog en laagopgeleide klanten; klanten met veel en weinigervaring met computers. Hoe ga je met al dezegroepen om? Hoe bepalen jullie welke userexperience de klanten van bol.comverwachten? Maken jullie gebruik vanpersona’s?

We hebben persona’s, maar een persona gebaseerd oplifestyle of op segmentatie van de klantpopulatie is voorons minder bruikbaar, omdat iedereen in onze doelgroepvalt. We gebruiken persona’s vooral alsgeheugensteuntje of als designtool. In de persona’smaken we, op basis van de Myer Briggs typologie,onderscheid in vier categorieën interfacegedrag. Wedelen de bezoekers in vier kwadranten in: snel le

Customer journeyBol.com is gevestigd aan het Amsterdam-Rijnkanaal tussen de PrinsClausbrug en de A1 2, in de wijk Papendorp-Zuid in Utrecht. Debuitenkant van het pand is zwart, maar zodra we binnen zijn daalt eenontspannen gemoedeli jkheid op ons neer, die een goedevoedingsbodem is voor inspiratie en concentratie. We ontmoeten RoosGroenewegen in de royale ontvangsthal. Zi j is teamleider van het UXdesignteam en neemt ons mee naar de plek waar de look and feel vande webwinkel worden bepaald. Ons gesprek zal gaan over hoe bol.commet user experience omgaat.

Interview

door Reinoud de Leve en Hans Siebering

De kern van UX is waardetoevoegen voor de klant

Een persona gebaseerd op lifestyleof op segmentatie van de

klantpopulatie is voor ons minderbruikbaar, omdat iedereen in onze

doelgroep valt.

User Experience 29

tegenover langzame beslissers en beslissers op basisvan feiten tegenover beslissers op basis van gevoel.

Ook doen we gebruikersonderzoek. We hebben eenusabil ity lab. In dat lab nodigen we respondenten uit, diewe onder begeleiding van een moderator observeren opinterfacegedrag. We gebruiken de Think Loud methode:mensen moeten hardop denken en beargumenteren watze doen. De moderator stelt bi jvoorbeeld de vraag: stel jeman is jarig en je wilt een cadeautje kopen rond eenbepaald thema, hoe zou je dat doen? We observerendan hoe de gebruiker navigeert.

Maar primair zetten we bij bol.com sterk in oppersonalisatie. Dat betekent dat we bijvoorbeeld op basisvan het gedrag van anderen zoals j i j of je eerdereaankopen je passende aanbevelingen doen. Op diemanier wil len we de klant op individueel niveau eenwinkel aanbieden die het beste aansluit op zijn behoeftesvan dat moment. Dit beïnvloedt de manier waarop weontwerpen. Dit gaat steeds meer over sl imme enschaalbare templates creëren waarin de content,producten of informatie die we daarbinnen aanbiedenvariabel is.

Hoe ontstaan nieuwe ideeën voor hetverbeteren van de user experience?

Naast gebruikersonderzoek, doen we expert reviews van

de huidige situatie. Bij het door ontwikkelen vancategorieën met nieuw assortiment worden erfocusgroep sessies georganiseerd door de afdelingpropositie. Dat zi jn gesprekken met mensen over hunleven, waar ze behoefte aan hebben en wat mensenverwachten van bol.com.

Al deze activiteiten leveren een overdaad aan ideeën op.Deze ideeën worden op businessvalue geprioriteerd.Vervolgens start het zoeken naar de juiste oplossing dooreen ontwerper met een analyse van het huidig gedragvan klanten en een onderzoek naar de ontwikkelingen inde markt. Dit doen we door het ki jken naar soms wel 20of 30 andere websites. Conventies zijn een ergbelangri jke driver voor een goede UX.

Wat is de rol van UX in de uitwerking vanideeën?

De UX afdeling bestaat uit ongeveer 40 mensen. Ik bende teamleider van het UX designteam, daarnaast is ereen team UX-Business Analisten en een aantalStrategen en Productowners.

Het UX designteam is vormgever van alle interfaceelementen op de website, behalve van de ti jdel i jke,actiematige delen. De visuals en de content worden dooranderen gemaakt, het stramien komt van ons. Binnen hetteam zijn we opgedeeld in themagebieden: ShoppingExperience, UX Improvements (al les vanaf hetwinkelmandje) de Verkoper UX (onze verkoperomgeving)en Cross Device.

Wanneer een plan wordt opgepakt, dan inventariserenUX-Business Analisten de wensen van de business. Zeverzamelen alle kennis die we hebben over het gedragvan de klant in relatie tot de vraag en toetsen detechnische mogeli jkheden met IT. Met deze kennishelpen ze de ontwerper beslissingen te maken in hetontwerpproces. Uiteindel i jk is de deliverable voor eenUX-business analist een aantal userstory’s binnen de

Roos Groenewegen

Roos Groenewegen is sinds 201 3 teamleider van het ux-design

team bij bol.com en al bi jna 1 5 jaar met passie bezig met user

experience. Naast werkzaamheden als ontwerper, is ze in 2003

gestart met lesgeven. Zo raakte zij betrokken bij het vormgeven van

het hbo-onderwijs tot user experience designer (opleiding CMD) en

heeft ze meegewerkt aan de ontwikkeling van het bijbehorende

landeli jk competentie profiel . Daarna heeft ze overstap gemaakt terug

naar de prakti jk. In 2008 kreeg ze de kans inhoudeli jk vorm te geven

aan een van de eerste ux-teams in Nederland op de afdeling online

bij de ANWB. Vanuit daar was het een geweldige uitdaging om

hetzelfde te gaan doen, maar dan bij de grootste e-commerce

organisatie van nederland, bol.com. Ze is vrol i jk en enthousiast over

al le kansen bij bol.com en geeft graag een kijkje in de ux-keuken.

Als het lukt om de klant dewebsite/interface niet te laten

‘voelen’, en de producten te laten‘shinen’, hebben wij als UX

designteam ons werk goed gedaan.

DREAMagazine SEPTEMBER 201 530

Interview

epic die antwoord moet geven op de vraag. Ook kan hetzi jn dat de UX-Business Analist op basis van eenhypothese een voorstel doet voor het inrichten vanbijvoorbeeld een AB-test.

Werkt het UX designteam alleen aan dewebsite of houden jullie je met het hele procesbezig?

Onze verantwoordeli jkheid begint op het moment dat deklant op bol.com landt. Wij houden ons niet bezig met tvcampagnes of (inspiratie- of reclame-) mail ings.Hetzelfde geldt voor het after sales proces: de klant heefteen bestel l ing gedaan en kri jgt een bedankmail , hi j of zi jwordt geïnformeerd over de bestel l ing. We adviserenhierin, de eindverantwoordeli jkheid l igt elders in deorganisatie. Wij overzien dus wel de hele customerjourney, maar zijn eindverantwoordeli jk voor deklantervaring op de website.

Als bol.com een nieuwe dienst, product offunctionaliteit gaat aanbieden, wanneer gaanjullie dan nadenken over de user experience enhoe gebeurt dat?

Het idee kan bij UX ontstaan, maar ook bij bi jvoorbeeldBusiness Development, de Categorieën of Logistiek. Alleideeën komen in het innovatieproces. Daar worden zegeschat op business value en technische impact en naprioritering als epic op een roadmap geplaatst. Wehebben 35 scrumteams, die elk een eigen roadmaphebben. Driemaal per jaar worden de prioriteitenopnieuw gesteld. Wij zi jn vaak al betrokken bij deontwikkeling van een eerste business case. We werkendan een denkrichting uit en bepalen de relatie metandere plannen. De epics worden, nadat ze bij ons op deplanning zijn gekomen later uitgewerkt in user stories.Dat is het moment waarop het ontwerpproces van startgaat.

Kun je een recent voorbeeld geven van eenverrijking van de gebruikerservaring opbol.com?

We hebben onlangs sociale l i jstjes geïntroduceerd:iemand kan een li jstje met producten maken, dat hi j of zi jgraag wil delen met anderen. Dat l i jstje wordt gekoppeldaan de producten en zo kun je navigeren door hetproductassortiment van de winkel. Onze ambitie is omklanten veel meer een rol te laten spelen in het verri jkenvan de winkelervaring. Klanten kunnen ook elkaarinspireren. Stap 1 is: zorgen dat je een li jstje kunt maken.Die stap is nu gerealiseerd voor experts. Als jebijvoorbeeld hardloopfanaat bent, kun je een li jstjemaken met boeken, drinkflesjes, schoenen, shakes,kleding, etc. , waar je goede ervaringen mee hebt.Wanneer dan een klant op die schoenen terecht komtkan die jouw li jstje bekijken (onder het kopje ‘Laat jeinspireren door onze experts’) en geïnspireerd wordenom een boek te gaan lezen dat j i j hebt aangeraden. Zomaken we gebruik van de wisdom of the crowd. Del i jstjes worden gemaakt door experts, bloggers,verkopers, onze eigen productspecial isten en iedereendie zi jn of haar l i jstjes wil delen.

De epics worden, nadat ze bij onsop de planning zijn gekomen lateruitgewerkt in user stories. Dat is hetmoment waarop het ontwerpproces

van start gaat.

User Experience 31

Hoe ben je met dit boek in aanrakinggekomen?

“In een aantal boeken die ik de laatste ti jd heb gelezen,werd dit boek aanbevolen. Op een gegeven momentwerd het haast onvermijdel i jk dit boek te lezen”. JosWesterink heeft twee andere boeken meegenomen. Hijlegt ze voor zich op tafel naast het boek van CarolDweck. Het zi jn 'Switch' van Chip en Dan Heath en'Feedback is een cadeautje' van Douglas Stone enSheila Heen.

“Wat ik bijzonder aan het boek Mindset vind, is dat hetmij echt heeft veranderd. Door dit boek ben ik anderstegen persoonli jke ontwikkeling gaan aankijken. Ik bendingen gaan doen die ik zonder dit boek niet zou hebbengedaan. Dat is toch uitzonderl i jk dat een boek zoveelinvloed op je heeft.Laatst was ik met de famil ie een weekendje in Zeeland.Mijn kinderen hadden een waveboard meegenomen.Vóór het boek zou ik waarschijnl i jk gedacht hebben datik daar te oud voor was. Ik had niet onderuit wil len gaanals een soort Balkenende op een skateboard. Die afganghad ik me wil len besparen. Nu keek ik daar anderstegenaan. Ik was benieuwd of ik het zou kunnen leren. Ikhoefde niet per se direct te kunnen waveboarden. Ik koner ook plezier aan beleven door het te proberen. Kijkenhoe ver ik kwam. Het leuke is dan dat je veel meer kuntdan je van tevoren denkt. In het begin was het wel lastig,maar na wat oefenen bli jkt waveboarden helemaal nietzo moeil i jk te zi jn. ”

Hans heeft een zelfde ervaring bij het piano spelen.Vroeger gaf hi j eerder op als hi j moeite had met hetspelen van een pianostuk. Hij dacht dan dat het te hooggegrepen voor hem was. Hij schoof het terzi jde met degedachte: “Dit wordt nooit wat”. Dan speelde hij l ieveriets dat hi j wel kon. Na het lezen van het boek is hi jmoeil i jke stukken meer als een uitdaging gaanbeschouwen. Hij hoeft het niet in een keer foutloos tespelen, maar hij probeert steeds iets te verbeteren. Hijmerkt dat hi j nu meer grip op zijn pianospel kri jgt. Hi j istevreden met de vorderingen die hij maakt. Zi jn foutenbetekenen niet meteen dat hi j geen ‘getalenteerd’ pianist

MindsetIn deze serie interviews spreken Hans Siebering en Reinoud de Levetelkens met een collega requirements engineer naar aanleiding van eenartikel of een boek dat hem of haar inspireerde. Deze keer spreken zemet Jos Westerink – informatieanalist bi j bol.com – over het boek‘Mindset, De weg naar een succesvol leven’ van Carol S. Dweck.

Jos Westerink

door Reinoud de Leve en Hans Siebering

Het centrale idee vanhet boek van Dweck isheel simpel. Mensenkunnen volgens haarnaar zichzelf kijken meteen statische of meteen op groei gerichtemindset.

Als je naar jezelf kijktmet een statische mindset zie je succesvooral als het resultaat van jouw uniekeeigenschappen. Je bent ergens goed in,omdat je daar het talent voor hebt. En alsje fouten maakt, dan heb je daarkennelijk geen talent voor. Een statischemindset werkt op den duur verlammend:niemand doet graag dingen waar uit zoukunnen blijken dat hij geen ofonvoldoende talent heeft.Is je mindset op groei gericht dan zie jesucces vooral als het resultaat van jeinspanningen. Je unieke eigenschappenzijn minder bepalend voor je succes. Alsje er zo tegenaan kijkt, wordt lerenbelangrijker dan kunnen. Het is veelminder erg dat je iets nog niet goed kunt.Iemand met een op groei gerichtemindset wil juist wel graag dingen doenwaarvan hij op voorhand niet zeker is ofhij het wel kan. Voor hem zijn hetuitdagingen, mogelijkheden om iets teleren. Ook is het maken van fouten veelminder erg; je kunt jezelf immers nietontwikkelen zonder fouten te maken.

DREAMagazine SEPTEMBER 201 532

is. Hi j vindt zelfs van zichzelf dat hi j beter piano speeltdan vroeger.

Belemmerende overtuigingen

Jos vertelt dat een KNO-arts hem laatst uitlegde dat wijvolwassenen duizel ig worden van koppeltjeduikendoordat wij dat te weinig doen. Als wij net zo vaakzouden koppeltjeduiken als kinderen dan hadden wehelemaal geen last van duizel igheid.“Dat is toch opmerkeli jk. De meeste mensen denkenvermoedeli jk dat ze duizel ig worden van koppeltjeduikenomdat volwassenen daar te oud voor zijn. Het l ichaamkan het niet meer aan of zo. Maar dat is dus helemaalniet waar. Het is al leen maar een belemmerendegedachte.

Aan belemmerende overtuigingen heb ik me alti jd algeërgerd. Mensen die zeggen: ’ Ik ben niet technisch’. Endus kunnen ze geen stekker aan een snoer zetten.Terwij l je daarvoor ongeveer even technisch moet zi jn alsom je veters te strikken. Maar hoor je ooit iemandzeggen dat hi j zi jn veters niet kan strikken, omdat hi j niettechnisch is? Een beter voorbeeld van een statischemindset kun je bijna niet geven. In ons vakgebied zie jeook vaak dat mensen zich verschuilen achter dat ze niettechnisch zijn. Zi j doen dat dan soms met enig dedain.Zo van: techniek is mijn ding niet, als ik technisch zouzijn geweest, dan had ik ook wel een rare bri l op.Jammer, want daarmee sluiten ze zich alleen maar afvan dingen die ze heel goed zouden kunnen begri jpen.”

Kritiek op het boek

In het boek wordt de op groei gerichte mindsetgepresenteerd als een soort ‘cure for all’. Hetboek bevat een heleboel voorbeelden dieeigenlijk allemaal op hetzelfde neerkomen.Iemand heeft een statische mindset. Ondankszijn talenten loopt hij op een gegeven momentvast. Hij komt niet meer verder totdat hij leertnaar zichzelf te kijken met een op groei gerichtemindset. Dankzij die veranderde houding weethij zich verder te ontwikkelen en groteresuccessen te behalen. Is dat niet een beetjeongeloofwaardig?

“Inderdaad, het idee van het boek wordt nogal repetitiefgebracht. Op den duur gaan al die voorbeelden jetegenstaan. Het is wat dat betreft een ‘Amerikaans’ boek.Ook las ik reviews die haar wetenschappeli jke onder-bouwing betwisten. Al is haar idee aantrekkeli jk enplausibel, daarmee is het natuurl i jk nog niet waar. MaarCarol Dweck is een wetenschapper. En bij dit soortboeken vertrouw ik een wetenschapper als auteur snellerdan een journalist. Een wetenschapper kan er immersmee zijn wetenschappeli jke reputatie verspelen.

Ik vind het jammer dat zi j in het boek niet veel verdergaat dan met een heleboel voorbeelden uitleggen wathet verschil is tussen een statische en een op groeigerichte mindset. Als je stelt dat het belangri jk is om eenop groei gerichte mindset te hebben dan roept dat nogalwat vervolgvragen op. Kun je niet op het ene gebied eenop groei gerichte mindset hebben en op het anderegebied een statische? En is dat dan erg? Is het welwenseli jk om op alle gebieden een op groei gerichtemindset te hebben? Helpt het inzicht in je talenten jemisschien juist, om te focussen? Je kunt je uiteindel i jkniet in al les ontwikkelen? Dan li jkt het handig om in iedergeval te weten waar je van nature al goed in bent. Overdit al les zegt ze niets.

Interview

Door dit boek ben ik dingengaan doen die ik zonder dit

boek niet zou hebben gedaan.

User Experience 33

Het boek zegt ook niets over de omstandigheden of deomgeving die nodig zi jn om te kunnen groeien.”

Leren in kleine stappen

Hoe denk jij daar over? Wat zijn volgens jou deideale omstandigheden om te kunnen groeien?

“Ik denk dat het erg belangri jk is dat je niet te grotestappen ineens moet wil len zetten. Ik zit bi j bol.com ineen Scrum team. In een Scrum team is het de bedoelingdat ieder teamlid meerdere rol len kan uitvoeren. Het heleteam is verantwoordeli jk voor het opleveren van een stuksoftware. Natuurl i jk heb je nog steeds mensen die beterin het één zijn dan in het ander, maar bij Scrum kun je jeniet meer helemaal terugtrekken in je rol. Maar ik heb aleen hele ti jd niet meer geprogrammeerd. Als ik dan naaronze programmeurs kijk, denk ik weleens dat het nogeen hele stap is voordat ik echt toegevoegde waarde ophet gebied van programmeren zal hebben. Een taakwaar ik een dag over doe, doet een ervaren program-meur in een uur. Dan voelt veranderen ineens moeil i jk.

Het boek Switch, dat ik jul l ie zonet l iet zien, gaat overhoe veranderen werkt. In Switch wordt de metafoorgebruikt van een olifant met een beri jder die loopt overeen pad. De olifant staat voor het gevoel, de beri jdervoor het verstand en het pad voor het gemak vanverandering. Het boek legt uit dat de beri jder (hetverstand) wel een richting uit kan wil len, maar dat deolifant (het gevoel) dat niet doet als hi j de stap te grootvindt.

Ik moet heel goed voor mezelf duidel i jk hebben wat ikstap voor stap wil bereiken. Je moet daarom om teveranderen niet al leen een op groei gerichte mindsethebben, maar je moet ook goed nadenken over kleine,bereikbare veranderingen.Gelukkig is door de vaste rituelen van Scrum deaandacht meer op veranderen gericht. In deretrospective merk ik dat een kleine concrete verbetering

voor de volgende sprint beter werkt dan een groteverbetering. Ook vanuit een psychologisch perspectief ishet een pluspunt van Scrum dat je voortdurend kleineaanpassingen doorvoert.

Daarnaast is meteen herhalen belangri jk. Een voorbeeld.Ik regel de scheidsrechters voor de hockeyclub van mijnkinderen. We hebben een tekort aan goedescheidsrechters. Dat komt vooral doordat de meestescheidsrechters te weinig en onregelmatig fluiten.Daarom zet ik de scheidsrechters bij voorkeur meteeneen paar wedstri jden achter elkaar in. Je ziet dan dat zeal een stuk beter gaan fluiten. Dat mechanisme werktnog sterker in ons vak. Als wij maar heel af en toe ietsprogrammeren, worden we daar nooit goed in.”

Feedback op fouten

“Misschien is de manier waarop de omgeving feedbackgeeft nog wel het belangri jkste. Daar heeft Carol Dweckhet wel uitgebreid over in haar boek. Als je iemandstalenten pri jst of het gevoel geeft dat hi j geen fouten magmaken, dan plaats je diegene in een statische mindset.

Gelukkig gaat dat bi j bol.com beter. Laatst had eencollega een best ernstige fout gemaakt. Hij had perongeluk een verkeerd script gedraaid op de productiedatabase. Het werd bij ons besproken in een meeting.De reactie van het management was toen ‘Jongens hetis helemaal niet erg dat er fouten worden gemaakt, alswe er maar van leren’. Dat is feedback die uitnodigt omeen op groei gerichte mindset te hebben.“

Misschien is de manier waaropde omgeving feedback geeftnog wel het belangri jkste.

Jos Westerink

DREAMagazine SEPTEMBER 201 534

Ontdekken

Net gezienDe lol van (ver)dwalen is om onverwacht een prachtige plek teontdekken. En mocht je zelf moeite hebben om zo’n plek te vinden, danzijn er gelukkig alti jd mensen die je de goede richting wil len wijzen. Datis wat wij met deze rubriek wil len doen. Hier zetten we de wegwijzersneer om jul l ie de plekjes op internet te laten ontdekken waar het goedtoeven is voor de requirements engineer. Deze keer richten we ons opUser Experience, het thema van dit nummer van het DREAMagazine.Heb je zelf nog mooie plaatsen bezocht die je wilt delen? Laat het onsweten: dreamagazine@dreamevent.nl .door Johan Oldenziel

De website UXmastery1 geeft een goed overzicht vanalle stappen die van belang zijn bi j het vormgeven vande User Experience. Klik bi j deze site ook op de tabsvoor technieken, templates en tools. In het onderdeeltemplates vind je een fl ink aantal documenten van SteveKrug over Usabil ity Testing. Steve is een goeroe op ditgebied.

Maar nu ben ik alweer bij het onderdeel testen, terwij l wenog zoveel andere fasen hebben te doorlopen. Allereerstzul je onderzoek wil len gaan doen.

Maak hiervoor een plan en houd daarbij deze punten2 inhet oog als je het research-plan gaat schri jven. Sommigepunten zijn open deuren, maar zeker niet verkeerd alschecklist. En als je dan echt onderzoek gaat doen, heeftde Usabil ity-site3 een uitgebreide l i jst met technieken dieje kunt gebruiken bij het doen van je research. Dit is eenheel goede site, verzorgd door een Amerikaansministerie.

Na de analyse-fase komt het design. Ook in die fase bli jfje contact houden met je eindgebruiker, en bli jf je vragen

1http: //uxmastery.com/resources/process

2http: //www.smashingmagazine.com/201 2/01 /26/ux-research-plan-stakeholders-love/

3http: //www.usabil ity.gov/what-and-why/user-research.html

4http: //uxmovement.com/thinking/the-art-of-questioning-as-a-ux-skil l/

User Experience 35

stel len4. Ook op UXmatters5 vind je info hierover – enover veel meer. Steve Krug schreef over interactiondesign het boek “Don’t make me think” over hoeinteractie met een website intuïtief dient te verlopen6. Ditboek is verpl ichte kost in interactie design trainingen. Zieook zijn presentatie7 en zijn fi lmpjes op YouTube.

Hierboven heb ik de test fase al benoemd, je vind meerop de website van Online Behaviour8. Steve Krug heeftvoor de testers van usabil ity het boek “Rocket surgerymade easy” geschreven.

Op Usabil itygeek.com9 vind je ook veel info en veelblogs, dus lekker veel meningen.

In Nederland heb ik niet zoveel gevonden. WelInformaat1 0, met een groot aantal blogs over al les watmet een goede website samenhangt. Omdat hetontwerpen van websites zich focust op de gebruiker,wordt er veel gebruik gemaakt van persona’s. Alsalternatief hiervoor wordt experience mappingaangedragen11 . Oordeel zelf.

Verder vind ik nog Ferry den Dopper, ook al l i jkt hi jinmiddels gestopt te zijn met zi jn blog. Ik ben vooralgecharmeerd van tips & tricks1 2. Mooi dat hi j hier ookweer een link naar User Stories legt, we zullen het tochallemaal samen moeten doen! Op de site van zijn nieuwewerkgever vind je wel een prachtig vormgegeven blog1 3.Je ziet wat hun beroep is . . .

Zo, ik denk dat je nu wel genoeg om te lezen hebt dekomende ti jd!

Net gezien

5http: //www.uxmatters.com

6http: //www.uxbooth.com/articles/1 0-usabil ity-lessons-from-steve-krugs-dont-make-me-think/

7http: //www.sl ideshare.net/SteveKrug/steve-krug-explains-it-al l-for-you-sxsw-2011 ?related=2

8http: //onl ine-behavior.com/testing

9http: //usabil itygeek.com/tag/user-experience/

10http: //www.informaat.com

11http: //www.sl ideshare.net/fred.zimny/adaptive-paths-guide-to-experience-mapping

12http: //www.den-dopper.com/201 2/09/04/4-tips-om-toegankeli jkheid-eenvoudig-in-te-passen-in-je-ontwerpproces/#more-1 545

13http: //www.tamtam.nl

DREAMagazine SEPTEMBER 201 536DREAMagazineDutch Requirements Engineering And Management SEPTEMBER 201 5

.