New feature - Contact Details

This page describes the steps we took to test the new contact details feature as well as the conclusion of the user tests

User tests

Introduction

These usertests were conducted to test the new contact details feature. Additionally, we also asked the users some questions about their filter behaviour when searching for organisations. The conclusions of that part of the usertesting can be found on Usertering - Filter behaviour.

Participants

For these user tests, we have worked with users of the Worship services part of the Organisation Portal, as well as KAR members who will be using OP in the future.

The KAR users hadn't used OP in prior to the sessions

We held 5 sessions:

• 1 session with 3 LOW members (Worship services)

• another session with 3 LOW members (Worship services)

• 1 session with 3 members of LSVP (KAR)

• 1 session with 3 members of LF (KAR)

• 1 session with 3 members of LF (KAR)

Test

Each session was done the same way:

Every participant took turns to share their screen and try a scenario (3 in total) in QA, which would test one part of the new feature.

The scenarios can be found in a spreadsheet [NL]

The interesting [new] thing about our way of working for this user test, is that we screen-recorded the sessions. This was great because:

• we didn't have to worry about forgetting to write something down

• we can rewatch the sessions

• it helps with identifying bugs as we can rewatch the steps taken by the participant

• we can use these recordings to find out other behaviours (e.g. how does a user interact with a date picker)

  • This has been noted down in a different Gitbook page: Usertesting - User interactions

Conclusions

The items in this table ONLY relate the the new contact details feature. Other items we have found during these sessions which we should consider for a better UX, but that aren't related to this feature are described in User Interactions.

Underneath the table, you can also find notes on the different sessions, which quotes from users, or transcriptions of steps taken by users during the tasks.

Item	Priority	Jira ticket	Details
Modal needs to work for smaller screen types		OP-1490	see screenshots in notes for examples of the problem
Selecting address in modal - then having to save		OP-1491 = POC	Ideally, we would do a technical analysis and see if we can sort the problem by not having to do this in 2 steps. If this is not possible we will solve the problem with design.
Users have the reflex to update exiting data rather than creating new data sets		refinement ticket or training of editors? To discuss with Yassin Boullauazan 🅿️ Added ticket to the parking	Is this because it is more likely to be updated in their context? Or is this a problem?
Users try updating contact details via contactdetail page		ON HOLD OP-1492 technical refinement story?	Should we bring back the edit mode for contact details on this page? IIRC the reason we took it out was because it was very tricky to make.
Users expect the Provincie to be filled in automatically when the address is filled in		OP-1504 = Improvement story to contextual dropdown in the address. In DEV the province is filtered in the dropdown (OP-1350), but you still need to select it.	This is not a bug in the current version, but would add to the user experience
"Voeg toe" button to change to "Opslaan"		NOT FOR NOW, we wait for other end users to say the same. 🅿️ Added ticket to the parking.	This is not a bug, but some users reported it being confusing that it wasn't called "Opslaan" -- this could be because Design asked the users to Save rather than Add during the tasks, but it could also be that Design used those words because subconsciously that made more sense

Notes from every session

Session 1

First scenario

• Create new person: OK

• Uses CRAB to look for address

• Add new position: OK

• Changing address: Using CRAB OK

• Did it save? [select v. save] - only clicked on select and assumed that the info would be saved

• Tried again, failed completely as they tried to do it via the contact information page, which has view-only for contact information -- needs help to get onto the right page

• Assumed it was changed on the position detail page but not on the contact details page

• Mentioned the breadcrumbs being from the organisation even though then were on the person (confusing)

• When trying a second time, used manual input to change the house number

• We explained the difference between selecting and saving and they understood and it made sense

Second scenario

• Updating address for both positions

  • comments about having to do it twice before trying (shows how annoying users found this)

• easy to update

• happy that it happens automatically for both positions

Third scenario

• Adding existing person: OK

• Asks whether to create new contact details or update existing ones

• Other person thinks the reason for this is to see a history of contact data - not multiple data sets per person

  • we clarify this

  • One person still thinks this is unnecessary

  • we use an email address as an example instead of an address- makes more sense when clarifying some more

  • It's good that it got asked because the first reflex would be to update existing, not create new!

• changing contact sets: OK

• extra screen: OK

Other notes

• "Het is een super super super ding dat jullie gedaan hebben"

• "Het blijft maar verbeteren, we zien het groeien"

• +32 in front of a phone number is a bit.... we all live Belgium, don't we!

• PDF for rapports available?

• "Het wijst allemaal z'n eigen uit"

• "Ik vind het een fantastisch instrument"

Session 2

First Scenario

• Writing Gemeente correctly gave "geen resultaten" --> takes a while to load

• goes to Bewerk on bestuursorgaan instead of going to the detail page

  • after explanation - OK

• "add a new person" --> tries to search for an existing person first

  • this is a good reflex, to not create duplicates

• adds new person - OK

• adding new contactdata - OK

  • CRAB didn't find address when user didn't write hyphen in the address

• checks contactdetails on contactdetail page - not position detail page

• to update contactdata, the user went back from the position detail page to the contact detail page

  • not possible to edit contact info there

    • when we explained that contact details belong to a position and not a person the user said this was a little bit weird, but managed to find his way back to the position detail page to edit

• the modal is really small on this screen and it gets harder to fill in/read

  • 
• "Why does it ask me to Select? That's weird"

  • after explanation --> OK

    • I understand it now, but it's still weird.

    • It's then really important that the user doesnt forget to save it properly and this might happen

    • The fact that the button says "select" is good because it's obvious that it's not saved yet

    • Is it not possible to change the technical side of things? - e.g. "select & save"

Second scenario

• update contactinfo for voorzitter

  • went to the right page but thought he was wrong

  • tried again and sees it

  • corrigeer - OK BUT

    • modal is SO SMALL it's really hard for the user to use - had to help navigate this screen because it was so small

      • 
    • Does the provincie not fill in automatically?

  • Forgets to save the page after select

    • other users in the session do realise this

  • wants to continue with task and change address for other position

  • sees that it happened for both

    • question - can we add this system to change the end date for both positions if its within one bestuursraad (get the chose to do this rather than automatically)

Third Scenario

• adding new contact details

  • tries corrigeer

  • do you see corrigeer and nieuw aanmaken as the same thing or different?

    • --> to me it's more logical to change existing as you can only live in one address at a time

    • What about a different email address?

    • understands but seems a bit iffy about it

  • easy to fill in - OK

  • other users know straight away that you need to save

  • --> user would want to delete the other row in the contact detail table

    • explaining then OK

• changing contact details to match all three

  • starts with changing email for predikant - OK

  • new page

    • is this ok?

      • --> YES makes sense.

      • forgets to select in the table

        • explain --> OK

Other notes

• nothing for now

Session 3

First Scenario

• writes "st." fully as "sint" and can't find the right organisation because the search function can't work with this --> user also brings this up

• Creating new person - OK

• adding contact details - OK

• updating wrongly input data - OK

Second scenario

• changing address for two positions

  • can't save

    • --> this is the first time we saw the chrome bug which made us stop the sessions until it got fixed

• other user takes over - tries to change contactdetails from contactdetails page which is read-only

• finds the correct page

• updates address - OK

Third scenario

• adding third position

  • goes to bewerk on a different position --> wanted to create a new position from there "I want to copy him actually"

  • finds the existing way to add a person - OK

  • Add new contactdata - OK

    • "I think it's weird the provincie isn't filled in automatically"

• changing data of 2 positions to match third

  • tries to change contactdetails from contactdetails page and finds it annoying that it isn't possible

  • new page

    • "oh this is interesting!"

    • easy to understand - OK

Other notes

• "Voeg toe" could change to "Save", not sure voeg to makes sense

  • --> Note from design: This might be because I told the users to "save" rather than "add" during the session?

Session 4 (+ 4 bis)

First Scenario

• adding new person

  • tries to enter bestuursorgaan through edit instead of clicking on the name

  • writes name in search field but decides last minute to create a new person

  • adding contact details - OK

  • second guesses clicking on voeg toe (this might be because design said "you can now save" instead of "you can now add this person")

• updating address

  • changes address manually rather than through CRAB

  • selects --> do you think it is saved now?

    • i don't know, maybe? yes?

      • not ideal

      • "is the button called Save? because earlier it was called "Voeg toe"

        • --> user thinks Voeg toe is confusing

      • --> chrome bug reproduces

--> session paused until bug is fixed

--> 4 bis

Second scenario

• updating contactdata for 2 positions

• updates for first position - OK

• EASY

Third Scenario

• Adding third position - OK

  • adding new set contact dat to new position - OK

• when adding date for position - maybe there was an option for "geen geplande einddatum"

• changing addresses of 2 position to fit third

  • "it should be working all on one page"

  • goes to kerngegevens of the organisation and clicks edit

    • --> realises he's not on the correct page

  • goes to kerkraad

  • clicks on the name of a person and tries to change the contact information of all 3 position in one place --> realises this is read-only

  • goes back to kerkraad

  • clicks edit for a specific position

  • selects correct row in table

  • save

  • new page

    • does this make sense?

      • yes, understands perfectly and does it

  • ALL GOOD