Schuld van Designer.
Ik voel het de hele tijd, ik weet zeker dat jij dat ook doet. Ik voel deze schuld als ik nalaat iets te doen dat de ontwerpersgemeenschap erop heeft aangedrongen dat alle ontwerpers moeten doen .
Wanneer ik rechtstreeks in high-fidelity-prototypen spring, voel ik me schuldig. Als ik te veel vertrouw op mijn eigen veronderstellingen in plaats van gebruikersinzichten, voel ik me schuldig. En als ik er niet in slaag om een patroonbibliotheek te starten aan het begin van een nieuw project, voel ik me schuldig.
Voor de eerste twee punten moet je je zeker schuldig voelen. Dit zijn praktische tips om redenen die ik hier niet zal bespreken. (Geloof me niet, kijk maar hier , en hier .)
Maar moet je je schuldig voelen omdat je geen patroonbibliotheek hebt gestart?
Ik heb me gerealiseerd dat het antwoord Nee is. Dat zou je niet moeten doen.
Ik suggereer niet dat je op een gegeven moment geen patroonbibliotheek nodig hebt. Je doet. Misschien niet op dit moment. In feite zou het creëren van een verplichte patroonbibliotheek te vroeg in uw project uw proces kunnen vertragen.
Hoe? Wel, aan het begin van een project is het nuttig om een beetje rommelig te zijn. Loslaten is de sleutel tot a Lean UX proces terwijl u aannames test om te bepalen wat uw gebruikers nodig hebben. Dit is niet het beste moment om je te concentreren op je patroondocumentatie.
Na een tijdje zal de spanning van het niet hebben van een patroonbibliotheek echter in gaan. U zult weten dat het tijd is om te gaan investeren in uw patroonbibliotheek wanneer deze vier tekens verschijnen:
Ontwikkelaars zullen u vaak vertellen dat zij zich houden aan het principe van DROOG - Herinner jezelf niet. Dit houdt hun code schoon en vrij van overtolligheden.
Patronenbibliotheken kunnen productteams helpen dit principe ook te volgen.
Tegen de tijd dat we een paar maanden bezig waren met het bouwen van onze app, voelden mijn team een gevoel van deja-vu wanneer we onze ontwerpen bespraken. Welk patroon gebruiken we om een modaal opnieuw te openen? Hoe ziet het tekstveld eruit op deze pagina?
Een gedeeld patroon kan deze cyclische discussies helpen voorkomen. Nu, als de vraag welk patroon moet worden gebruikt, hebben we een betrouwbaar referentiepunt.
"Laten we de modal gebruiken die vervaagt naarmate hij omhoog schiet en een zoekwoordveld voor typografie heeft."
Ja, ik zei dit tijdens een vergadering. Geen grapje. Dit was een van die momenten waarop de grimmige realisatie van onze behoefte aan een patroonbibliotheek zich manifesteerde.
Patroonbibliotheken kunnen helpen om een gemeenschappelijke taal te creëren voor uw team en afdelingen. Als je 'braadpan' zegt, kun je ervan uitgaan dat ik de juiste afbeelding in mijn hoofd heb. Op dezelfde manier zou je kunnen zeggen "Modal List Picker" en je team zal precies weten waar je het over hebt.
Het is een ongelukkige realiteit, maar je app heeft in het begin enkele kleine kloven. Een outcast-lettertype hier, enkele afvallige marges daar. Dat is geen probleem. Je bent nog steeds dingen aan het uitzoeken.
Na verloop van tijd echter beginnen deze kleine kloven te leiden tot meer ernstige scheuren in de gebruikerservaring. Uw app kan ongepolijst en asymmetrisch aanvoelen.
Malcolm Gladwell eens geschreven hoe mensen binnen enkele seconden frauduleuze kunst kunnen detecteren. U wilt niet dat uw gebruikers uw app op dezelfde onbewuste manier afschrijven.
Het proces van het maken van een patroonbibliotheek kan uw team helpen bij het identificeren en oplossen van deze inconsistenties voordat ze uit de hand lopen.
Tijdens de eerste fasen van een nieuw product is het gebruikelijk dat een klein team volledig eigenaar wordt. Hierdoor blijft iedereen gefocust, zodat ze zo snel mogelijk kunnen reageren op de behoeften en inzichten van klanten.
Naarmate het product groeit, groeit ook het aantal teams en bijdragers. Zonder patroondocumentatie kunnen nieuwe teams de patroondebatten die u dacht dat voorbij was, opnieuw aanwakkeren.
Een patroonbibliotheek kan helpen bij het communiceren van het wat, hoe en waarom achter uw patronen naar nieuwe teams en belanghebbenden.
Het is het beste om te onthouden dat patroonbibliotheken hulpmiddelen zijn, geen dogma. Maar als je een product ontwerpt, voel je de schuld. Je zult je zorgen maken dat je praktische adviezen hebt genegeerd en je team hebt laten vallen.
Dat is geen probleem. Het is belangrijker om enkele grote sprongen van vertrouwen te maken, te zien hoe uw ideeën falen en blijven leren en itereren.
Je zult ooit een patroonbibliotheek bouwen, maak je geen zorgen. De tijd zal komen dat je spanning niet kunt negeren. Het beste van alles is dat het geen verplichting zal zijn.
Het zal een openbaring voelen.
[- Dit artikel is oorspronkelijk gepost op Medium . Opnieuw gepubliceerd met toestemming van de auteur. -]