Eine Codebasis und eine Community

Ich wachte eines Morgens auf und erkannte, dass ich alles falsch gemacht hatte. Ich entdeckte, dass Code und Design nicht jedes Problem in einem Design-System-Team lösen können, auch wenn viele Probleme dadurch gelöst werden können, dass man den ganzen Tag in einem dunklen Raum codiert und designt. Moment, was? Wie zum Teufel ergibt das Sinn? Nun, das liegt daran, dass gute Design-System-Arbeit auch Einstellung beinhaltet.

Ich werde es erklären.

Zuerst werfen wir einen Blick auf einige gängige Probleme mit Design-Systemen. Eines könnte sein, dass Ihre Komponenten eine dicke Div-Suppe sind, die Probleme für Benutzer verursacht und insgesamt schlecht für die Barrierefreiheit ist. Ein weiteres Problem könnte sein, dass Sie eine große Anzahl von benutzerdefinierten Komponenten haben, die fragil und extrem schwierig zu verwenden sind. Oder vielleicht haben Sie acht verschiedene Illustrationsstile und vier verschiedene Modal-Komponenten. Vielleicht haben Sie tausend verschiedene Farbwerte, die inkonsistent verwendet werden.

Jeder in einer Organisation kann diese Probleme in der Regel spüren, aber sie sind wirklich schwer zu beschreiben. Leute können sehen, dass es viel länger dauert, Dinge zu bauen, als es sein sollte, und Missverständnisse sind weit verbreitet. Unsere Web-App hat möglicherweise schlechte Web-Performance, erhebliche Probleme mit der Barrierefreiheit und ein wild inkonsistentes Design. Aber warum ist das so? Was ist die Ursache all dieser verdammten Probleme?

Das Seltsame an Design-Systemen ist, dass es schwierig ist zu erkennen, was die Ursache all dieser Inkonsistenzen und Probleme sein könnte. Und selbst die Antwort ist nicht immer ganz offensichtlich, sobald man das Problem sieht.

Ein Design-System-Team kann Komponenten-Dokumentation schreiben, um diese Probleme zu beheben, oder vielleicht Dinge refaktorieren, Muster überprüfen, noch mehr Dinge refaktorieren, Komponenten neu gestalten und Schulungen und Anleitungen anbieten. Aber wenn Apps eine bestimmte Größe erreichen, reicht es nicht aus, wenn eine Person (oder sogar ein ganzes Team von Leuten), die sich mit diesen Problemen befassen, diese lösen kann.

Sicher, ein Design-System-Team kann viel Zeit damit verbringen, bei der Behebung eines Problems zu helfen, aber ist das wirklich die beste Nutzung ihrer Zeit? Was wäre, wenn sie ein anderes Team im Unternehmen davon überzeugen würden, stattdessen einen engagierten Front-End-Entwickler einzustellen, um ein nachhaltiges Arbeitsumfeld zu schaffen? Was wäre, wenn sie einen Illustrator einstellen würden, um die Dinge konsistent zu gestalten und eine hohe Qualität in der gesamten App zu gewährleisten?

Deshalb gehört auch das Thema Einstellung zur Arbeit an Design-Systemen.

Ein Design-System-Team ist in der perfekten Position, um Anleitungen zur Einstellung zu geben, da sie als erste Probleme in einer Organisation erkennen werden. Sie werden sehen, wie Komponenten zusammengeflickt werden oder wo es zu viele unnötige benutzerdefinierte Komponenten gibt, die nicht Teil einer Bibliothek oder eines Styleguides sind. Das Design-System-Team wird Schwächen im Code erkennen, die sonst niemand sieht, und kann zeigen, welchen Teams welche spezifischen Fähigkeiten fehlen – und dieses Problem beheben, indem es Leute mit Fähigkeiten in diesen spezifischen Bereichen einstellt.

Wenn Sie im Management sind und diese Inkonsistenzen nicht jeden Tag sehen, wird wahrscheinlich nichts dagegen unternommen. Wir werden die Probleme, die wir nicht sehen können, wahrscheinlich nicht beheben.

Als Leute, die mit Design-Systemen arbeiten, müssen wir uns letztendlich wegen Folgendem um die Einstellung kümmern: Eine Codebasis ist eine Nachbarschaft und eine Community.

Und der einzige Weg, wie wir die Codebasis reparieren können, ist, die Community zu reparieren.