DPD · User research
How user research changed the search model
From one universal search field to three intentional filters — and a results view based on information people actually used.
Executive summary
The research changed the underlying model, not only the interface
The original concept assumed that one universal search field would provide the simplest way to find an address.
User interviews revealed a different pattern. People did not approach search as an open-ended task. They knew what type of information they wanted to use and narrowed their searches intentionally.
The findings replaced one general search field with three explicit filters and removed information that did not support the search decision.
The initial assumption
One field appeared to offer the simplest experience
The first design used a single search field intended to support different ways of finding an address.
The underlying assumption was that reducing the number of visible controls would make the experience easier.
But interface simplicity does not always produce decision clarity. A universal field required users to understand what the system accepted and how their query would be interpreted.
What the research revealed
Users already had a search strategy
During interviews, users described more structured behaviour than the original design supported.
They searched within specific categories and deliberately narrowed the results. Their mental model was not “I will enter anything and see what the system finds.” It was closer to “I know which type of information I have, and I want to search within that category.”
The research also established a hierarchy of information used to evaluate the results.
Address
Consistently important during identification.
Name or contact person
Useful depending on the situation.
Phone and email
Did not support the decision at this stage.
The design decision
From universal search to explicit filtering
The findings led to a change in the search model. The available search paths became visible instead of requiring users to infer the system’s logic.
One general search field
Multiple possible query types hidden behind one control.
Three explicit filters
Categories reflected the ways people intentionally searched.
Beyond the research findings
What users needed for search was not enough for the complete flow
Interviews showed that phone numbers and email addresses did not help people find or identify an address. Based on the search task alone, removing them appeared to be the right simplification.
I then compared the information visible in the address book with the data required by each delivery method. This exposed a failure that the interviews could not reveal.
For delivery to a pickup point or locker, the form required a full name and phone number. A saved record could contain only a company name and address, appear valid on the list, and then produce no visible change in the form. The user received only a short success toast, even though the required fields remained empty.
Research insight → process conflict → design decision
Why visible search data was not enough
User research: people searched and compared records using D1, D2 and D3. D4 was considered unnecessary for finding an address.
S1
Delivery to an address
Required: (D1 or D2) + D3 + D4
- The list shows D1, D2 and D3.
- After selecting a record, D1 or D2 and the address appear in the form.
Visible resultThe user can see that the record was applied.
S2
Pickup point or locker
Required: D2 + D4
- A record containing only D1 and D3 still looks complete on the list.
- Neither D1 nor D3 is displayed in this form after selection.
Invisible resultThe form appears unchanged; a three-second toast is the only confirmation.
Process analysis changed the design decision
Decision 01
Show the phone number
D4 helps users distinguish duplicate records and choose one that can complete S2.Decision 02
Validate missing fields immediately
Applying a record is treated like entering and leaving required fields empty, making the result visible.
My contribution
Translating observed behaviour into product decisions
- Examined how users searched for and identified addresses.
- Compared their behaviour with assumptions embedded in the initial design.
- Translated the findings into an explicit filtering model.
- Established which information supported the search decision.
- Balanced search relevance with the data needed to understand the result of applying a record.
The purpose of the research was not to validate the existing concept. It was to determine whether the proposed model matched how people actually worked.
The outcome
Research materially changed the design direction
The project moved from one universal field and a broader set of result data to three intentional filters and a more focused information hierarchy.
No verified post-release metrics are available, so I do not claim a measurable improvement in performance or adoption.
What the evidence confirms is that the final direction was based on observed user behaviour rather than the original design assumption.
Leadership perspective
Research creates value when it can change the model
Research should not be treated as confirmation performed after the important decisions have already been made.
In this project, its value came from exposing a mismatch early enough to change the product direction.