Hoe we 'Easy' in Easy LMS stoppen

Een product hebben met veel functionaliteiten kan moeilijk te begrijpen zijn. Voor ons is het een constant balanceren tussen het snel toevoegen van nieuwe functies en het gebruiksvriendelijk maken ervan. Dat is waar onze bruikbaarheidsrichtlijnen om de hoek komen kijken. Ze helpen ons ontwerpbeslissingen te nemen, prioriteiten te stellen bij wat we moeten doen om het in de eerste plaats bruikbaar te maken en te bepalen wat er tijdens een latere iteratie kan worden verbeterd. Door op deze manier te werken, hoeft u niet te wachten tot de functie perfect is en kunt u als klant al profiteren van het gebruik van de nieuwe functie.

Niveaus van bruikbaarheid

Sommige functies vereisen helaas altijd wat meer denkwerk

Sommige functies of functionaliteiten zijn van nature complex, zoals het opzetten van integraties met andere systemen. Daarom hebben we verschillende niveaus van bruikbaarheid gedefinieerd. Om het duidelijk te maken: niet al onze richtlijnen hoeven te worden toegepast op elke functie waaraan we werken.

Als we het voorbeeld van integraties nemen, kunnen we het aan onze kant supergemakkelijk maken, maar we hebben geen invloed op de bruikbaarheid van het systeem waarmee je de integratie opzet. Bovendien kan het coderen of geavanceerde instellingen voor meerdere systemen inhouden. Daarom zal het hoogstwaarschijnlijk nooit een moeiteloze taak zijn om te voltooien. Het is iets dat van nature meer geavanceerd is. Vooral als er iets misgaat, is het soms moeilijk te zeggen welke kant de verstoring in uw stroom veroorzaakt.

In de vorige paragraaf heb ik je stiekem kennis laten maken met twee van onze vijf niveaus van bruikbaarheid. Laat me de andere met je delen:

• Mundane taken moeten moeiteloos worden uitgevoerd.

• Uitdagende taken moeten gemakkelijk worden uitgevoerd.

• Vergevorderde taken moeten haalbaar worden gemaakt.

• Geavanceerde taken moeten worden ondersteund.

• Taken die we niet van plan zijn te ondersteunen.

Laat me dit wat tastbaarder maken. Sommige functies, zoals vragen toevoegen, zijn alledaagse dingen om te doen. We willen dat ze moeiteloos werken. Om dat te bereiken, willen we dat al onze bruikbaarheidsrichtlijnen worden toegepast. Andere functies, zoals het instellen van eenmalige aanmelding, zijn inherent complexer. Toch willen we deze functionaliteit ondersteunen. In het geval van een geavanceerde functie, zoals deze, zijn er minder richtlijnen waar we ons aan moeten houden.

Maar hoe zorgen we ervoor dat de gebruikerservaring optimaal is ontworpen voor alle vastgestelde niveaus? Wat hebben we nodig om dit voor elkaar te krijgen? Laat me je kennis laten maken met ons proces.

Richtlijnen in actie

Kiezen waar we aan werken

Eerst beslissen we aan welke functie we gaan werken. We vergelijken het belang van verschillende functies met een hoge prioriteit om te bepalen aan welke functie het dringendst moet worden gewerkt.

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.

De huidige status bepalen

Vervolgens beoordelen we welk niveau van bruikbaarheid de functie heeft door de richtlijnen te doorlopen die moeten worden toegepast. Vervolgens bepalen we ook naar welk niveau we willen streven. Dit kan verschillen van het einddoel, omdat het een te grote stap kan zijn om in één iteratie te nemen. Zo weten we op welke richtlijnen we ons tijdens deze iteratie moeten richten om de best mogelijke gebruikerservaring te garanderen.

Bij elke iteratie richten we ons voornamelijk op het verbeteren van één richtlijn per keer. Dit betekent niet dat er helemaal geen rekening wordt gehouden met de andere richtlijnen. We willen gewoon ten minste één ding tegelijk verbeteren, zoals Jeroen me eens herinnerde: snelheid is ook kwaliteit. "We werken in korte cycli omdat bewezen is dat dit sneller is en betere resultaten oplevert, maar het betekent wel dat we kleine stapjes moeten nemen en dat niet alles erin past", legt Anouk, een van onze front-end designers, uit.

We brengen een nieuwe of verbeterde functie liever snel uit dan dat we er eeuwen over doen om het perfect te doen.

We hebben bepaald dat het exporteren van je resultaten moeiteloos moet verlopen. Dit betekent dat al onze richtlijnen van toepassing moeten zijn. De knop brak onze richtlijn voor voorspelbaarheid, die stelt dat klanten moeten kunnen begrijpen hoe ze een functie moeten gebruiken en met succes de resultaten moeten kunnen voorspellen. Dat is waar we besloten ons op te richten voor deze iteratie.

Een oplossing vinden

Zodra we mogelijke oplossingen hebben besproken, besluiten we welke van de richtlijnen op dat moment het belangrijkst is om te verbeteren. De manier waarop we dat gaan doen wordt dan opgenomen in de voorgestelde oplossing. En dan is het eindelijk tijd om het waar te gaan maken!

Zoals eerder vermeld, konden er in principe twee dingen gebeuren als je op de knop Exporteren klikte. Of je moet even wachten voordat het wordt gedownload, of het wordt meteen gedownload. Om duidelijk te maken wat je kunt verwachten, hebben we voor elk van de twee scenario's een knop ontworpen.

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.

De verbetering evalueren

Tot slot, als het ontwikkelgedeelte van het verhaal klaar is, test het team het door mogelijke scenario's te doorlopen op basis van de acceptatiecriteria. Hierdoor kunnen we beoordelen of aan de normen voor de richtlijn(en) is voldaan. Als het testen succesvol is afgerond, geven we de story vrij en kun je de nieuwe of verbeterde functie ook gebruiken ?.

Door de verbeteringen die we hebben aangebracht, hebben we vastgesteld dat aan de eisen voor voorspelbaarheid is voldaan. Omdat de andere richtlijnen al zijn toegepast, kunnen we zeggen dat dit Mundane!