🆔Feature Passport [01/2021]
This feature passport contains all information necessary [available up to date] to build the module Personen
Status Feature Passport
| STATUS | OWNER | DATE |
|---|---|---|
In proposal | Saska | 10/01/22 Edited by Yassin: 9/2 |
In refinement - Design Research | Saska | 21/01/22 Edited: 01/02/22 Edited: 07/02/22 Edited: 10/02/22 Edited: 14/02/22 Edited by Sofie: 18/02/22 |
In refinement - Technical Research/Feedback | Nordine | 24/01/22 |
In development | ||
In QA/ Testing | ||
In Final state |
Analysis
Current state
Currently, the Module: Personen includes:
A search page (user can search and filter persons but not create any data - only showing one position per person, and only showing positions of type: mandate)
Detail pages per person
2.1. A personal information page (user can view and edit personal information, incl. request to see sensitive data
2.2. A contactinformation page (user can view available contact information for active positions)
At the moment of writing, not all contactinfo is viewable, because some positions are not shown
2.3. A positions page (user can view all the positions [of type: mandate] a person has or has had)
2.3.1. A detail page per position (user can view details about a position including a card with contact information for positions that are active)
🤩 Expectations
In this feature passport, we will tackle these future expectations:
1. Search page
Following the logic of the search page for bestuurseenheden, the user should now be allowed to create a person from the search page.
The filters available on the search page need to be revised to best serve the needs of the user
The columns available in the table need to be revised to best serve the needs of the user [OUT OF SCOPE - Added to Parking]
The rows in the table should include every position for every person
Pre-select active positions to reduce clutter, as those will be searched for the most
2. Detail pages per person
2.1. Personal information & 2.2. Contact information pages
Previous user research [link where this is documented missing] has shown that users expect to see contact information on the personal information page, we should accommodate this (note: we only keep contact information for active positions)
The [current] contact information page is not needed anymore as this information will be available on the [current] personal information page
The personal information page is to be renamed to: Contact Information, as the two pages merge together. * From this point onwards, this feature passport will now be referring to "Contact information page" to talk about the merged version
2.3. Positions page
Add the option to create positions from this page
Show all types of positions in one table
The columns available in the table need to be revisited to best serve the needs of the user [OUT OF SCOPE - Added to Parking]
2.3.1. Positions Detail page
Add the option to edit the details of a position
Solution
Design
User research
We are conducting user research to find answers to the following questions raised in the expectation part of this feature passport:
1.Search page
The filters available on the search page need to be revisited to best serve the needs of the user
The columns available in the table need to be revisited to best serve the needs of the user [OUT OF SCOPE - Added to Parking]
2. Detail Page: Positions page
The columns available in the table need to be revisited to best serve the needs of the user
Information and details about this usertesting can be found on the Usertesting: Module personen page
User Research Conclusions:
For this feature, we are adding the following filters for the search page:
Name
Organisation (start typing then -> drop-down)
Position (drop-down)
Add an active-inactive filter
We will also merge Persoonlijke gegevens with Contactgegevens. The new name will be: Contactgegevens
As there are a max of 3-4 active positions per person, and usually only 1-2, we will show contact information in a card. The newest position at the top.
Posities & Positie detail page
No changes needed for this feature passport design-wise. All positions will be listed, both the inactive and the active ones. The positions should be listed chronologically, with the newest ones at the top.
Mock-ups
Full figma file for persons module
Using the information found in the user research as well as design best practices, these are the proposed mockups for this feature passport:
Search Page
Only showing active positions:
Also showing inactive positions:
Creating a person from the search page
To create a new person, the user must create a new position. (This is because the search page shows all positions, so if we create a person without a position, they won't show up anywhere.)
To create a new position, the user clicks on "Nieuw" in the top-right of the search page (Step 1), where he is presented with a screen to choose a bestuurseenheid to add the position to. (Step 2). The user also chooses the type of position.
If the type is a Bedienaar then the user goes top the next step (Step 3)
If the type is a Mandate, then the user has to first select what governing body the mandate belongs to as well as a governing period. The technical reason for this is explained in the technical solution part of this feature passport.
All the governing bodies (GB), which includes also the inactive GB's are shown in the dropdown lists. Why, because we still have a lot of data of non-active GB's in the SharePoint lists, which might be entered in the OP later. The business is focusing now on adding the data of the active GB's.
2. How to display the "Bestuursperiode*" dropdown of GB's with no start- and/or end date?
option 1 = add the missing dates (We can't add the dates because they are unknown)option 2 = input 1/1/1900? (not a good solution, discouraged by Boris)option 3 = show available dates, examples:
start date is empty = " - 2020"
end date is empty = "2020 - "
start- and end date is empty = " - "
The user can then continue on to step 3.
In step 3, the user can search for existing people in the database to add this new position to.
To do this, the user can search the first and last name of a person, and get a list of all people with that combination in a table to select from. When they select a person, they can automatically go to step 6, where they fill the position detail information.
Currently, the user is only allowed to search via first and last name. There will be no sensitive data visible for the user to identify unique people. This is so to keep consistent with the logic for the Sensitive Data FP
If the person does not exist in the database, this is when the user can create a new person.
To do this, the user selects "voeg een nieuw persoon toe" and goes to step 5.
This is the step where they fill in the personal (and sensitive ) data about the new person. When this is done, the user clicks on "Volgende" and goes to step 6, where they fill in the position detail information. i.e. contact information, as well as detailed information cards which depend on the type of position selected in step 2.
If the user leave the journey at any time before hitting the last save button, the information will get lost. This means that if the user has filled in the personal information for a new person (Step 5), that information will not be saved unless the user fills in all the mandatory postion detail information and hits save.
All information related to sensitive data should be discussed and added to the Feature Passport: Sensitive data
Step 1
[Search page]
Step2
if Bedienaar:
If Mandate:
Step 3
Step 4
Step 5
Step 6
Contactgegevens
Posities
Position detail page
Technical
[Information about the technical solutions for expectations that need it e.g. using mu-search for showing all types of positions in one table.]
Technical Research Conclusions
Technical research conclusion on the extra filters for the person search page:
Name: We can search on both field (first/last name)
Organisation (start typing then -> drop-down): No technical issue
Position (drop-down): No technical issue
Add an active-inactive filter: No technical issue using Mu-search
2. Technical research conclusions on the new Contactgegevens screen:
editing the data on the Contactgegevens screen
implementing the link to the codelist when viewing/ editing privacy related data
...
Last updated