Wir haben kürzlich ein paar Features bei CodePen veröffentlicht, an denen ich beteiligt war. Das hat mich ein wenig über den Prozess nachdenken lassen. Er ist immer einzigartig, und das aus vielen Gründen. Lassen Sie uns das erkunden.
Was war der Funke?
Features beginnen mit Ideen.
War es ein großer heller Funke, der plötzlich aufkam? War es ein winziger Funke, der vor langer Zeit entstand, aber langsam heller wurde?
Ideen zu dokumentieren kann sehr helfen. Darüber haben wir kürzlich in CodePen Radio gesprochen. Wenn Sie Ideen tatsächlich aufschreiben (sowohl eigene als auch auf Anfrage von Benutzern), kann dies diese klären und kontextualisieren.
Es gibt Tools (z. B. Uservoice), die speziell für Benutzerfeedback zur Steuerung der Feature-Entwicklung gedacht sind.
Persönlich bevorzuge ich eine Mischung aus interner Produktvision mit gemessenen Kundenanfragen und halte die öffentliche Roadmap schlank.
Die Ergänzung von Design-Assets bei CodePen, eines der jüngsten Features, an denen ich gearbeitet habe, war eher ein sich langsam intensivierender Funke als einer, der heiß und schnell aufkam. Er entstand aus jahrelangen angesammelten Benutzeranfragen. CodePen sollte einen Farbwähler haben. Das wäre nett, dachten wir uns. Es sollte einfacher sein, benutzerdefinierte Schriftarten zu verwenden. Ja... wir springen auch regelmäßig herum und kopieren Code von Google Fonts.
Dann erhalten wir eine E-Mail von Unsplash, die im Wesentlichen lautete: Hey, wissen Sie, wir haben eine API. Hmmmm. Das tut ihr in der Tat! Der Funke war dann Mensch, all diese Dinge scheinen wirklich miteinander verbunden zu sein. Es sind alles Dinge, die Ihnen beim Design helfen. Design-Assets, sozusagen.
Vielleicht können wir sagen, dass dies ein gutes Rezept ist, um ein neues Feature zu starten: Es scheint eine gute Idee zu sein. Ihr Instinkt sagt Ihnen, dass Sie es tun sollen. Sie wollen es selbst. Sie haben genug Recherche, dass Ihre Benutzer es auch wollen.
Während Sie dabei sind...
Der Funke ist entzündet. Es fühlt sich nach einer guten Idee an und sollte jetzt umgesetzt werden. Was nun?
Wenn Sie an einem neuen Feature für ein bestehendes Projekt arbeiten, kommen Sie nicht umhin, darüber nachzudenken, wo es in die UI und UX der Anwendung passt. Vielleicht ist es nur der Designer in mir, aber designgeführte Feature-Entwicklung scheint wirklich der richtige Weg zu sein. Entscheiden Sie zuerst genau, was es tun soll, wie es sich anfühlt und aussieht, und bauen Sie dann darauf auf.
Ich bin immer der Miesmacher, wenn es um nicht-UI/UX-Features und -Verbesserungen geht. Ich versuche, aus Lass uns auf Postgres umstellen ein Lass uns einen Weg finden, wenn wir wirklich auf Postgres umstellen müssen, den Benutzern etwas zu geben, während wir es tun. Aber ich schweife ab.
Ich wette, die meisten neuen Features sind keine Lass uns einen völlig neuen Bereich auf die Website hinzufügen. Die meiste Arbeit an Websites besteht darin, kleinere Teile dessen, was bereits vorhanden ist, hinzuzufügen/zu entfernen/zu verfeinern.
Im Falle des neuen Design-Assets-Features, an dem wir gearbeitet haben, war klar, dass wir es in unseren Code-Editor integrieren wollten, da dort Bedarf dafür bestand. Unsere Tendenz ist generell machen wir ein neues Modal! Ich bin in einer solchen Situation nicht gegen Modalfenster. Klicken Sie auf eine Schaltfläche, wechseln Sie für einen Moment den mentalen Kontext, um eine Design-Asset zu finden, kopieren Sie, was Sie brauchen, und schließen Sie es dann und verwenden Sie es. Außerdem nutzen wir bereits Modalfenster im Editor, sodass es eine aufgebaute Affordanz für diese Art von Interaktion gibt.
Aber ein neues Modal? Vielleicht. Manche Dinge rechtfertigen eine komplett neue Benutzeroberfläche. **In dem Moment, in dem wir eine neue Benutzeroberfläche in Betracht ziehen, betrachte ich das immer als einen Moment der Vorsicht.** Nicht, weil eine neue Benutzeroberfläche schwierig ist, sondern im Gegenteil, weil sie zu einfach ist. Ich verfeinere lieber das, was wir bereits haben, wenn möglich. Dort hat uns dieses Feature hingeführt.
Wir haben bereits eine Assets-Funktion, die es Benutzern ermöglicht, Dateien hochzuladen, die oft Design-Assets sind! Warum nicht diese beiden Welten kombinieren? Und das ist der **Moment, während Sie dabei sind...** Moment. Unser bestehendes Assets-Modal brauchte sowieso etwas Liebe. Es gibt einen ähnlichen Rückstand an Ideen, um es zu verbessern.
So wurde dies zu einer Gelegenheit, nicht nur ein neues Feature zu erstellen, sondern auch ein bestehendes Feature aufzuräumen. Wir haben auch die Feature-Suite für bestehende Asset-Uploads erweitert und bieten eine einfachere UX, wie z. B. Klick-zum-Kopieren-Schaltflächen und Aktionsschaltflächen, die es Ihnen ermöglichen, die URLs als externe Ressourcen hinzuzufügen oder sie in unserem Asset-Editor zu öffnen, um Änderungen vorzunehmen.
Aufräumen gilt für UI-Designarbeiten, Front-End-Code und Back-End-Code gleichermaßen. Sicherlich das CSS, wie die Leser dieser Seite wissen! Features sind eine großartige Ausrede für den Frühjahrsputz.
Wer kann daran arbeiten?
Das ist eine riesige Frage, die es bei der Entwicklung neuer Features zu beantworten gilt. Selbst kleine Teams (wie meines) sind auf Feature-Basis in kleinere Teams unterteilt.
Um zur Antwort für ein neues Feature zu gelangen, kann es von großem Vorteil sein, **diese Sache auf ein Blatt Papier zu bringen**. Ein One-Pager ist ein Dokument, das Sie zu Beginn der Entwicklung eines neuen Dings erstellen, in dem Sie den Umfang dessen festlegen, was erforderlich ist.
Es zwingt Sie, **nicht engstirnig** darüber nachzudenken, was Sie tun wollen, sondern **weitläufig**. Auf diese Weise vermeiden Sie Situationen, in denen Sie sagen: **Ich füge hier nur eine kleine Checkbox hinzu ... 7 Monate später, 2.427 Dateien berührt ... fertig!**
Ein One-Pager könnte etwa so aussehen
- Übersicht. Erklären Sie, was Sie bauen und warum.
- Alternative Lösungen. Haben Sie über mehrere Lösungsansätze nachgedacht?
- Frontend-Übersicht. Inklusive Design, Barrierefreiheit und Leistung.
- Backend-Übersicht.
- Datenüberlegungen. Berührt dies die Datenbank?
- API- und Serviceüberlegungen.
- Überlegungen zum Kundensupport. Wird dies wahrscheinlich mehr oder weniger Support verursachen?
- Überlegungen zu Überwachung, Protokollierung und Analyse.
- Sicherheitsüberlegungen.
- Testüberlegungen.
- Überlegungen zur Sicherheit der Community.
- Kostenüberlegungen.
Wenn Sie diese ganze Liste ernsthaft durchgegangen sind und alles aufgeschrieben haben, sind Sie in einer viel besseren Verfassung. Sie wissen genau, was dieses neue Feature erfordert und sind näher an der Schätzung eines Zeitplans.
Entscheidend ist, dass Sie wissen, wer daran arbeiten muss.
Dieser Abschnitt von Fabricio Teixeira trifft den Nagel auf den Kopf
Designer müssen verstehen, wie digitale Produkte über die oberflächliche Schicht hinaus funktionieren und wie selbst die kleinste Designentscheidung eine Kettenreaktion an vielen anderen Stellen auslösen kann.
Sie müssen andere Disziplinen einbeziehen, wenn Sie über eine „kleine Designänderung“ in Ihrem Produkt sprechen. Es ist gut möglich, dass es „kleine Designänderungen“ eigentlich nicht gibt.
Was unser Mini-Feature für Design-Assets betrifft, war einer der Hauptgründe, warum wir es umsetzen konnten, dass wir, vorausgesetzt, wir haben den Umfang dessen, was es tun sollte, richtig eingeschätzt (siehe nächster Abschnitt), 90 % + der Arbeit von einem einzigen Frontend-Entwickler/Designer erledigen konnten. Von allen hatte ich den flexibelsten Zeitplan, sodass ich es übernehmen konnte.
Manche Features, vielleicht die meisten Features, erfordern interdisziplinäre Teams. Große Features brauchen auf unserem kleinen Team normalerweise fast alle.
Version Eins vs. Die Zukunft
Es ist sehr wahrscheinlich, dass Sie Ihre Ideen auf etwas Überschaubares reduzieren müssen. Es ist sehr verlockend, großzügig mit Ideen zu sein, aber je größer Sie sind, desto langsamer gehen Sie voran. Ich bin sicher, wir alle waren schon in Situationen, in denen selbst kleine Features dreimal so lange dauern, wie wir erwartet haben.
Ich versuche, derjenige zu sein, der Dinge schnell auf den Markt bringt, zumindest dort, wo ich weiß, dass Verfeinerungen und Politur keine Luftschlösser sind. Ich habe tendenziell mehr Probleme mit Scope Creep und Verzögerungen als mit Dingen, die zu schnell herauskommen.
Was unser Feature für Design-Assets betrifft, so wollte ich es, wie erwähnt, zunächst auf ein fast reines Frontend-Projekt beschränken, damit nicht viele von uns daran arbeiten müssen. Dies wurde durch die Tatsache ausgeglichen, dass ich sicher war, dass wir es ziemlich nützlich machen könnten, ohne viel Backend-Arbeit zu benötigen. Ich würde ein Feature nicht nur aus Gründen der Verfügbarkeit von Personal einschränken, aber manchmal passen die Sterne so.
Der Farbwähler-Teil des Design-Assets-Modals ist ein gutes Beispiel dafür. Sofort haben wir darüber nachgedacht, dass jemand vielleicht seine eigenen Lieblingsfarben als Palette speichern möchte. Vielleicht pro Pen oder global für sein Konto. Ich halte das auch für eine nette Idee, aber das erfordert Datenbankarbeit, um uns darauf vorzubereiten. Es scheint eine recht kleine Sache zu sein, aber wir würden uns mit so etwas Zeit nehmen, um sicherzustellen, dass die Datenbankänderungen abstrakt genug sind, dass wir nicht nur eine Spalte „Lieblingsfarben“ hinzufügen, sondern ein System, das entsprechend skaliert.
Ein einfacher Farbwähler kann also „v1“ sein! Kein Problem! Bringen Sie das Ding auf den Markt. Sehen Sie, wie Leute es benutzen. Sehen Sie, was sie verlangen. Dann verfeinern und ergänzen Sie es bei Bedarf.
Um ganz ehrlich zu sein, gab es nicht viele Rückmeldungen dazu. Das ist normalerweise etwas für die **Gewinn**spalte. Dass die Leute es lautstark lieben, ist sicherlich besser, aber das ist selten. Wenn Produkte funktionieren und das tun, was die Leute wollen, gehen sie normalerweise einfach still und zufrieden ihren Geschäften nach. Aber wenn Sie ihnen im Weg stehen, zumindest in gewissem Umfang, werden sie es Ihnen sagen.
Vielleicht werden wir eines Tages den Bereich Design-Assets überarbeiten und eine v2 machen! Gespeicherte Favoriten. Mehr Bildsuchanbieter. Mehr Suche im Allgemeinen. Bessere Erinnerung daran, was Sie zuvor verwendet haben, und Ihnen diese Dinge schneller anzeigen. Solche Verfeinerungen könnten ein anderes Team erfordern. Es ist auch ein ebenso befriedigendes Projekt wie die v1, wenn nicht sogar mehr.
Hier ist ein besserer Blick darauf, was aus v1 geworden ist
Ein weiteres Beispiel… CodePens neue externe Assets
Wo wir gerade von der Verfeinerung eines Features sprechen! Lassen Sie uns dies auf ein weiteres Feature anwenden, an dem wir kürzlich bei CodePen gearbeitet haben. Wir haben gerade neu gestaltet, wie unser Bereich für externe Assets funktioniert. So sieht er jetzt aus
Es ist eher unwahrscheinlich, dass die meisten Leute eine starke Erinnerung daran haben, wie es vorher war. Das ist nicht so anders. Der große UI-Unterschied ist diese große Suchleiste. Zuvor waren die Eingabefelder die Suchfelder, im Typahead-Stil. Wir verwenden immer noch Typahead, haben es aber in die Suchleiste verschoben, was ich für eine stärkere Affordanz halte.
Die Verschiebung des Ortes, an dem Typahead stattfindet, ist tatsächlich eine kleine Änderung, aber wir hatten viele Beweise dafür, dass die Leute keine Ahnung hatten, dass wir es überhaupt angeboten haben. Die Verwendung der visuellen Suchaffordanz behebt dies vollständig.
Eine weitere bedeutende UX-Verbesserung kommt in Form dieser gespeicherten Ressourcen. Immer wenn Sie eine Ressource auswählen, merkt es sich, dass Sie es getan haben, und gibt Ihnen eine kleine Schaltfläche, um sie erneut hinzuzufügen. Hey! Das ist doch sehr ähnlich wie das Bevorzugen von Design-Assets, oder?! Gut, dass wir diese „Lieblingsfarben“-Datenbankspalte nicht erstellt haben, denn wir sehen bereits, wo ein abstrakteres System nützlich wäre.
In diesem Fall haben wir beschlossen, diese Favoriten in localStorage zu speichern. Jetzt können wir eine UI experimentell nutzen, die Favoriten verarbeitet, aber die Datenbank noch nicht anfassen muss. Der Vorteil der Übertragung in die Datenbank ist, dass Favoriten jeglicher Art einen Benutzer über Browser und Sitzungen hinweg folgen könnten, ohne Angst haben zu müssen, sie zu verlieren. Es gibt immer eine v3!
Es gab auch einige interne Backend-Updates, über die wir uns intern genauso freuen. Dieses Typahead-Feature? Es durchsucht Zehn- oder Hunderttausende von Ressourcen. Das sind viele Daten. Zuvor haben wir dies gehandhabt, indem wir diese Daten erst heruntergeladen haben, wenn Sie in ein Typahead-Feld geklickt haben. Aber dann haben wir sie heruntergeladen. Ein riesiger JSON-Chunk, den wir auf unseren eigenen Servern gespeichert haben. Ein riesiger JSON-Chunk, der regelmäßig veraltet ist und ständig aktualisiert werden musste. Wir hatten ein System für die Aktualisierung, aber es erforderte dennoch Arbeit. Das neue System nutzt die CDNjs API direkt, was bedeutet, dass nie ein riesiger Download stattfinden muss und die Ressourcen immer aktuell sind. Nun, so aktuell wie CDNjs eben ist.
Apropos v3, wir haben bereits viele Ideen dafür. Die Geschwindigkeit ist ein geringfügiges Anliegen. Wie können wir die Suche beschleunigen? Wie können wir die Ergebnisse nach Popularität eingrenzen? Wie können wir lockerer werden und besser erraten, wonach Sie suchen? Wahrscheinlich am wichtigsten: Wie können wir dies für Ressourcen auf npm öffnen? Wir hoffen, all diese Dinge anzugehen. Aber glücklicherweise hat nichts davon uns davon abgehalten, jetzt eine bessere Sache auf den Markt zu bringen.
Zusammenfassend
Ein bisschen ein Schwafeln, oder?
Definitiv einige unvollständige Gedanken hier, aber die Feature-Entwicklung hat mich in letzter Zeit viel beschäftigt und ich wollte etwas festhalten. Viele von uns Entwicklern leben diesen Kreislauf unsere gesamte Karriere. Viele von uns haben erheblichen Einfluss darauf, was wir bauen und wie wir es bauen. Es gibt unglaublich viel, über das man im Zusammenhang mit all dem nachdenken kann, und wohl keine offensichtliche Reihe von Best Practices. Es ist zu groß, zu nebulös. Man kann es nicht in die Hand nehmen und sagen: So machen wir Feature-Entwicklung. Aber man kann gründlich darüber nachdenken, einige Prinzipien haben, die für einen funktionieren, und versuchen, das Beste zu tun.