# Wat Mac-gebruikers me leerden over betrouwbare software bouwen > Een temperatuurstandaard, een ontoegankelijke donkere interface, een dubbele aankoop en een direct prijsbezwaar veranderden hoe ik over vertrouwen, lokalisatie, toegankelijkheid en support denk. Published: 2026-08-16 | Updated: 2026-10-18 Toen Mole van een shellopdracht een Mac-app werd, verwachtte ik dat het moeilijke deel de interface zou zijn. Het verrassende werk was mijn eigen aannames afleren. Iemand kocht de app per ongeluk twee keer en sloeg mijn aanbod af om de tweede aankoop terug te betalen. Iemand anders corrigeerde de temperatuureenheid die ik voor die regio had gekozen. Weer iemand anders kon de app helemaal niet gebruiken omdat de donkere interface moeilijk te lezen was. Een direct prijsbezwaar liet me heroverwegen wat een betaalde app moet verdienen als er al gratis tools zijn. Geen van deze kwam binnen als een netjes featureverzoek. Elk gesprek legde een ander gat bloot tussen de persoon die ik me voorstelde en de persoon die het product echt gebruikte. Dat gat heeft me meer geleerd dan nog een vergelijkingstabel of analytics-grafiek had gekund. ## Vertrouwen hoort bij de functie De dubbele aankoop bleef bij me omdat het praktische antwoord eenvoudig was: ik kon het geld teruggeven. Wat het moeilijk maakte, was het vertrouwen achter de vergissing. De persoon had al één keer betaald, een fout gemaakt, en wilde nog steeds dat de tweede aankoop het werk steunde. Dat is genereus, maar het schept ook een verplichting om het product makkelijker te begrijpen en veiliger in gebruik te maken. Een hulpprogramma dat bestanden verwijdert, heeft een grotere vertrouwenskloof dan de meeste software. Het vraagt iemand te geloven dat een scan bestanden juist heeft toegeschreven, dat een onzeker onderdeel niet wordt geselecteerd, en dat een vergissing te herstellen is. Een gepolijst scherm kan die belofte niet alleen dragen. Het product moet het plan tonen, uitleggen waarom iets is overgeslagen, gedeelde gegevens beschermen, en de prullenmand gebruiken als herstel ertoe doet. Die details zijn geen supportwerk rond de functie. Ze zijn de functie. Dit veranderde ook hoe ik lof lees. Een compliment is prettig, maar de nuttige vraag is wat de persoon het product toevertrouwde. Is het antwoord "bestanden weghalen zonder me ongerust te maken", dan moet de volgende versie controle en herstel versterken voordat hij nog een categorie aan de scan toevoegt. ## Een locale is geen voorkeurenprofiel Ik nam ooit aan dat een Mac met een Amerikaanse locale hardwaretemperaturen in Fahrenheit moest tonen. Een gebruiker legde uit dat technische temperaturen normaal in Celsius worden gelezen, ook als weer en lichaamstemperatuur Fahrenheit gebruiken. Een chip op 110 graden zien zonder de verwachte eenheid voelde alarmerend in plaats van vertrouwd. Mole zet hardwaretemperaturen nu standaard op Celsius in elke regio en houdt Fahrenheit als een expliciete keuze. De codewijziging was klein. De correctie erachter was groter: een locale vertelt me hoe ik taal, datums en getallen opmaak. Hij vertelt me niet hoe iemand elk technisch domein begrijpt. De veiligere productregel is beginnen bij de conventie van wat er wordt gemeten, die controleren bij mensen die die conventie gebruiken, en een expliciete keuze bewaren als beide vormen nuttig zijn. Automatisch meer voorkeuren uit een land gokken kan persoonlijk aanvoelen en het product tegelijk minder vertrouwd maken. ## Toegankelijkheid begint bij "ik kan dit niet gebruiken" Mole heeft geïnvesteerd in VoiceOver-labels, focusvolgorde, minder beweging en meer contrast. Ik was toegankelijkheid gaan zien als een hoeveelheid werk die het product al serieus nam. Toen legde iemand met slecht zicht uit dat witte tekst op de vaste donkere interface moeilijk te lezen was en dat die alleen apps gebruikte die de lichte weergave van het systeem volgden. Die feedback veranderde de categorie van het probleem. Lichte weergave was niet langer een esthetische voorkeur of een verzoek om nog een instelling. Voor deze persoon was het het verschil tussen de app gebruiken en hem geïnstalleerd laten staan. Mole dwingt vandaag nog een donkere weergave af, dus dit blijft een echt gat en geen afgerond succesverhaal. Toegankelijkheid is geen badge die waar wordt nadat er genoeg labels zijn toegevoegd. Een product kan goed werken met VoiceOver en iemand toch buitensluiten door contrast, kleur, beweging, tikgrootte of een beslissing over de weergave. De nuttige vraag is niet of de app "toegankelijkheid ondersteunt". Het is welke taak iemand nog niet kan voltooien, onder welke systeeminstellingen, en welk deel van de interface dat tegenhoudt. ## Een prijsbezwaar kan productonderzoek zijn Eén gebruiker zei me helder dat de prijs hoog aanvoelde voor werk dat een gratis app kon doen. De makkelijke reacties zouden de prijs verdedigen, hem verlagen, of functies toevoegen tot een vergelijkingstabel langer oogde. Geen ervan zou het belangrijke deel van het bericht beantwoorden. Gratis tools kunnen echt veel onderhoudsklussen op de Mac oplossen. De open-source Mole CLI blijft gratis, en macOS bevat al Activiteitenweergave, opslaginstellingen, de Finder en de prullenmand. Een betaalde app moet zijn plek verdienen door herhaald werk veiliger te maken, verspreide informatie bij elkaar te brengen, en iemand die Terminal nooit opent te helpen begrijpen wat er gaat gebeuren voordat het gebeurt. Lost een gratis tool de klus van iemand al op, dan is die aanraden eerlijker dan een reden verzinnen om nog een app te verkopen. Het bezwaar werd daardoor een positioneringstest, geen aansporing om het product uit te breiden. Het vraagt wie genoeg baat heeft bij de native app om ervoor te betalen, wat die anders zelf zou moeten samenstellen, en of het verschil zichtbaar is tijdens een proefperiode. Zijn die antwoorden zwak, dan kan marketing ze niet repareren. ## Maak van het verhaal een veranderde aanname Feedback wordt ruis als elk bericht de backlog in gaat zoals het geschreven is. De een vraagt om een schakelaar, de ander om een lagere prijs, en een derde beschrijft een vergissing die misschien nooit meer gebeurt. Alle drie als stemmen voor functies behandelen verliest de context die ze nuttig maakte.
Een feedbackpad dat begint bij de geblokkeerde taak van de gebruiker, de productaanname aanwijst die faalde, test of het probleem bij het product hoort, en eindigt in een gewijzigde standaard, een gerichte reparatie of een bewuste afwijzing in plaats van elk verzoek direct in een backlog te zetten
Een nuttig gesprek verandert het model dat het product van de gebruiker heeft voordat het de roadmap verandert. De uitkomst kan een nieuwe standaard zijn, een gerichte reparatie, of een helderdere reden om af te wijzen.
Ik probeer nu vier feiten uit een gesprek mee te nemen. Wat probeerde de persoon te doen? Welke aanname in het product faalde? Raakt de fout een groep mensen of alleen deze ene setup? Kan een betere standaard het oplossen, heeft het een gerichte reparatie nodig, of moet het product uitleggen waarom het het verzoek niet overneemt? Dit is langzamer dan verzoeken tellen, maar het levert minder instellingen en minder halve oplossingen op. Het Celsius-gesprek veranderde een standaard. Het gesprek over de weergave legde onafgemaakt toegankelijkheidswerk bloot. Het prijsbezwaar verduidelijkte de grens tussen de gratis CLI en de betaalde app. De dubbele aankoop had helemaal geen functie nodig. Die bevestigde de zorg die je verwacht van een product dat met persoonlijke bestanden wordt vertrouwd. ## Houd het gesprek lang genoeg Ik doe support nog zelf, omdat vroege gesprekken meestal te rommelig zijn om bij het eerste antwoord samen te vatten. De eerste vraag kan over een licentie gaan terwijl het echte probleem verwarrende apparaattaal is. Een verzoek om terugbetaling kan een onduidelijke belofte op de productpagina blootleggen. Een verzoek om een instelling kan het bewijs zijn dat de standaard voor iedereen verkeerd is. Automatisering wordt nuttig nadat de vraag zich herhaalt, het antwoord stabiel blijft, en de uitzonderingen begrepen zijn. Vóór dat punt kan het gesprek inkorten precies het detail weghalen dat het product beter had gemaakt. Ik schreef meer over die grens in [Aantekeningen over een stil product bouwen](https://mole.fit/nl/blog/notes-on-building-a-quiet-product). Ik krijg een deel van deze inschattingen nog steeds verkeerd. De temperatuurstandaard is gecorrigeerd. De vaste donkere weergave niet. Sommige feedback wordt code, sommige wordt een productgrens, en sommige blijft een open verplichting. Het waardevolle deel is niet tegen iedereen ja zeggen. Het is elk gesprek verlaten met een nauwkeuriger idee van wie het product gebruikt en wat die nodig heeft om het te vertrouwen. Het langere pad van een privé-script naar deze app staat in [Hoe Mole groeide van shellscript naar Mac-app](https://mole.fit/nl/blog/the-story-of-mole), en de veiligheids-keuzes achter verwijderen dat eerst controleert, staan in [Mole zo ontwerpen dat het uit de weg blijft](https://mole.fit/nl/blog/the-design-of-mole). --- Canonical HTML page: https://mole.fit/nl/blog/what-mac-users-taught-me Blog index for agents: https://mole.fit/nl/blog/llms.txt Site index for agents: https://mole.fit/llms.txt