Here at Pingdom when we develop a new product or feature, there is always one thought we go over and over (and over!): “what will the user’s experience be like?” User experience is the central point from which we build our products.
It’s easy to say that you’ve taken the user experience into consideration when building a product and present your shiny handiwork with all its bells and whistles. However, if setting your product up is frustrating, people are simply going to avoid it, no matter how cool it looks.
One of our UX designers put it succinctly:
“I define UX as what happens in a user’s head when they use our product.”
In essence, there is a big difference between user interface (UI) and user experience (UX).
User experience defines the user interface
Although UX and UI go hand-in-hand, you can’t just paint on a shiny interface and proclaim your software to be user friendly. When we set to building an interface for one of our products, we take a long hard look at whether it allows the user to do what they want easily and intuitively.
Hiding your software’s features and settings behind a poorly labelled hamburger menu might look tidy but your users will have a hard time finding what they are looking for. We’ve clearly labelled our menu so our users can get to what they want quickly.
Build your software based on how your users want to experience it not on how you want it to look.
Your users don’t live in a bubble
We know that a user’s experience of a product fluctuates depending on their environment. Just because you like a double espresso as your morning pick-me-up doesn’t mean you’d appreciate it quite as much at 11 o’clock at night.
When developing our incident management interface, we realized our users don’t just use our interface from the comfort of their ergonomic office chairs. An (un)lucky few would have the pleasure of being alerted in the middle of the night.
Eyes don’t behave nicely with bright screens in dark places, especially if you’ve just opened them. We built our incident management tool with a low-light interface so you can respond to an alert without burning off your retinas.
We also built in severity level functionality into the alerting, so you wouldn’t be awoken unless really necessary.
One size does not fit all
A common UX mistake is assuming that just because you find your software intuitive, you think your users find it intuitive too. Of course you think it’s intuitive and navigable: you built it!
If, like us, you have many types of users using your software, you need to cater to users who might not be the most tech-savvy.
We designed our interfaces with all of our users in mind. To do this, we identified specific types of users that operate our applications, or personas as we like to call them.
For example, a front-end developer might use the Page Speed Check to see what elements might be slowing a site down whereas an ops manager would need fast and effective incident management. The way these two personas interact with our products can be vastly different. In fact, we took speed and efficiency as paramount factors in defining our products’ UX: we implemented simple set ups for our tools using modal windows. You simply enter a URL and name it and we take care of the rest for you.
It’s a thin between too much and too little
By approaching our products the same way a front-end developer, CTO, or ops manager would, we tailor the way we build our user interface to match to expected experience of each user type, or persona.
There’s no point showing lots of information to a user on one screen if they just want to check whether a site is up or down. On the other hand, if you hide it all behind menus and submenus, you can expect frustrated users.
The bottom line is that what works for you right now might not be as effective later on and so we’re listening to our users’ feedback and testing out new ways of letting you do what needs to be done in the most effective manner.