HEMA Smart is an application made by HEMA. As expected this app is made to connect and interact with smart objects they also sell. The app is great but small detail such as empty states and performance can get in the way of an overall good experience.
The best way to describe the issue to you, is to tell you a user story, mine actually, before we jump into some learning from this short story.
When being a power user doesn't help you
This application is made for your daily small tasks. You can create:
- Tap-to-run tasks: those are small buttons you can tap to start a succession of tasks.
- Automation tasks: those are automated tasks you can program depending on weather, time, etc.
I use a lot the tap-to-run tasks with which I've made actions to create ambiances in my living room depending on my mood, or simply turn off simultaneously all the lights in my flat.
Here is what you could see on my phone when I start the App.
HEMA Smart has a Forecast component...
I don't know why, HEMA decided to put on the first position on the screen something that is not related at all with the primary thing this app or at least this specific screen is suppose to do: give you control over your tasks.This thing is the current forecast. Why? Why do I have this by default, and also why is it the first element of the home screen of this app?
I already have a sensor in my house to know that, also, I can guess the weather by looking at the window, or just another app made for this purpose, with real forecast of the next hours, which is more useful than the current one.
But anyway, even if it's a debatable choice here, (and I'm using it sometimes) the main issue isn't even the existence of this component, but the fact that this component is conflicting with the usability of this app.
As you can imagine, even before I open the app to do the thing I want to do, I'm already picturing it in my mind and know exactly what colored button I want to tap. So when I open the app, I tap quickly on the blue button named "Bright" when I want a bright light. Done. Or not...
When you load the home screen you have this first screen for around 1s to 5s, then the forecast component is loaded and pushes the content down.
The forecast component is higher than the line of Tap-to-run tasks (the colored buttons), so when the component loads... Yes! You get it right, I accidentally tap the forecast component and get directly to the detail page:
Yes, there is a detail page so that when you tap on this non-primary-need-component you are trapped and need to go back to eventually find what you come for in the first place.
Widget to the rescue
The good thing with Android is that we have customizable widgets. Yeah I know, now you have them too on iPhone ;p
HEMA developed a widget for embedding the Tap-to-run actions into a small bar of actions. Really handy. So handy that I'm not even using the app anymore, mostly because of this jumping interface that I want to call a bug.
Content hierarchy is key
In fact, this bug isn't a bug, it's a defect that could have been avoided with a proper content analysis and user research.
To keep it simple here, when you work on the content of a mobile app (or any type of content actually), you need to prioritize things that appears on the page : the order, the space it takes, the visual importance, etc.
As I'm not a designer for HEMA company, I can't be sure about the specification and the objectives here, but I'm pretty sure that if the app is made to give you control over your smart objects, the first thing you want to do isn't getting more info or detail about the weather outside…So, why is it in the first room of the home screen of this app?
Well, I don't know either, but what is sure is that if you reverse the position of the custom actions with the weather component, it fixes a lot of usability and accessibility issues. If you put at the end the secondary components, it helps you use the primary components easily.
Obvious, isn't it?
Performance and fake content
When you build an app made of components that loads information from third-party services, or even from your services, never expect the response to be instant. It never happens the way we want it to, and even if it's quite fast, you'll always fall into delayed server one day or another.
To prevent this kind of issue, and to avoid jumping interfaces, we have built what we call "skeleton interface", or "placeholder interface".
It doesn't make the position of this component right, it allows the user to expect something here while the app is loading the information and just before putting the server response into the dedicated rooms. The user won't be surprised by a jumping interface anymore.
What we've learned from HEMA Smart issues
Let's sum up what we've learned here and see what we can do better as designers next time we build something similar:
- On small screens, the space available for important and less important stuff is reduced. You need here more than on bigger screen to focus on what's really important for the user. Each screen on an app needs to have one or two purposes maximum, and if you have more objectives per page, take the time to prioritize them in order to avoid the HEMA issue we just met.
- When you expect answers from services, data, that takes time to arrive, reserve the space on your screen by faking its content in some way.
A bit of reading outside this blog:
- Everything you need to know about Skeleton screen
- Mind over Matter: Optimize Performance Without Code
