🆔FP: Improve Personen search

(and adding new person)

Status Feature Passport

STATUSOWNERDATE

In proposal

21/08/22

In refinement - Technical Research/Feedback

27/09/22

In development

In QA/ Testing

In Final state

  • JIRA-ask here

  • Feature passport “adding person on search” here

  • Feature passport “Copying” details of a person here

  • User research on “How users search” here

Analysis

Current state

Full flowchart of adding/updating a Person in the current product

Full whimsical flowchart here

This is the current state with the problems I (Judith) identified.

Decisions made in the past
  • Persons need to be added by position first. This is how it historically was built, we need to refactor this to input name first. Exploring if we can reverse this on JIRA

Problems

Issues identified through data research
  • Looking at an Excel with duplicates;

    • 1087 = total duplicates

    • 464 = Appointed to several bestuurseenheden

    • 54 = No bestuurseenheid added

    • 61 = Duplicate with same bestuurseenheid (other position?)

    • Others;

      • Slight deviations in name Franck vs Franckx

      • Additions to the name "Franck, ontslagnemend op 1/1/22"

  1. Issue: 43% of duplicates is because of several bestuurseenheden. Misspelling of names is not the main issue, adding new people to different besturen/positions (?) is. Main issue = Missing functionality to add new bestuurseenheden to existing people rather than search

  2. Learning; Duplicates most often have the correct name, thus leveraging name recognition on search would work(instead of ID-identifier)

Additional context

  • We do not have data on who added the duplicate

  • We do not have data when the duplicate was added it, so it might have been added before the product was changed in a meaningful way (and thus the duplicate no longer the usecase today)

Issues identified through going through the current state (see flowchart above)

Usecase 1: creating a new person with a new position

  1. Determining position comes first, not adding personal details. Assumption of the issue: This isn’t expected UX when you are trying to add a person (in a module called “Personen”)

  2. One needs to input first name & last name 3x, including going to the same person search twice. Issue: unnecessary actions asked from the user

  3. Search doesn't come first in the user flow to add a new person (adding position is) Issue: unnecessary actions asked from the user

Usecase 2: Creating a new position for an existing person

  1. Inability to edit positions with an existing bestuurseenheid (bestuurseenheid a person is already part of) or add to a new bestuurseenheid of an existing person (person that is already in the database). You can only edit or add new contact details to an existing position. Issue = Missing functionality to update positions of an existing person to bestuurseenheid person is already part of OR to add to a new bestuurseenheid if you do it from the "Person" module.

Usecase 3: Search

  1. Suggestive search (positions/organisation) isn’t smart Dropdown, suggestive search doesn’t allow for misspelling St. instead of Sint.

  2. UX between searching on name & position/organisation is different (suggestive search vs free text).

  3. No ability to filter through results for name/bestuurseenheid.... You are obliged/forced to select from a dropdown while typing. Result = less accurate search results don't show up.

  4. Search on first & last name separately can easily be missed

All identified issues

UsecaseIssueNotes

Search output

Search isn't smart

Doesn't recognize Franckx as Franck

Users cannot take actions from the search results

Search input

Different search UX for different fields (Name vs Organisation)

suggestive search in drop down and selection of right one vs free text and list view).

First name & last name are 2 different fields

🤩 Expectations

🕵️‍♂️ Use Cases

  • Best case; People search for the correct first and last name and there’s an exact match

  • OK Case;

    • People search with only first name

    • People search with only last name

    • List of returned names is long

  • Worst case & edgecases

    • People search for a first name that is part of the last name too and vice versa ("jan" is part of "janssen" too)

    • People search with misspelled names

    • People search with a name that can be first OR last name

    • People search something else than a name

    • People list part of the name and not enough input to make distinct recommendations

🤔 Assumptions

  • Current users use "Bestuurseenheden" to add new people and that's where the current duplicates come from. This is due to historical reasons; the bestuurseenheden module was built before Personen so they are less familiar with it.

  • Future users will use "Personen" to search & add personen

Solution

We will tackle this problem in several places of the full product suite. Solving it for current users AND future users, assuming they have different behaviors (see above). We want to solve this with repeatable UX, so users see the same patterns in different places. Concretely; we want the list of results from search OR when trying to add a new person look and feel the same, without being confusing. Currently those list views are different.

Overarching idea & complexity; 2 levels of information

While brainstorming concepts we noticed there's 2 levels of information about a person;

  • Top level; information that is the same across positions or bestuurseenheden

    • For instance; the name of a person / DOB / ID-number...

  • Sub levels; information that can be different depending on another piece of information

    • For instance; contact details (tied to a position), position, bestuurseenheid..

Users need to take certain actions on the top level, but also on the sub level. For instance; adding a new position to a person, should happen on the top level. Changing an existing position, should happen on the sub level of the dedicated position this change is related to.

Overarching solution

In the search results we need to split up

  • the top level information and actions (name of a person + adding a new position)

  • the sub level information and actions (list of positions + editing those or contact details)

Full link of flowchart here

1. Adding action on search results of Personen

Issue: Users cannot take actions from the search results Solution:

  • Allow users to add a new position or change contact details from the list of search results

  • Move the action of "adding a new" person from the search result to the bottom. Only when users went through search they should be able to add a new person

2. One search input: merge first & last name search INPUT into free text

Allow the ability for users to input first & last name in one, free text "name" box, without suggestions. Suggestions should be displayed in the search result output instead of in the input.

3. Search output: Generate "Exact" and "Potential" matches

On

  • search results, for search in Personen

  • search results when trying to add a new person and doing an automatic search first

Design / engineer for

  • exact matches

  • potential matches (copy: We vonden personen die mogelijks aan je zoektermen voldoen)

  • no matches (copy: We vonden geen persoon in de database met deze zoektermen. Gelieve opnieuw te proberen met een andere spelling of andere informatie. Indien de ingevboerde informatie correct is kan je deze persoon ook toevoegen) --> Add action "Adding new person"

  • Show results in 2 levels of information;

    • Level 1: First name + last name + action “add new position”

    • Level 2: Position + actions “view position” AND “edit contact details”

  • For exact matches show all info (all levels)

  • For potential matches

    • only show the top level with an ability to drill down more

    • Limit the number of matches until they are no longer relevant

Ability to add a new person;

  • Easily allow people to add a new person without having to filter through a long list of potential matches

Design

This part of the feature passport is owned by the designer

User research

[If there is any user research preceding the wireframe mock-up stage, it needs to be documented here]

Mock-ups

[link to figma mockups + any explanation or extra documentation]

Technical

This part of the feature passport is owned by the technical team

[Information about the technical solutions for expectations that need it - e.g. using mu-search for showing all types of positions in one table.]

After the designer and/or the technical team finish their task, a meeting follows where the solutions are presented. The team exchanges feedback and amends the feature passport where necessary.

Last updated