What does document management look like for frontline workers?
A UX case study from Beekeeper
Beekeeper is a platform specifically designed for frontline workers. Our mission is to help non-desk employees to unlock their full potential. We also want them to feel a sense of community and appreciation in the workplace.
What‘s the core problem?
We realized that many of our customers struggled with sharing documents (such as training and onboarding manuals, site plans, canteen menus, health and safety regulations and best practice examples) with their teams.
Some of them still worked with printed documents that were placed on pinboards in common areas in the workplace. Imagine you’re a construction worker and you need to access your company’s safety regulations on the construction site. Having a physical copy in an office far away probably wouldn’t prove very useful. 🤔
A few managers and team leads actually realised the problem and started using Beekeeper’s More tab as a “mobile employee intranet”. They added links that pointed to useful documents so that their employees could access everything in one place. Inventive use cases like this always make one realize how much product teams can learn from their users.
But even though one could create separate sections, at the end of the day the More tab was still just a simple list of items which got cluttered easily.
Sneak peeking into the usage data and listening to our customers’ feedback made us realize that we could do more to help our users access the resources they needed for their everyday work.
Relevant documents always at hand
Challenge
As a first step, we dug deeper and learned more about our customers’ challenges:
- Many had a huge number of documents either on paper or on their servers that were difficult to access for employees without a computer.
- Because of this, links on the More tab often pointed to certain documents or photos of documents temporarily stored in third-party file-hosting services that employees had to separately sign up for. It required additional effort from frontline workers.
- When there were more than 15–20 links on the More tab, people got lost as they couldn’t find relevant information any more.
- Some companies were not even allowed (due to certain regulations) to use third-party file storage apps, so they regularly posted files and photos of documents in News Streams and Chats in Beekeeper.
- Employees couldn’t keep track of documents that had been posted in Streams or Chats since these quickly moved out of focus.
- Managers wanted to be able to decide who had access to certain resources.
Our solution
Our main takeaway was that we needed to help our customers make their documents accessible and more organised so that they can centralise all work-related information for their employees right in Beekeeper. At the same time, we had to come up with a solution to help non-desk workers find relevant files as easily as possible.
We came up with different concepts that could potentially solve this problem:
- Making the More tab smarter and easier to navigate
- Integrating a third-party file storage application
- Creating Beekeeper’s own Document Library
- Enabling users to find files that were posted in Streams or Chats more easily
We cross-checked these concepts with the research insights to evaluate which solution could work best for our target audience. It was clear that our users wanted a simple way of managing relevant documents. They wanted something that feels familiar to them.
“We update our safety regulations and standard operating procedures quite often. Organizing them in folders would make it easier to find what we need.”
Focusing on real operational use-cases, we decided to go with the solution that seemed to solve most of the identified problems: Beekeeper’s own Document Library.
Early prototypes reveal areas of improvement
After the initial discovery phase, we started thinking about how the actual interface could address our users’ problems. We came up with multiple different solutions and put them on paper. This helped us quickly filter through our ideas and choose the ones we wanted to get feedback for.
We created wireframes and eventually coded the first version that we actually released to some customers so we could get feedback on it. Gathering and analysing usage data helped us understand better how our customers interacted with the interface. Completing these numbers with qualitative research (feedback mainly through usability tests) helped us see the bigger picture.
We identified several usability issues, some of which you can read more about below.
Navigation
Although we implemented breadcrumbs for the Document Library in the Beekeeper admin portal, people didn’t use it to navigate back to the root folder. During the usability tests, we realized that it was because people didn’t understand that the “files icon” was for navigating back to the top level. Some even hovered their mouses over but never clicked on it.
Learning from the user feedback, we replaced the icon with the word: Documents. This small change made it easier for our users to navigate through folders of the Document Library.
Finding files
During the discovery phase, we learned that it usually didn’t matter to people if a file was a pdf or an image as long as it provided them with the information they were looking for. Because of this (and to simplify the interface), the file extensions were hidden in the UI of the first prototype.
Later we realised that people got frustrated about not being able to see the file types. It turned out that they wanted to see them because it helped them find certain files easier.
So, in the next iteration, we introduced a new icon set in which the colors reflected the “typical” ones for certain file types, such as blue for Word files, to make the learning curve as flat as possible.
During the next usability tests, we received very positive feedback and people were finally able to find what they were looking for much faster.
Permissions
We know that in a big organization not everyone has permission / needs to see certain files. So, we designed a system that enables admins to decide which items are shared with whom.
In Beekeeper, people are organized into groups and locations to be able to map real company structures. These organizational units are used, for example, to send messages to a particular segment of the company or to filter analytics based on teams.
Leveraging this capability, we wanted to allow admins to assign permissions to files by groups and locations. Our research also showed that there was a need for differentiating between certain units a) being able to see files and b) unit admins modifying them (delete, rename, etc).
Because of this, we came up with the idea of adding an Access column in the file management table. It was supposed to give admin users a quick overview of the permissions.
Take this image as an example. There’s a folder, named Warehouse files, that all employees in Austria and Switzerland and all members of the Warehouse workers group (no matter which location they are part of) can see but only admins of the Warehouse workers group are allowed to edit the content.
On one hand, people understood what the access tags were and that more detailed information could be found when clicking on them. But on the other hand, they were confused because they didn’t understand who exactly had access to certain items.
- “Warehouse workers… but only in Austria and Switzerland or…?” — they asked during the usability tests.
- Participants thought that everyone in the Warehouse workers group can edit the folder, not only admins. (Hovering over the pencil icon would have shown them a tooltip but none of the test participants did that.)
- They also didn’t understand what those small blue dots meant on the group’s icon. Some said they were notifications, others thought that they were supposed to indicate that group members were active at that time.
After the first set of usability tests, it became clear that we needed a different solution. We experimented with different approaches but the one that worked best during tests was a fairly straightforward one. Clicking on the access labels would still show a quick view dropdown menu but the information was structured differently.
Instead of showing dots and icons, we simply created two different sections:
- “Members can view”
- “Members can view, admins can edit”
Organizational units were listed below these sections according to their permissions.
Testing this new solution brought much better results: every participant understood who had access to each item, and what kind of access these people had.
It’s a great example of how early usability testing can help us realize when an otherwise fairly straightforward concept is overcomplicated.
It might seem obvious now, but without the tests, it would have taken much longer for us to realize this usability issue. It also reinforced our thoughts around how important in-app copy is: sometimes words cannot be replaced with icons.
Error and empty states
While testing the coded prototype, a participant got disconnected from the internet for a second and got an error message. It was a default page that we showed in most of the cases when something went wrong.
Can’t retrieve data — We’re having problems loading data from the server.
Seeing this message, the test participant thought that she didn’t have access to that folder. She didn’t understand how and if she could resolve the problem which made her confused.
“Uh-oh… Okay, maybe I’m not really supposed to open that.”
This test made us realize that we needed to pay special attention to the error and empty states. We had to let our users know why a page is empty or why exactly an error message was being shown and how to resolve the issue. So, we started working on new error and empty states. It was an exciting exercise to test our new content guidelines that we had just finished.
We ended up creating a bunch of different empty and error states, some of which we had tested before implementation. See the result below.
Sharing files
At Beekeeper, different user types are represented by different personas. To avoid self-referential decision-making, we usually think and talk about our personas; their goals, challenges and motivations.
A couple of weeks after we had started working on the Document Library, we did a workshop with our team to generate new ideas. The special thing about this session was that each persona was assigned to a team member. Prior to the workshop, everyone had to learn about their selected persona and during the discussions, we acted like we were that persona. We had to evaluate the first version of the prototype from our persona’s perspective.
Many great ideas were born during that workshop, one of which was about sharing files with coworkers. To test the idea, during the usability tests — without actually putting the feature in the prototype — we asked participants to share a file with their colleagues.
Most of them described this action as a very common use-case and wanted to find a share action under the “more actions” dropdown menu. They also tried opening the file and looking for a share icon there. Others wanted to download the file and send it as an attachment.
So, we started sketching and came up with a solution that later proved to be even more convenient and also more secure than downloading and sending a file to someone else in the company. We created the “copy link” feature.
Replacing files
As our users started sharing more and more links with each other that pointed to certain files, a question arose:
“What if I want to upload a new version of the same file? Would I have to copy and share a new link?”
We identified this use-case as a regular one among the majority of our customers. Company policies, regulations, shift schedules, lunch menus, HR documents and site plans — just to mention a handful of examples — get updated almost every week. Sending a new link seemed to add too much extra work that made the experience sub-optimal and our users frustrated.
So, we took all the feedback we got into consideration and created a solution to address this issue. See the “upload new version” feature in action below.
It might be a small feature but it saves a lot of time for our users. It was really amazing to see how small changes can have a huge impact on user experience.
What we’ve learned
This project yet again highlighted the importance of early usability testing and research in general. Seeing what issues our users face when interacting with our product is crucial. No matter how well we think we know our target audience, we need to ask for their direct feedback as often and as early as possible. It saves us plenty of time and energy.
Error states can make or break the user experience. We need to stop thinking about them as edge-cases and start seeing them as what they are: tools that we can leverage to give relief to our users when something goes wrong. With the help of the right error state, we can transform an otherwise unpleasant experience into an “Aha!” moment.
Through the example of both the root folder icon in the early version of the breadcrumbs and the access dropdown menu, we could come to a conclusion that copy is a very powerful tool in a product designer’s toolbox.
During this project, we facilitated our first persona acting workshop. Putting on our users’ masks from time to time can help us avoid self-referential thinking. It helped us generate great ideas some of that we validated and implemented later on.
Thanks for reading! I hope you enjoyed reading about our challenges and how we solved the identified issues. If you have any questions or thoughts, feel free to leave a comment or send me a message. 👋
