How we put the ‘Easy’ in Easy LMS

Having a product with a lot of functionalities can be hard to understand. For us, it is a constant balancing act between quickly adding new features and making them easy to use. That is where our usability guidelines come into play. They help us make design decisions, prioritize what we should do to make it usable in the first place, and determine what can be improved during a later iteration. By working this way, you do not have to wait until the feature is picture perfect and you as a client can already benefit from using the new feature.

Levels of usability

Some features, unfortunately, will always require a little more thinking

Some features or functionalities are complex by nature, such as setting up integrations with other systems. That is why we have defined different levels of usability. To make it explicit, not all of our guidelines have to be applied for every feature we work on.

Taking the example of integrations, we can make it super easy on our side, but we don’t have any influence on the usability of the system you are setting up the integration with. Furthermore, it might include some coding or advanced settings across multiple systems. Therefore it will most likely never be an effortless task to complete. It is something that is more Advanced by nature. Especially if something goes wrong, it is sometimes hard to tell which side is causing the disruption in your flow 😉.

I have secretly introduced you to two out of our five levels of usability in the previous paragraph. Let me share the others with you:

• Mundane tasks should be made effortless.
• Challenging tasks should be made easy.
• Advanced tasks should be made feasible.
• Sophisticated tasks should be made supported.
• Tasks that we are not planning on supporting.

Let me make this a bit more tangible. Some features, such as adding questions, are Mundane things to do. We want them to be effortless. In order to get there, we want all of our usability guidelines to be applied. Other features, such as setting up single sign-on, are inherently more complex. Yet, we still want to support this functionality. In the case of a Sophisticated feature, like this one, there are fewer guidelines that need to be adhered to.

But how do we make sure that the user experience has been optimally designed for all the determined levels? What do we need in order to get it done? Let me introduce you to our process.

Guidelines in action

Picking what we work on

First, we decide which feature to work on in the first place. We go through a batch rating process comparing the importance of different high-priority features to determine the most pressing thing to work on.

I will use our export buttons as an example. They enable the exporting of the results of participants to a file you can view and crunch further in Excell. The image on the right shows how they all used to look. From this button, you do not know the behavior that it has. Do you have to wait for all the data to compile first, or does it download straight away? Because of all this unclarity, we decided to pick it up.

Determining the current state

Next, we assess what level of usability the feature has by going through the guidelines that should be applied. We then also determine which level we want to aim for. This might differ from the end goal, as it might be too big of a step to take in one iteration. By doing that we know which guidelines we should focus on during this iteration to ensure the best possible user experience.

For each iteration, we mainly focus on improving one guideline at a time. This does not mean that the other guidelines are not taken into consideration at all. We just want to improve at least one thing at a time as Jeroen reminded me once, speed is quality too. “We work in short cycles because it has proven that it is actually faster and has better results, but it means taking tiny steps and not everything will fit in,” explains Anouk, one of our front-end designers.

We rather release a new or improved feature quickly, than take ages to do it perfectly

We determined that the process of exporting your results should be Effortless. This means that all of our guidelines have to apply. The button broke our Predictability guideline which states that clients should be able to understand how to interact with a feature and successfully predict the results. That is what we decided to focus on for this iteration.

Finding a solution

Then, as soon as we discuss possible solutions, we decide which of the guidelines is the most important to improve on at that time. The way in which we will do that is then included in the proposed solution. And then it is finally time to start making it happen!

As mentioned before, there were basically two things that could happen when clicking the export button. You either have to wait for a little before it downloads, or it will download straight away. To make clear what to expect, we designed a button for each of the two scenarios.

The Start Export button (see image on the right) implies the waiting time through the use of the icon. The wording also shows that you will start the process of exporting so you will not have an immediate result.

The Export button (see image on the right) shows it will download straight away because of the universally used icon for downloading. The wording implies that it is a one-click action and that the data is available straight away.

Evaluating the improvement

Lastly, once the development part of the story is done, the team tests it by going through possible scenarios based on the acceptance criteria. By doing this we can assess whether the standards for the guideline(s) are met. When testing is completed successfully we release the story and you can use the new or improved feature too 🙂.

Because of the improvements we made, we determined that the requirements for the predictability have been met. Because the other guidelines were applied already we can say that this is Mundane!