Smart Apiculture Management Services.

SAMS is an interdisciplinary project, in partnership with countries from Asia, Europe and Africa, funded by European Union. The SAMS project aims to develop and offer an open source remote monitoring technology which supports beekeepers in managing and monitoring the health and level of productivity of bee colonies. I'm currently involved in designing the app interface to ensure beekeepers are comfortable enough using the SAMS app to assist their beekeeping needs.
Role
Interface Designer
Product Type
IoT, New Product
Timeline
9 Months
Skills Used
Product Strategy - Value mapping - Service Design - Interaction Design - Design System - Data visualization

Why we build this

Bee health, good beekeeping practices and the promotion of beekeeping are essential for a sustainable agriculture worldwide. The current trend of degraded pollination power of suffering bee colonies threats general agricultural production. The SAMS project works on three continents in three different scenarios of the apicultural sector:

Helping beekeepers optimise honey production

AfricaEthiopia:

Beekeepers have limited access to modern beehive equipment and bee management systems. The apicultural sector is far behind its potential. SAMS is currently implemented in the Oromia region, in SNNP regions and in Addis Ababa city.

Asia Indonesia:

Beekeeping is a rarely conducted business and few professional processing organizations are existing. Support and marketing lead to a slow development of the apicultural sector. SAMS is currently implemented in West Java.

Fulfilling Honey market demand

Europe :

Consumption and trading of honey products are increasing whereas the production is stagnating, and pollination services are underdeveloped. SAMS is currently implemented in Germany and Latvia.

Source :

Visit : sams-project.eu

Initial Brief

The project started from foundational research, my job as interface designer is to translate the insights into a tangible, usable interface. I was involved when the tech and hardware already designed, so I was given list of product backlogs and rough sketch from the Product Owner. The expected outcome of this phase is to validate how the beekeepers will use the device according to their context.

This is pretty much describe how the process looks like

This is my first IoT design with few similar app benchmarking so when I got assigned to this project, the concept hive monitoring itself is still an abstract concept. Everyone knows the idea of it, but different mental models can have different expectation and perception on how data should be presented and how touch points should be designed. Since we're designing for global context ( small and established beekeepers from 3 continents ) I decided to have all information presented on the screen first with basic pattern from google material so the beekeepers can at least have basic visualisation first for them to easily prioritise what matters rather than directly asked what they want which could make them confused since they've never used similar device.

Let's get everyone on the same page first before getting too technical

I translate the backlog and sketch into flow & Information architecture first to ensure everyone has the same definition of element's hierarchy

The Basic Concept

Usually, a beekeeper have several apiaries ( a place to farm honey from hives)
in different location depends on which one has the best forage for bees to produce honey. In one apiary there can be :

Apiary data input

An apiary is usually an outdoor place where several hives are installed. The location plays a crucial role to determine the success of honey production and quality because the bees collect nectar from the surrounding environment. At this stage we still don't know how the data will be gathered, will it through manual form or is there a way to collect it automatically.

Hives monitoring

The devices will be installed on hives to gather data about their weight, temperature and humidity. The scientist already have normal range for temperature and humidity and they also have determined the significancy of data changes to determine whether it needs urgent inspection or not. They also provide best practice recommendation to help beekeepers know what to do in the next step.

Synchronising the data into the system - Information Architecture

After having a proper understanding on how the device works, I began to develop information architecture to determine how much information should be put into one screen and which one matters the most. This one is still function driven, meant for user who want to quick monitoring without having to move into new page.

And this is one of the preview of my first visual interpretation

There are indeed so many information that is put in one screen, but established beekeepers with approximately 30 hives in one apiary will need this to quickly scan and immediately know what happen on each hives to anticipate if they have different judgement from the monitoring system. The usability engineer from Germany suggest when they click the endangered hive, they should immediately directed to suggestion on what to do instead having to be overwhelmed by lots of data. They also suggest to remove the hive illustration as it took lots of space.

Add some colors to it

After the design become more solid as there's only minor changes, I decided to start using colours on the design to have it ready for prototype. The initial brand colours were not enough to cater different cases in the design, such as for different action buttons, so I added more variants accordingly.

The colour system, more details will be explain in design system section

And this is how I implement the colours into the interface

After Several Expert Reviews

The prototype's ready to be tested

The global committee from Germany, Latvia, Ethiopia and Indonesia gathered to give last feedback before it's tested. Most of the committee gave a positive feedback towards the design but some predicts that the system would be too complicated or the beekeepers need further training to use the app. Here are the final design before user testing :

Onboarding

After splash screen, users will be explained about SAMS in general and how to use it. To avoid overwhelming, I divide the information into 3 section with automatic slider to let user know there are more contents on the right side.

Login/Sign Up

The login and sign up design were pretty similar, but in this phase we wanted to test which method were more comfortable for users, e-mail or phone? After the design finalisation I actually have an idea to have the login/sign up in one button and field only to avoid confusion and provide more effective process, but I'd like to see beekeeper's respond to this design first.

Product Tour

To give users expectation on how the system works, we created a product tour to explain the step by step process.

Create Apiary - Apiary List

Since the forage condition haven't been specified yet, the apiary info will be consist of map location which will be useful later for weather forecasting.

Add hive

After the users input apiary information, they'll be able to synchronise the monitoring system to their account. Each device will have a specific QR code where users can just scan them and monitor the system 24 hours after first activation.

Hive List - troubled hive warning system

The troubled hive will have a specific resolve button to urge users to immediately take action if their hive is in trouble. The system then provide the summary of what happen and provide step by step recommendation, proven by scientists.

Some Prototype Video Preview

Hmm, something's missing...

I did design the complete product with its function, but it was lacking of context and exact target user. "Is there any possibilities that the beekeeper might not need the app at all and could've just used alarm system if there's anything wrong?" The team and I began to ask fundamental question again, but since the prototype has been prepared, we decided to keep an open mind and listen what the beekeepers have to say about the device and app concept.

The team test the design, and the result...

After the final design has been approve to be tested, the researcher team starts recruiting beekeepers and ask them what do they think about the app. Not only usability, we also ought to discover new opportunities on the features. The researcher team test the prototype to 5 beekeepers in Indonesian and Ethiopia. Kudos to researcher team for still able to make this user design evaluation happen even in the midst of pandemic, also the insights are indeed invaluable for our team to improve our product.

Indonesian Beekeepers result

The researchers interview 3 types of beekeepers : grass root beekeepers, community beekeepers and established beekeepers.
The researchers interview 3 types of beekeepers : grass root beekeepers, community beekeepers and established beekeepers. From the key insights, I recreate the user journey into flow diagram and match it with the insights. Turns out about 80% of the flow experience contain negative expression, but they indeed excited about the monitoring feature which is our core feature.
Here are the key behaviours of Indonesian Beekeepers :
1. Not familiar with the app - afraid or don't have the confidence to take action independently.
2. Asking a lot on what to fill or what to do next - like to be guided or being told what to do if they not familiar with the system.
3. They prefer to take advise from someone familiar ( community leader ) rather than scientifically proven
4. They do things collectively, that's why they suggest to have this app used collectively within their community.

Ethiopian Beekeepers result

Here are the key result of Ethiopian Beekeepers :
1. The beekeepers wish the DSS system was less complex to use
2no apiary yet were misunderstood as if there's something's wrong with the system
3. With the current design, the beekeepers would need a training first, they recommend a video learning that they can learn by themselves.
4. The beekeepers might need a manual way to input the weight data because in certain weather they put roof-like protection and took it off if the weather's changed.

Easiest solution isn't always the best, isn't always seems trustworthy.

We thought the users would've wanted a fast solution, but turns out they have their own way to trust an advise and own ways to solve problems. It was indeed fascinating how users have their own interpretation towards the system. Even though we did a thorough foundational research, the design could easily be misunderstood if we don't test it thoroughly as well. The prototype is crucial to give them a grasp on how the system works and at least, the prototype show them the things they don't want, that could gradually shaping it to become the system they want.

We rework. Almost everything

After having a meeting regarding the result with the global committee, we agree to have one more iteration. But first, it will start from ideation session again. I was indeed excited because I wasn't involved in the first ideation session. We decided to have face-to-face ideation since it would ease the brainstorming session. The ideation involved 4 people : researcher, product owner as well as hardware engineer, country project manager and me as interface designer.
We then evaluate the design based on experience success ladder and we decided that we're still in the functional ladder.
Experience ladder reference by Ward Andrews

How do we know we've achieved functionality level?

From usability engineer, hardware engineer, researcher and country project manager's judgement, the app already provide basic function and features needed by beekeepers to monitor, it has approval from internal team who have been on this project since the beginning and they've interact and conduct with users about background, but no matter how deep the research, we can only know what works or not until we actually show the design to the users.

How do we know we haven't achieved usability level yet?

the signals that shows we haven't achieved the usability ladders are:
-Users feel lost and discouraged, resulting in dissatisfaction and abandonment
-Users feel they need proper training first
-They can’t complete their tasks efficiently as they have to keep asking on what to do next

Found the missing pieces : End-to-end service journey

The ideation starts with solving the obvious problem of negative experiences but it took us to the ultimate missing puzzles :
Pre-Sales & After-Sales Service
Hardware Interaction
I imagine what the process would've look like if the beekeepers try to buy from SAMS sales team in a conversation :

Beekeepers : Hi! I'd like to buy remote bee hive monitoring system to optimise honey production
SAMS Sales : that's wonderful! how many device would you like to buy?
Beekeepers : 20
SAMS Sales : Perfect! where should we send the device?
Beekeepers : 10 to my honey farm in Sweden, 10 in Germany
SAMS Sales : Excellent, can we have your e-mail or phone details so you can access the monitoring system from your smartphone?
Beekeepers : sure, my e-mail is nisa@labtek.com

From the conversation, the team and I agree the apiary input and device set up can be done once the beekeepers finish the payment process. Thus, I continue the process by creating simple service blueprint, to give the whole team better understanding towards the new discovery we just found.
After redefining the whole process and include sales phase and hardware device interaction, we were able to simplify the setting up device flow and move the apiary input and hive input into the sales phase. Turns out the apiary information input and hive synchronisation weren't necessary in the setting up device phase, the process was more relevant to be put in the sales phase because like it or not, the sales phase cannot be dismissed unless it's a charity program.

The whole flow wasn't really simplified, it was actually more detailed than before, but at least for the setting up phase should be less complex for the beekeepers and we found other opportunities to onboard the users so the process isn't depending on the app only. Here are the improved flows :

Flow Improvement - Setting Up Device

Flow Improvement - Hardware design interaction

Complete flow with edge cases such as manually input apiary and hive info, with more than one beekeeper manage the apiary

Exciting new ideas came up! - A Sneak Peek

Augmented reality solution to help beekeepers find trouble hives immediately

As we rework the whole flow, I also found new ideas especially regarding the hardware interaction. The device was designed to be as simple as possible so it wouldn't attract unnecessary attention from the surroundings since the hive will mostly be placed outdoors. The hives were indeed prone to be disturbed by thieves or wild creatures.

But it was lacking the ultimate indicator : danger indicator. When the beekeeper found something wrong, they would've wanted to find the hives immediately, but due to risk of attracting attention, they can't use red lamp or loud alarm. Since there are no GPS tracker to map out the hive location at the moment, I proposed to utilise augmented reality to check the hives physically without having to heavily modify the physical indicator.

User generated recommendation

As Indonesian beekeepers have trust issues with the suggestions from scientists,
I was inspired from Quora where a solution can be upvote and downvote. With this solution, we can directly compare which solutions works the most with proven records from other beekeepers.

Design Improvement Preview

These are the latest improvement of the design so far, I reworked everything using proven-research-based- design best practices. We aim to achieve comfortable level with this new design concept.

Improvement goals :

1. Increase user's confidence in using the app
2. Taking out any complex-to-use perception from user's mind
3. Increase beekeepers trust that this app will actually be helpful for them

Metrics to be measured

Since we don't know yet when this app will be launched, the early metrics from HEART framework that can be used to evaluate the design from prototype phase are :
1. Task completion rate
2. Willingness to adopt from scale 1-10
3. Happiness - satisfaction rating - scale 1-10

Visual improvement concept

01. Rounded corners

Rounded corners are known to make users process the information easier. With this more rounded corners the app should appear more friendly and less intimidating.

02. Higher contrast

Before, the are some elements with contrast ratio below 3 : 1, in the new improvements I made sure everything were above 3:1 contrast ratio to enhance its accessibility.

03. Reduce cognitive load - Only show what matters - Gradual information processing

Before this, I put all elements on the screen in hoping that user would've access things faster but turns out they would pause and slow their pace a bit to process the informations and then make interpretations afterwards. In the new improvements, I gave them flexibility on how they'd want to process informations, this principles are also applied in other sections, especially in warning systems and hive quick monitoring.

04. Layout designed for eye-scanning

I optimised the layout for eye-scanning, meaning that users won't have to read thoroughly words by words to get a grasp on what's going on with their hives. I utilised cards to categorised the informations to help users easily process the informations. This can be measured using 5 seconds test, asked the users to scan the page in 5 seconds and tell us what are the things they can grasp from the screen.

Interaction improvement concept

01. Quick access (1-3 clicks ) to hives that need urgent action

Other than data, user need a real time warning system that could help them anticipate further damage on the hives. That's why I created special sections for troubled hives that needs urgent resolve so they don't have to go through dashboard and apiary section first.

02. Navigation so simple that if you click all the buttons you won't get lost

The thing about less tech savvy Indonesian is that they tend to be afraid to click on anything or they're afraid they would break the device if they do anything.

The first 3 screens are the screens that have the most button variants, with prioritising where to look first, strictly filter the important elements and make sure every buttons are perceived to be clickable, users can safely and confidently press anything without having to be afraid that they'd get lost. The last screen shows that subpages tend to have 1-2 buttons which should help them navigate through pages confidently because of very limited clickable choices.

03. Flexible monitoring style

Beekeepers can use which monitoring style would suit their context, if they only have limited time and just want to casually check how are their hives doing, they can have a detailed view without having to go through one by one, whereas, if they need more data and information, they can just go to hive details and process from there. In the end, the decision is still within the beekeepers judgement.

To Be Continued : New design and design system audit is still on progress. Still a long journey, but it's a great start!

We are now in the journey of creating the design and features improvements as well as auditing previous design and experience for newly designed design system.
Hi! The mobile version is still on progress, in the mean time please view through desktop for optimised viewing, Thank you! :)