"User-friendly" does not mean "simple to use"

Designing user-friendly software

We tend to associate user-friendliness and simplicity. Often, however, the opposite is true.

“User-friendly” means that the system is friendly to the user; not the stakeholders or the metaphorical mother. Users can sometimes be very knowledgeable, both about the system and technology.

To a software developer, this UI is user-friendly

To a pilot, this UI is user-friendly

To a designer, this UI is user-friendly

To a hardcore gamer, this UI is user-friendly

To a 4-year-old, this UI is user-friendly


So how do we design user-friendly software?

1. Observe users

UX designer Donna Spencer nailed it when she said: “I can design something decent whether we involve users or not. The difference between the two is that if I don’t involve them, we’ll make mistakes and not know we’ve made them. “

The main key to a user-friendly software is involving users, and this starts with simple observation. Watch how users work with their current setup. Learn their habits, their proficiency level, the frequency and speed at which they learn to use new systems.

2. Build personas

Personas are fictional depictions of actual users. By building fake users based on real, observed data, the development team and stakeholders will have something to refer to when having to make design decisions.

Personas can’t be 100% accurate. They can lead you to focus on stereotypes that aren’t always true. But there’s a saying in the industry that states: better to have any focus than no focus at all.

3. Observe some more

As early as possible, test your design with actual users. Go out there and watch real people use your prototype or semi-functional application. You will learn a lot by watching them struggle with features you thought were clear.

This step does not need to be complex. Simply going out in the field and putting the controls in the hand of an actual user will give you and the whole team great insights.

Because it is so much easier to develop something right the first time than to adjust it later, testing often and testing early will save a lot of development time.