Same thing we did back when we introduced iomando version 2, this article explains the reasoning behind some of the design and product decisions we have taken. Here you'll find some insights of the design process and the challenges we've faced developing both software and hardware products.
Last month we released iomando version 3, which brought a new mobile app and also an updated hardware lineup. Despite the whole update brought with it more than 30 new features, on this post I wanted focus on the Unified View and the Sorting Algorithm, because both of them have been the most challenging from a design standpoint.
Arguably one of the most notable changes we've introduced to the mobile app it has been the Unified View. With Unified View we have departed from separate navigations for both the Space List and the Access Screen, to an integrated, more intuitive and straightforward visualization.
Why we did it?
Back in version 2, we had different views to select the Space you wanted to access and the access action itself. It was like that because when we introduced version 2 the management tool was still integrated within the mobile experience.
The assumptions we were designing around have changed though. Houses and small communities are not our primary customer anymore. Our main clients are now large spaces, with multiple accesses in each of them, therefore we needed to provide a way that made the access experience intuitive, fast and reliable in this new environment.
The old layout didn't work under these assumptions because:
- Navigating through Spaces was not easy because you had to jump through different screens.
- Each Space could only afford 4 accesses because of the button design. Moreover, you couldn't possibly know which access belonged to each button, because there was no label in them.
iomando version 2 mobile app did great so far, but it was never intended to perform in this new scenario and it was clearly not getting the job done for our customers. We had to come up with a different approach in order to deliver value in this new environment.
It wasn't until we introduced a standalone tool to manage the Spaces that we could finally design the app around the assumption that it was only intended to access. This focus freed us from the constraints that all the management blocks presented, thus we could rebuild the experience from the ground up and further enhance the access capabilities.
The purpose was to blend the Spaces where the access itself takes place. The main problem we faced though, was complexity: because if you had 4 Spaces with 10 accesses each, you were presented with 40 choices. The feature of "all your accesses in one place" now becomes a nightmare.
The ultimate access experience tells us that we need to ideally solve for two problems here:
- Content structure: the visualization of the Spaces and accesses has be comprehensible for the user. The distinction of the two elements, but also the subtle relation between them (access belongs to Space) has to be clear at a glance.
- Access priority: ideally, the app should guess beforehand the access you wanted to open. Then it should present you this access like the first and only option.
Something like that would solve for both context, because you'll know what you are accessing at any given time, and also for smoothness, because the access you wanted to trigger would already be presented to you, no need to look for it.
Despite crafting a great visualization model was totally up to us, the ultimate access predictor machine was not fully developed, yet ;) But still, we could make educated guesses about which door a user might wanted to open at any given moment. Our available sources of information were:
- Patterns: which accesses are usually opened at any given time. Say the user opens her home door everyday at around 6:00pm.
- Recursion: how frequently the user accesses certain Spaces.
- Geolocation: how far the user actually is from each of the available Spaces.
With this information we can’t be 100% positive about which access the user wants at any given time, but we can come pretty close. So we developed a sorting algorithm that ranked the Spaces and accesses in a way that matched the user’s (predicted) intentions.
If it was 5:58pm, and our hypothetical user was pretty close from home, which by the way is the most used access, the moment she opens the app she'd presented with her home access. I know this example was an easy guess, but the point is that the algorithm learns from the user's actions and gets better the more you use it.
The challenge though, was to design a way to present the algorithm's results is a way the user could easily understand. We tried with several approaches before settling with the definitive design. It's worth noting that part of the team was particularly sold on the idea of bubbles that grew correlated with the probability defined by the algorithm. What was convincing about this idea was that it gave a dynamic sense of relevance, therefore it was more tolerant when we guessed our first choice wrong.
Let me explain: say the probability of not guessing right the first option was 25%, consequently 1 out of 4 cases we were going to fail. Although, the chance that the right guess ranked among the first 3 was pretty high. Therefore if the accesses took relevance by probability, tests showed us that the user tended to naturally shift to the second biggest bubble quickly.
The problem with this approach was that it was chaotic. The UI never looked the same because percentages were changing all the time, and despite we limited the amount of sizes a bubble could adopt, the user felt lost most of the time.
After iterating on many designs, at the end, we felt really comfortable with this particular trend.
Spaces lay at the bottom of the screen. They are easy to navigate because the swipe gesture is embodied in most of the built in experiences on both iOS and Android, like swiping the home screen. People perceive it as a natural thing to do, we don’t have to teach them anything new. The dots at the bottom also give some clues to how many spaces there are.
The accesses are the bubbles in the row above. The bubbles on display always belong to the Space below. They show its name and also the distance to the access. Despite you can scroll this row, too, the main point is that the algorithm will always give you the access you probably had in mind. So we hope our guesses are right and most of the time the access is already visible.
Additionally if you swiped up the Space you got all the Space information. Space information was something that got a lot of attention in iomando v2, but truth is that few people cared.
After applying some brand new design colors, the home screen finally ended up as you might know, like this:
The UI is definitely clearer than it was before. The interface can finally handle all the accesses overload in an understandable way, helping the user focus on the first available choice, although moving to the following options also feels pretty straightforward.
 This button split was introduced - almost as a "hack" - when version 2 came out to solve the problem of houses having 2 or 3 doors. It worked for them because it was like having a physical remote with two buttons, you just remember without a label. It was never intended to manage accesses at this new scale and it was clearly not getting the job done in those places.