SRE-Benutzererfahrung

Eine Einführung in Design und UX

Die Idee, wie Benutzer mit der Benutzeroberfläche interagieren, als UX bezeichnet. In der SRE-Welt zeigt sich das oft in der Definition einer Befehlzeilenschnittstelle (CLI), aber manchmal bedeutet UX auch die Gestaltung einer Website-Oberfläche. In anderen Fällen handelt es sich um eine grafische Benutzeroberfläche (GUI), und manchmal ist es ein Hebel oder eine Schaltflächen im echten Leben.

Benutzerprüfung

Unter Benutzertests versteht man die Arbeit mit den Benutzern, um festzustellen, ob bestimmte Erfahrungen optimal (oder zumindest gut) sind und ob sie dem entsprechen, was der Benutzer tatsächlich tun möchte. Diese werden oft als Benutzerinterviews bezeichnet. Die Idee ist, dass man einem Benutzer Fragen stellt, um zu sehen, wie er mit einer Software interagiert oder interagieren würde. Um einen Benutzerfest zu erstellen, müssen Sie sich eine Erfahrung ausdenken, die Sie untersuchen möchten, sich Fragen und Tests ausdenken und Personen finden, die Sie testen möchten.

In den meisten der Beispiele spreche ich von Software, die bereits fertiggestellt ist. Denken Sie daran, dass Sie Benutzertests auch mit Papierdiagrammen oder Frontends mit Schaltflächen, die nichts bewirken, oder sogar mit einem Foliendiagramm durchführen können. Je flüchtiger die Dinge sind, mit denen Ihre Benutzer interagieren, desto mehr müssen sie den Test so einrichten, dass er erklärt, was vor sich geht.

Sie können diese Tests verwenden, um User Stories zu entwerfen.

User Stories sind eine Beschreibung einer Aktion, die ein Benutzer ausführen wird. Sie kombinieren oft drei Informationen: Benutzerrtyp, Benutzerziel und Benutzergrund. Ein Benutzertyp beschreibt eine Gruppe von Benutzern. Ein Benutzerziel ist etwas, das jemand aus dieser Gruppe vielleicht tun möchte. Ein Benutzergrund ist der Grund, warum jemand aus dieser Gruppe dieses Ziel erreichen möchte. Jede dieser Geschichten ist ein Erlebnis, das Sie während der Benitzertests testen möchten.

Erfahrung als Entwickler

In der Welt der Softwareentwicklung treten zwei Ärgernisse auf die sich auf die Erfahrung der Entwickler beziehen. Es handelt sich um die Codequalität und das NIHS-Syndrom (Not Invented Here). Sich auf die Erfahrungen von Entwicklern zu konzentrieren, ist so , als würde man sich auf die Erfahrung von Menschen konzentrieren , die auf Flughäfen arbeiten. Sie sind nicht der Hauptkunde, aber die Verbesserung ihrer Lebensqualität wird die Erfahrung Ihrer Kunden und die Qualität der von Ihnen gelieferten Arbeit verbessern.

Wenn ich von Codequalität spreche, meine ich damit den Stil, in dem die Mitarbeiter gemeinsam Code schreiben. Wenn Sie die Möglichkeit haben, empfehle ich Ihnen, für jede Sprache, in der Sie schreiben, einen Team-Style-Guide zu erstellen. Auf diese Weise können Sie eine Grundlinie festlegen, so dass alle Beteiligten im gleichen Stil entwickeln können. In der Welt des Journalismus gibt es einen Hausstil , d.h einen von der Organisation veröffentlichten Stilleitfaden, der festlegt, wie die Mitarbeiter mit alltäglichen Dingen umgehen, z.B wie sie sich in einem Artikel auf Personen beziehen oder wie sie mit Geschichten über psychische Krankheiten umgehen. Für die Codierung beschreibt ein Code-Style.Guide , wie das Team mit ungewöhnlichen Sprachmerkmalen umgeht. Daring wird oft beschrieben, welche Art von Leerraum verwendet wird, Schleifen und Konditionale gehandhabt werden, und es werden Antworten auf allgemeine Fragen zum Stil gegeben. Dies hat den Vorteil , das sich Mitarbeiter , die zwischen Projekten wechseln, nicht an einen neuen Stil gewöhnen müssen, wenn sie dieselbe Sprache verwenden. Das bedeutet auch, dass Personen, die häufig zwischen Codebasen wechseln, wie z.B. SREs, sich beim Schreiben von Code wohlfühlen, und dass er zum Rest des Codes in einer Datei oder einem Verzeichnis passt.

NIHS bedeutet, dass Menschen nur Software verwenden wollen, die von Mitarbeitern ihres Unternehmens geschrieben wurde, und dass sie kein Vertrauen in alles haben, was von Softwareentwicklern erstellt wurde, die nicht in ihrem Unternehmen arbeiten. Das ist unglaublich gefährlich, denn es kann dazu führen, dass Sie mehr Software schreiben, als ihr Unternehmen sich leisten kann. Der klassische Ratschlag lautet, dass die Software , die Sie entwickeln sollten, Ihre oberste Priorität sind. Wenn Sie z.B. ein Medienunternehmen sind, ist es sehr sinnvoll, ein eigenes Content-Management-System (CM/S) zu entwickeln, damit Sie sehr genau festlegen können, wie Sie Ihrre Inhalte erstellen und bereitstellen, was ja die Hauptaufgabe Ihres Unternehmens ist. Andererseits müssen Sie wahrscheinlich keinen neuen Überwachungsdienst oder Load Balancer erfinden, denn es gibt bereits viele davon. Wenn Sie nichts finden, was genau Ihren Anforderungen entspricht, sollten Sie versuchen, die Funktionalität zu einem bestehenden Projekt hinzuzufügen und es dann stromaufwärts einzubinden, so dass Sie der Welt etwas zurückgeben und Ihr Team nicht zum alleinigen Betreuer von etwas machen, das für Sie wichtig ist, aber nicht ihre oberste Priorität darstellt.

NIHS ist auch gefährlich , weil es ein Gefühl von Elitismus innerhalb ihres Entwicklerteams hervorrufen kann. Dies kann dazu führen , dass das Team denkt, dass niemand sonst so gut entwickeln kann wie es selbst und dass es unbesiegbar ist. Dies ist eine giftige Kultur , die andere davon abhält , Ihrem Team beizutreten, und führt häufig zu Burnout , da die Teammitglieder versuchen werden, auf dem Niveau ihres aufgeblähten Egos zu arbeiten.

Das soll nicht heißen , dass Sie keine Software entwickeln sollten; stellen Sie nur sicher, dass Sie alle Möglichkeiten abwägen, bevor Sie sich für die Entwicklung und Wartung einer weiteren Software entscheiden.

Erfahrung mit Tools

Es gibt viele Dinge, die Sie tun können, um Ihre Werkzeuge zu verbessern. Oft findet man sie, indem man seine Werkzeuge wie Produkte behandelt. Das bedeutet, dass man sie nicht wie Wegwerf-Skripte behandelt und nicht nur nach Bedarf an ihnen herumhackt. Stattdessen muss in sie investiert werden, sie müssen gehegt und gepflegt werden.

Eine Möglichkeit, dies zu erreichen, ist die Verwendung von so genannten „opinionated tools“. Damit sind Werkzeuge gemeint, die nicht jeden einzelnen möglichen Arbeitsablauf unterstützen. Stattdessen konzentrieren sie sich auf die richtige und die falsche Art, Dinge zu tun. Der Nachteil dabei ist, dass die Tools möglicherweise nicht in der Lage sind, neue Arbeitsabläufe zu unterstützen, wenn diese im Unternehmen wachsen. Der Vorteil ist jedoch, dass Sie als Betreuer genau wissen, welche Arbeitsabläufe es gibt und wie sie funktionieren , und dass Sie an deren Verbesserung arbeiten können, um die Erfahrung zu verbessern.

Was am besten ist, müssen Sie selbst herausfinden: Es hängt alles von Ihrem Dienst ab und davon , wie er verwendet wird. Sie können das definieren , aber stellen Sie sicher, dass es für Ihre Benutzer funktioniert und über die gesamte Lebensdauer des Tool hinweg funktioniert.

Leistungsbudgets

Ein weitere Möglichkeit, die UX eines Dienstes zu verbessern besteht darin, ein Leistungsbudget festzulegen. Das Konzept besteht darin, dass Sie bei jeder Codeänderung deren Auswirkungen auf die Systemleistung messen. Wenn sich die Leistung so stark ändert, dass der Dienst die zulässigen Grenzen überschreitet, müssen Sie die Arbeit an den Funktionen einstellen, bis Sie die Anwendung so modifiziert haben, dass die Leistung wieder auf ein normales Niveau zurückkehrt.

Leistungsbudgets wurden mir erstmals von Lara Hogan vorgestellt. Lara Hogan ist eine sehr angesehene technische Managerin, Autoring des Buches Designing for Performance und außerdem eine vielseitige Rednerin.

Die Idee ist, dass Sie eine maximal zulässige Seitenlagegeschwindigkeit unter bestimmten Bedingungen festlegen, wie z.B. WebPagetest unter Verwendung des Standorts. Der Grund , warum die Seitengeschwindigkeit für den Web-UX so wichtig ist, ist vielschichtig. Zunächst einmal verwenden viele Suchmaschinen, darunter auch Googke, die Seitengeschwindigkeit als eine Metrik zur Bewertung der Rangfolge einer Seite. Je langsamer die Seite ist, desto niedriger ist das Ranking. Zweitens hassen die Nutzer langsame Seiten (The Cost of Latency im Jahr 2006 sagte Marissa Mayer, die frühere Google- und Yahoo-Chefin, als sie über Google sprach: „Eine halbe Sekunde Verzögerung führt zu einem Rückgang der Besucherzahlen um 20%.“ (https://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20.html) Benutzer brechen auch häufig Warenkörbe ab, die zu lange zum Laden brauchen, oder Checkout-Bildschirme, die ihre Kreditkarten zu langsam verarbeiten.

Mit dem Wachstum der Softwarebranche ist ein weitere wichtiger Faktor Teil der UX eines Dienstes geworden, der eng mit der SRE-Welt verbunden ist: die Sicherheit

Sicherheit

Sicherheit ist entscheidend, um das Vertrauen der Nutzer zu gewinnen. In unserem modernen Zeitalter sind Datenschutzverletzungen sehr häufig und die Informaitonssicherheit ist sehr wichtig. Die Nutzer beginnen, Produkte auf der Grundlage ihrer Sicherheit und ihres Datenschutzes auszuwählen. Viele Unternehmen haben eigene Sicherheitsingenieure und ganze Unternehmen arbeiten als Berater, um die Sicherheitspraktiken anderer Unternehmen zu untersuchen. Für die Sicherheit ist jeder verantwortlich, genau wie für die Überwachung, die Reaktion auf Zwischenfälle oder die Benutzerfreundlichkeit. Sie sollten Experten in Ihren Reihen haben, die Sie anleiten, aber Sie dürfen nicht unwissend sein und sich in allen Fragen auf ihre Experten verlassen.

Versuchen Sie bei der Entwicklung von Software oder der Überprüfung von Technologien in Bezug auf Sicherheitsfragen, die drei folgenden Aspekte einer Technologie zu berücksichtigen:

ACM-Ethikkodex

Wenn Ihre Software jemandem seelischen Schaden zufügt oder wenn Sie Funktionen zulassen, die den Benutzer in die Lage versetzen , sich selbst oder anderen Schaden zuzufügen, dann könnten Sie unethische Software schreiben. Wenn Sie z.B ein Verwaltungswerkzeug haben, mit dem jemanden einfach und ungeprüft Firmeneigentum löschen kann, oder wenn Sie es versäumen, Ihren Dienst auf zuverlässige Weise zu betreiben, was einer Person Schmerzen verursacht, handeln Sie dann ethisch?

Dies sind philosophische Entscheidungen, über die Sie nachdenken müssen, aber ich hoffe, dass Sie Systeme entwickeln, die einfach zu bedienen, zuverlässig, sicher und ethisch vertretbar sind.

Vorige Themen:

https://einsiedlerkreps.blogspot.com/2023/05/sre-monitoring.html

https://einsiedlerkreps.blogspot.com/2023/05/sre-reaktion-auf-vorfalle-incident.html

https://einsiedlerkreps.blogspot.com/2023/05/sre-postmortems.html

https://einsiedlerkreps.blogspot.com/2023/05/sre-testen-und-freigeben.html

https://einsiedlerkreps.blogspot.com/2023/05/sre-kapazitatsplanung.html

https://einsiedlerkreps.blogspot.com/2023/05/sre-entwicklung.html

Auskopplung vom Post:

https://einsiedlerkreps.blogspot.com/2023/05/sre-die-nachste-stufe-von-devops-teil.html