As your audience grows, it is important to ensure that your website or application can be used by everyone - specifically people with permanent or temporary disabilities. This is often referred to as accessibility (or A11y as an abbreviation), and is a requirement for all modern websites or applications.
Recently I had the task of taking assessment data and drawing it on a graph so that it matched the design below:
When creating a new webpage or app, there comes a time to decide: should I use a front-end framework (like Bootstrap) or write my own CSS (front-end code) from scratch?
As a front-end developer, I get asked this question a lot. I have worked on many projects in a number of different ways and, like anything, there are pros and cons to both. I will go through a few factors to consider, and review some front-end frameworks that I have used in the past.
The internet is the perfect medium for people with disabilities. It breaks down barriers, brings people together, and allows them access to information that, in turn, empowers them.
Australia's recent postal survey raised the issue of how inaccessible it was for people with disabilities or for whom English is not their first language. These people were unable to vote without assistance. Had this survey been conducted on the internet, everyone could vote, regardless of where they live, and whatever their disability or native language.
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.
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.