Accepteer nooit oplossingen van je gebruikers

Telkens wanneer mijn baas naar me toe komt met een functie die hij graag zou willen zien, herinner ik hem altijd aan het mantra "Denk niet in oplossingen maar in problemen". Het klinkt vreemd, maar laat me het uitleggen.

Laten we beginnen met wat wiskunde, maak je geen zorgen, we gaan niets daadwerkelijk berekenen. Als je de oppervlakte van een cirkel wilt weten, pak je eenvoudig de juiste formule en vul je de straal van die cirkel in. En voilà, je hebt de oppervlakte van die cirkel, behalve natuurlijk als je de diameter van die cirkel gebruikt in plaats van de straal. Een fout die snel gemaakt kan worden maar resulteert in een volledig verkeerd antwoord. Hetzelfde geldt voor computersystemen, een processor is niets meer dan een rots waar we wat wiskunde aan hebben geleerd met behulp van bliksem. Als we een systeem ontwikkelen dat feilloos werkt maar het systeem de verkeerde input geeft, levert het de verkeerde resultaten op. Het kan dat niet corrigeren, omdat het programma niet weet dat het de verkeerde invoer heeft gekregen. Simpel gezegd, troep input leidt tot troep output.

Bij het ontwerpen van oplossingen geldt hetzelfde idee, het belangrijkste is om het probleem dat je oplost goed te krijgen. Wat moeilijker is dan het lijkt, want de gebruiker zal je precies vertellen wat ze nodig hebben, toch? Helaas niet. Je gebruikers zijn slim, vaak te slim voor hun eigen bestwil, en zullen proberen het probleem zelf op te lossen. Wat hen, toegegeven, soms zal redden van de moeite om uit te zoeken hoe ze hen het beste kunnen helpen. Maar als ze er niet uitkomen, zullen ze vragen, maar wat ze vragen is niet altijd wat ze nodig hebben.

Problemen met voorgestelde oplossingen

Een verzoek dat de gebruiker kan hebben is "De website moet beschikbaar zijn als een progressieve web-app." Dat kan natuurlijk handig zijn, maar als hun daadwerkelijke probleem is dat de interface moeilijk te gebruiken is op hun telefoon, zal het simpelweg toevoegen van de bestanden en metadata voor de website om te kwalificeren als een progressieve web-app de interface niet verbeteren. Het beste geval is dat je naar de website op mobiel kijkt en tot dezelfde oplossing komt als de gebruiker. Waarschijnlijk heb je hier echter ook niet de middelen voor en houd je je gewoon aan het oorspronkelijke plan om er een manifestbestand tegenaan te gooien.

Wat ik zojuist heb beschreven, wordt soms het XY-probleem genoemd. Iemand vraagt om oplossing X, maar wil eigenlijk probleem Y oplossen. Er is een disconnectie tussen het onderliggende pijnpunt van de gebruiker en de gevraagde oplossing door hen. Enkele voorbeelden zijn:

• Oppervlakkige bestandsmanipulatie: In plaats van te vragen hoe je een bestandsextensie kunt ophalen (Y), kan iemand vragen hoe je de laatste drie tekens uit een bestandsnaam kunt extraheren (X). De beperkte focus van de vraag negeert het feit dat bestandsextensies in lengte en structuur kunnen variëren, wat de robuustheid van de oplossing beïnvloedt. Het kan werken in sommige situaties, maar zeker niet altijd.
• Verstoorde tekenreeksmanipulatie: Iemand kan vragen hoe je een tekenreeks tussen twee delimiters kunt verkrijgen (X), in plaats van te begrijpen hoe je JSON moet parsen (Y), wat kan leiden tot suboptimale oplossingen voor gegevensmanipulatie, waarbij het bredere context van hun informatiebehoeften over het hoofd wordt gezien.
• Beveiligingsproblemen met wachtwoorden: Men kan aandringen op langere verplichte wachtwoorden (X) in plaats van andere beveiligingsmaatregelen zoals tweefactorauthenticatie (Y) te implementeren, wat de beveiliging van de website kan compromitteren door een robuustere en gebruikersvriendelijkere benadering van authenticatie te negeren.

Als gevolg van het aanpakken van het verkeerde probleem krijgt de gebruiker een onjuiste oplossing aangeboden die de pijnpunten die ze mogelijk ervaren niet aanpakt, waardoor ze achterblijven met een onbevredigende oplossing en veel verspilde tijd. De verkeerde conclusie om hieruit te trekken, zou zijn dat de gebruiker fout is en de juiste vraag had moeten stellen vanaf het begin. Ik vind altijd dat die last op de ontwerpers en ontwikkelaars moet liggen, zij zijn tenslotte de experts.

Hoe vind je de problemen van de gebruiker?

Omdat gebruikers met de verkeerde oplossing voor hun pijnpunten naar je toe kunnen komen, is je reactie op hun verzoeken cruciaal om hen te helpen. Zoals eerder vermeld, als je het klakkeloos accepteert, help je hen misschien helemaal niet. In plaats daarvan zou je meer problemen voor hen en jezelf kunnen creëren in de toekomst. Daarom moet je een benadering hanteren die verder gaat dan het aanpakken van de gepresenteerde oplossing. De sleutel ligt in het stellen van doordringende vragen om de kernproblemen te vinden en hen vervolgens te begeleiden bij het verwoorden van hun gewenste resultaten binnen de context van hun vereisten.

Ontwerpers en ontwikkelaars kunnen een reeks doordringende vragen gebruiken om deze kernproblemen te identificeren, enkele essentiële vragen kunnen zijn:

• Wat is het uiteindelijke doel dat je met deze oplossing probeert te bereiken?
• Zijn er gerelateerde kwesties of uitdagingen die je niet hebt genoemd?
• Kun je meer context geven over het bredere probleem waar je mee te maken hebt?
• Zijn er specifieke beperkingen of vereisten waar we rekening mee moeten houden?

Door gebruikers aan te moedigen hun doelstellingen en beperkingen te verwoorden, kun je de informatie leren die nodig is om hun probleem aan te pakken in plaats van te focussen op een specifieke oplossing, waardoor een meer holistische benadering van probleemoplossing ontstaat. Maar alleen vragen stellen is niet altijd voldoende voor grotere en diepere problemen, evenals problemen die grotere oplossingen vereisen. Ontwerpers en ontwikkelaars kunnen aanvullende strategieën toepassen, zoals:

• Oorzaakanalyse: Voer grondige oorzaakanalyse uit om de onderliggende problemen te identificeren en oppervlakkige of symptomatische oplossingen te vermijden. Moedig een holistisch beeld van het probleem aan en erken onderlinge factoren.
• Contextueel begrip: Streven naar een alomvattend begrip van het probleem door rekening te houden met de bredere context en potentiële onderlinge afhankelijkheden. Werk samen met belanghebbenden om diverse perspectieven en inzichten te verzamelen.
• Open communicatiekanalen: Stel open communicatiekanalen in met belanghebbenden en moedig transparante discussies aan over het probleemgebied. Creëer een omgeving waarin belanghebbenden zich op hun gemak voelen om hun zorgen te uiten en waardevolle input te geven.
• Proactieve vraagstelling: Ga actief op zoek naar de kern van het probleem door doordringende vragen te stellen. Bevorder empathie om de perspectieven, behoeften en gewenste resultaten van belanghebbenden te begrijpen.
• Gebruikersgerichte benadering: Neem een gebruikersgerichte benadering aan en geef prioriteit aan een diep begrip van de uitdagingen en voorkeuren van eindgebruikers. Moedig gebruikers aan om hun behoeften te verwoorden, zodat voorgestelde oplossingen in lijn zijn met hun verwachtingen.
• Prototyping en validatie: Ontwikkel prototypes of proof of concepts om aannames te valideren en ervoor te zorgen dat ze in lijn zijn met het kernprobleem. Zoek feedback van belanghebbenden en eindgebruikers om voorgestelde oplossingen te valideren en verfijnen.
• Iteratief ontwerpproces: Omarm een iteratief ontwerpproces, waardoor continue feedbacklussen mogelijk zijn om oplossingen te verfijnen op basis van evoluerende inzichten. Itereer op oplossingen in reactie op nieuwe informatie, zodat deze in lijn blijven met het werkelijke probleem.

Het naleven van het idee "Denk niet in oplossingen maar in problemen" is cruciaal voor ontwerpers en ontwikkelaars die omgaan met gebruikersverzoeken. De inherente uitdaging ligt in het feit dat gebruikers oplossingen (X) voorstellen terwijl ze eigenlijk een onderliggend probleem (Y) willen oplossen. Het herkennen van deze verkeerde afstemming is essentieel, omdat het blindelings implementeren van een voorgestelde oplossing kan leiden tot ontevredenheid en verspilling van middelen. De last ligt bij ontwerpers en ontwikkelaars om de daadwerkelijke problemen achter de voorgestelde oplossingen van gebruikers te ontrafelen. Het gebruik van doordringende vragen en andere strategieën maakt deel uit van een toolkit hiervoor.

Door een holistische probleemoplossingsbenadering te omarmen, waarbij begrip belangrijker is dan onmiddellijke oplossingen, en effectieve samenwerking met ontwerpers, ontwikkelaars en andere belanghebbenden, zorg je ervoor dat je oplossingen resoneren met de werkelijke behoeften van gebruikers. De kern is om niet alleen het gepresenteerde probleem aan te pakken, maar het werkelijke probleem te vinden, wat resulteert in een betekenisvolle en efficiënte ontwerp- en ontwikkelingsreis. Deze aanpak helpt ons voorbij de verleiding te gaan om oplossingen klakkeloos te accepteren en in plaats daarvan oplossingen te creëren die authentiek inspelen op de pijnpunten en verwachtingen van gebruikers.

En dat is waarom ik mijn baas vertel om te denken in problemen en niet in oplossingen.

Geschreven door Ron Dekker op 4 februari 2024.

Meer lezen

• How to Ask Questions The Smart Way geschreven door Eric Steven Raymond. Het artikel behandelt onder andere het XY-probleem en de oplossingen ervoor. Het is meer gericht op softwareontwikkelaars die vragen stellen, maar het is zeker de moeite waard om te lezen.