Latest Articles on Ux by Our Team

Back in 1976, the idea of personal computing was somewhat different to that of today. The Apple I computer sold 175 units, and was considered revolutionary for its time. It came with one small catch – you had to build your own case.

A modern comparison to the original Apple I computer would be the raspberry pi, which has sold an impressive 12.5 million units. It too, requires you to build your own case.

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.

Dashboards are often the backbone of a good web app as they can be used to present large amounts of data in a condensed and visual form. In general, the more complex the app is, the more it can benefit from a well-structured, clear dashboard that helps users understand at a glance what the system and the underlying data is doing. We all use dashboards in our day-to-day lives, from the dashboard in our cars to the display on the thermostat that controls our air conditioner. In this case, I prefer to focus on the web ones.

So, how can we, as designers and developers, make sure that our web app dashboard is efficient?

It’s a relatively new discipline and, even though the definitions and standardised methods have been around for decades, everyone tends to interpret it their own way. Some have dedicated UX people and some have entire teams working on it. Others use UX and UI interchangeably to refer to “everything on the user side”. This is why it's always a good idea to clarify what exactly you get during a UX engagement, and based on that, decide whether you need it or not.

Here, at reinteractive I am the Lead UX specialist and work with our customers directly to work out their app’s requirements. My role, in a nutshell, is reconciling business needs and user needs in a way that is technically feasible within the time and budget. I don’t do it alone, of course, I have a cross-disciplinary team of designers and developers in my corner.