'Don’t judge a book by its cover' is a well-known cliché. And, while I agree completely with the principle, I’m the first to admit I’m guilty of it just the same. Today, more than ever, users are inclined to purchase based on packaging or advertising where contents may be identical or similar.
Today some 89% of Australians are consumers of digital content and we have a seemingly endless selection of it to choose from. Given our vast choice of content, we, as users became increasingly more discerning.
It wasn’t too long ago when we were happy if an app had a mobile version or a responsive site. Now, the options available mean that we will not put up with anything less than delightful. And, once we find that piece of delightful software, we tend to stick to it. We all know this first-hand, being daily consumers of digital content and knowing our own devices intimately. With the importance users place on their experience with today’s online content, entrepreneurs building new software are usually fully aware that they require UX, and they need it to be excellent.
We’ve recently run usability studies on an application for a financial product where, after a user inputs a couple of screens worth of data, a tailored product solution appears. We had a nice prototype, and all was well except for one thing…
During the usability study, we received the following feedback: the recommendation arrived too fast. Wait, what? Yes, the results arrived too quickly after the user hit send, which made people think that it wasn’t real. Some of the user feedback was “there’s no way it could’ve looked at my data in such short amount of time…”, “I don’t think this is real, because it hasn’t spent any time thinking about it…”, “I wouldn’t trust this product, it made me fill in screens of data but then ignored it all when giving me the recommendation…”, or, in some cases, people were expecting to continue filling in more data and didn’t entirely believe that the screen they were looking at was the solution and not just another screen requiring more information.
Lately, I’ve received a few questions about what a user experience review / heuristic review or evaluation / UX expert review is and isn’t and when it’s a good idea to have one. I thought I’d share a few of the questions and answers on what it is, what you can expect from it and roughly what sort of commitment it requires from a businesses’ viewpoint.
Let’s start with the common element in all three of the above-mentioned names for it. Yes, it’s a review. It evaluates an existing system against best-practices in the industry. It is performed by an expert in user experience design or Human Computer Interaction (HCI) and results in a report with key findings and action items that you can use to improve your product. It’s a so-called “inspection method” because it doesn’t involve users but it is based on principles derived from watching users interact with online systems. It results in a list of issues found and ranked by severity - usually a scale of 5 (minor, low, moderate, high, critical), but some UX designers use a different system.
The hands down best thing to do before building your next software project is to invest in a set of rapid prototypes. What do I mean by a prototype? Here's an example: http://ux.reinteractive.net/C3F2ZS/#p=introduction
For those of you who are too scared to click on the link I salute you for your security paranoia and offer the following description: A prototype is an interactive, clickable schematic structure of your final product and represents the experience the users will have with your application.
This isn't a strictly web app related topic, however it does have a strong online component. We build applications to solve our client's problems. Whatever we build are mere tools used to get certain things done. Take loyalty programs as an example: last time I moved house, I had to shop a lot - both online and in real life. As a direct result of this, I am now a member of several loyalty programs (I'm one of those people who doesn’t mind giving out their personal information to get a tangible benefit). I wouldn’t like to get into the details of whether or not this is a good thing - it clearly depends on the benefit you get. What I'd like to point out are some of the most common user experience hurdles encountered while trying to use some of these programs.
The member number is something you generate so that you can attach rewards to a member. Making them remember this number and enter it every time they log in to your online platform is troublesome. Why not use an email address instead?
Back in 1999, two scientists called Daniel Simons and Christopher Chabris developed a fun little experiment involving a gorilla. Okay, not a real gorilla, but someone dressed as one. It has since become one of the most famous psychology experiments showcasing inattentional blindness or selective attention. So, what is this about? You can watch the video here, if you’d like to try it out before reading on.
It goes like this: Participants are watching a basketball game between people dressed in white and black t-shirts. The task is to count how many passes the white team makes. During the game, a person dressed as a gorilla shows up, does a little dance then walks out of the scene. Half of the participants to the experiment reported not seeing the gorilla at all. As the experiment’s authors put it: “This experiment reveals two things: that we are missing a lot of what goes on around us, and that we have no idea that we are missing so much.”
Before every major new application is built reinteractive recommends getting prototypes built before development starts as we want to make sure what we build will be wanted by the people using the application. A prototype is a clickable wireframe that allows the user to experience the interactions of an application. Essentiality the user can walk through the application and experience the work flow without the input making any difference to the interaction. An example is here. We have found that every project that starts with a prototype has very good communication throughout the project as everyone can point to the prototype to discuss functionality. Good communication is the number one factor that leads to success in a software project. To put it another way building a prototype before a project helps a project be delivered on time and on budget as time is not wasted building features that are not wanted. reinteractive prototypes cost around one tenth of the price of development and are very easy to change. Changing an application once actual development has started can be both time consuming and costly.
There have been several projects recently that have changed dramatically during the course of a User Experience consultant's involvement.
This is a story about a first-hand experience I had recently with a service. I am not naming the service, the goal of this post isn’t to name-and-shame. Instead, I want to highlight an issue that happens on various websites all over the web. I am a user experience designer by trade. I am also a “regular user”, sometimes, though my experience with the web and UX usually makes me a bad usability test participant. Regardless, on with the story.
I am moving house in the near future, so I went online to look for moving companies. I found one that also offers re-usable boxes for free if you book your move with them! Sold. On to the booking process. Since I haven’t moved the current contents of my home before, I have no idea about the size of truck I need. Is the smallest truck big enough? I’ll select it to see what happens. To my relief, a help text appears as soon as I select the option. “Ideal if you are only moving a few large pieces of furniture”... Hmm, that’s not me, I’m moving the whole house. Finally I settle on the “ideal for 1-2 bedroom apartments” option. All good.
We have reached the point where if your business doesn’t exist on mobile you are suffering serious disadvantages regardless of what you are selling or providing. Deciding between what to build is a topic that needs its own blog post. Discussing the native app, hybrid app vs mobile website/responsive website topic is a separate one that I wouldn’t like to get into today. For the purposes of this post I will assume that you have decided on the right solution for you and that happens to be a native app. What can you do to ensure its success?
Context is crucial to the success of any app. With the web it’s easy - people will be using it while sitting at a desk or at least sitting with a laptop somewhere. With mobile, it can be any number of places and situations. If you’re building an app for runners, think of what features they can and should access while running. For example, for a runner it’s very useful to know their heart rate, their speed, track their movements on a map, see how many calories they’ve burned and have the ability to share their progress with their peer group. All of this is great to have in a mobile app, but should you have it all present at once? Or does it make sense to have a big “Start/Stop” button that takes up the whole screen? If you go with the start/stop button, how large should it be? What’s the ideal size to prevent accidental taps while in motion, but at the same time prevent the runner from having to stop to activate it? Or, what about a GPS app for mountain climbers? They probably don't have available hands to fiddle with their device while trying to keep safe. What features are still useful, and how can you ensure that your app is actually usable in the real world?
