Case Study: memo-media
Part 1/2: Analysis, user test & solutions
The company memo-media can be viewed as the interface between event service providers, event locations and artists on the one hand and event planners on the other. The website eventbranchenverzeichnis.de (EVB) is a practical search engine that can be used to find and request suitable service providers for the next event.
Over the years, the catalogue of EVB continued to grow, the usability was no longer up to date, and a complete restoration of the legacy system was due. Some stumbling blocks regarding usability were already known from user feedback. Nevertheless, we advised looking over users’ shoulders in a usability test to determine how they interacted with the application. This allowed us to draw conclusions about the handling and hidden difficulties.
Together with the client, we defined the focus areas for the usability test and clarified which questions should be answered with the user test.
What is the general ergonomics of the free text search?
How do users find their way around the categories when searching?
How easy is it for users to find their search results?
How easy/difficult is it for them to select a provider that meets their needs?
Is the function of the address picker (main feature and heart of the EVB) understood, and is the feature easy to find?
Based on this objectives, we defined questions and tasks that five test persons were asked to answer.
Challenges and findings of the user test
Searching via free text
The more words the testers entered in the search input field, the more search results they were displayed. This made it difficult to select a provider, as the search was not narrowed down.
Display of the free text search: In the search bar (screenshot 1), test subjects clicked the wrong button to trigger the search. Instead of clicking on the button with the magnifying glass to start the search query, they used the “We are searching for you” button to trigger the search. “We are looking for you” is a service provided by memo-media where event planners fill out a request form to find the right service provider for the planned event.
Search results page
It was unclear to test users how the search results were sorted in the list. The search results list always displayed paying service providers, so-called premium providers, first. This meant that the distance to the search location was not considered. The testers also lacked the option of sorting or filtering search results.
The proximity of service providers played an essential role in the selection process of the test candidates. They mainly searched for providers close to their location. The map lacked a complete overview of all providers for their search. Only premium providers were shown on the map.
The results page displayed categories matching the entered search query below the search bar. The users did not notice those due to the presentation (screenshot 2).
Another finding from the user tests was that an appealing logo, images of offered services and the service provider’s name were decisive in determining whether the test person was interested in a provider.
Provider page/detail page
One of our research objectives was to discover the challenges the so-called “address picker” provided. The address picker is a feature that allows event planners to create so-called project folders. They could add event service providers to these project folders and enter notes in order to better plan their next event.
The user tests showed that the feature’s name led to confusion among testers and raised false expectations. If users who weren’t logged in clicked on the address picker icon, they were taken to a new page, the login screen. We observed that the login process created a hurdle at this point. Users also had difficulties finding their way back to their search results.
Furthermore, it turned out that testers immediately left a detail page that displayed images and videos that did not match their search query.
Searching via categories
When searching via the main categories, we found that the testers were overwhelmed by the number and structure of the categories. Each sub-category led to a new page, which caused the testers to lose context.
After presenting the usability problems, we discussed possible solutions with the client and prioritized the features we wanted to tackle first in the project.
Search results page
From the start of the project, it was clear that a combination of full-text search and geographical search should be implemented. Both searches are implemented within one database to ensure that the system can deliver search results in an acceptable time.
Free text search
We revised the search result sorting and the search query logic: Each entry received an index field covering all relevant entries (company name, categories, description, etc.), which can be used to submit a search query. The tsvector from Postgres is used for this (link). This approach also enables an abstraction of the search terms (e.g. a search for “table” now leads to the same results as a search for “tables”).
To implement the geographical search, we used the built-in geospatial functions of the Postgres extension Postgis. In particular, the radius search
ST_DWithin ². Each entry also has the branch/location encoded as geo-coordinates. So, we get a lot of geographic points in our database:
If a radius search is carried out, e.g. around Cologne, this location is also converted as a geo-coordinate and then cached for further searches. All locations within a defined radius of the geo-coordinates of Cologne are then searched for.
Furthermore, the distance is calculated with
ST_Distance ³ to output the closest results first. As these queries both run within the Postgres context, a category filter can be used in addition to the aforementioned full-text search without losing performance.
Provider page/details page
In addition to renaming the address picker, the focus is on redesigning the feature. Previously, if an event planner asked several providers for an upcoming event, they always had to fill out the request form. This resulted in additional work, as the data had to be entered repeatedly. We recommended linking the research tool (address picker) with in-app provider communication. This way, the event planner only needs to send one request from a project folder. In addition, users who are not logged in should also be able to save or favourite a certain number of service providers in the future. As soon as the non-registered user makes a request to the provider or wants to use additional features, they must register or log in.
To be continued.