This post is organized around an original interaction design which is compared to my suggested redesign.

The original design

The following is a rather standard example of a publicly available employee directory.

The original of an employee directory with three filter dropdowns at the top.
The original of an employee directory with three filter dropdowns at the top:

Link to the original design

The design is organized as a grid of cards of employees.

It has three dropdowns for narrowing down the number of displayed employees:

Drawbacks of this design

The main purpose of an employee directory is to be able to find the relevant employee(s) and their contact info as quickly and effortlessly as possible.

However, in use, the original design is quite inefficient and cumbersome for this main task, because:

My proposed redesign

So, how could this potentially be redesigned to provide a more efficient interaction flow?

An improved version could look like this responsive, interactive prototype (copy is in Danish):

My proposed redesign of the employee directory using a different set of user interface widgets.
My proposed redesign of the employee directory using a different set of user interface widgets (and realistic dummy data).

Try the prototype

Improvements over the original

What did I do in the redesign?

To begin with, I got rid of the first dropdown for filtering by employees' first names: Instead, by presenting each employee on their on row with names neatly aligned along a vertical axis, skimming while scrolling vertically is better supported. To help users orient alphabetically, each first letter of employees' names is emphasized with a bold font and slightly larger font-size. The original's grid layout makes skimming more tedious due to the zig-zag pattern (on larger displays; on mobile grid cards are stacked vertically).

Next, I removed the potential dead ends by replacing the office branch "Kontor" dropdown with a set of checkboxes linked to the department dropdown. Thus when selecting a department, only the relevant branches are selectable with checkboxes. Now, the only dead ends occur when all office branches are de-selected; then a blank slate message is displayed prompting the user to choose a branch. A further benefit is the ability to easily select multiple branches to find employees "nearby".

The improved design also supports easy resetting of filters: Either you use the checkbox "Alle kontorer" (all office branches) or you simply select another department thus resetting the branch selections. So, all you have to do to reset everything back to all employees across all branches, is nothing more than selecting the topmost "Alle medarbejdere" in the department dropdown.

A further enhancement is the fixation of the filters at the top of the page. So, when scrolling down through results, adjustments to filters are readily available without having to scroll back up to the top.

Further discussion

It's quite obvious that the proposed redesign using checkboxes for office branches only works in cases, such as this, with a limited number of branches. Had the number of branches been significantly higher, we would need to come up with another redesign, taking this situation into account.

Thus, the primary point here is to tailor the interaction design to the actual content and usage scenarios. This way, the most efficient and pleasant user flow can be insured.

On another note, when considering the scenario of using an employee directory to find the best person to ask a specific question (say, about some intricate legal issues), neither the original nor the redesign is very well suited.

In this scenario, department and job titles wouldn't necessarily be enough to determine the right employee to consult. This also due to the fact that a departmental organisational structure is very much an internal tool, which can differ quite much between companies and thus be hard to understand and use for external people.

So, to support this "unknown item search" scenario, the designer would have to deploy other techniques such as meta data filtering (e.g. on the specific domains and specialities of employees) – or even better – a high-quality natural language query search powered by AI.

Using Vue.js for prototyping

For the prototype presented here I tried using the JavaScript framework Vue.js. Having previously used the (aging) jQuery framework for advanced prototyping, it's my first time exploring Vue.js. While it took some time to get aquainted, I also found it to be very productive with proper separation of data (as properties and JSON) and presentation in HTML.


redesign-case widget-design

Related posts