Gastbeitrag: Fragen und Antworten zur Gestaltung des Sucherlebnisses, mit Tyler Tate von Twigkit

Nachdem so viele von Ihnen an dem kürzlich von uns gesponserten Webcast zum Thema„Findability: Designing the Search Experience“ mit Tyler…

Nachdem so viele von Ihnen an dem kürzlich von uns gesponserten Webcast zum Thema„Findability: Designing the Search Experience“ mit Tyler Tate von Twigkit teilgenommen haben, gab es eine lange Liste von Fragen, die im Laufe der Präsentation nicht angesprochen wurden. Da die Liste recht umfangreich war, dachten wir, dass es für Sie nützlich sein könnte, weitere Einblicke zu erhalten. Deshalb haben wir Tyler gebeten, einige Antworten auf Ihre Fragen zusammenzustellen.

Q: Gibt es quantitative Methoden, um die Effektivität Ihres Sucherlebnisses zu beurteilen, z. B. durch die Analyse von Protokollen über das Verhalten der Benutzer – oder geht es wirklich nur darum, mit den Leuten zu sprechen und zu beobachten, was sie interaktiv tun?

TT: Suchprotokolle sind wirklich nützlich, um die Relevanz zu beurteilen und zu verbessern, aber sie geben nur Einblick in einzelne Suchanfragen. In der Realität kann es jedoch vorkommen, dass Benutzer mehrere Suchanfragen stellen oder ihre Ergebnisse mehrmals filtern, bevor sie das finden, wonach sie suchen. Nützlich wäre es, wenn Sie Daten zur Umformulierung von Suchanfragen verfolgen könnten, die Aufschluss über den Weg geben, den ein Nutzer während einer bestimmten Sitzung genommen hat. Dies könnte Ihnen Aufschluss darüber geben, wie die Benutzer die Benutzeroberfläche über einen längeren Zeitraum hinweg tatsächlich nutzen. Allerdings sind Usability-Tests mit echten Nutzern sowohl einfacher durchzuführen als auch schneller die größten Schwachstellen in Ihrem System aufzudecken, daher würde ich immer dort beginnen.

Q: Gibt es eine optimale Anzahl von Suchergebnissen oder eine optimale Anzahl von Facetten, die von den meisten Benutzern leicht erfasst werden können?

TT: Ich habe noch keine allgemeingültigen Zahlen gehört. Ich denke, es kommt darauf an, dass Sie Ihr Publikum kennen. Experten werden sich mehr Komplexität wünschen als Amateure. Und spezifischere Aufgaben werden mehr Optionen zulassen als breitere Aufgaben. Aber als Anhaltspunkt bieten eBay und Amazon oft 20-35 Filter, die sich auf etwa 10 verschiedene Facetten verteilen.

F: Gibt es konventionelle Weisheiten über den Anteil Ihres Designs oder Budgets, den Sie dem User Experience Design für Ihr Suchsystem widmen müssen, z.B. im Verhältnis zu Ihrem gesamten Entwicklungsbudget? Wie bei der Qualitätssicherung gibt es die gängige Meinung, dass 1 QA auf 2 Entwickler kommt… Woher wissen Sie, ob Sie den richtigen Anteil für das Design Ihres Suchsystems investieren?

TT: Such-UI-Frameworks (wie TwigKit, an dem ich arbeite) können die Kosten für die Erstellung der Benutzeroberfläche senken. Traditionell müssen jedoch etwa 30% Ihrer Zeit und Ihres Budgets für die Benutzeroberfläche aufgewendet werden, um ein erstklassiges Ergebnis zu erzielen.

Q: Wie können Sie bei einer großen Anzahl von Treffern pro Filter oder Facette verhindern, dass ein Benutzer das auswählt, was „beliebt“ ist, und nicht das, was relevant ist – auch bekannt als das Kaninchenlochproblem?

TT: Diese Frage zielt auf das Problem der „Nadel im Heuhaufen“ ab. Wie können Sie diese eine Anomalie in einem Meer von Ergebnissen finden? Die beste Lösung, die ich gefunden habe, ist, für jeden Filter eine „Ausschluss“-Option anzubieten. Auf diese Weise können Benutzer die beliebten Ergebnisse ausschließen und sich auf die seltenen Ergebnisse beschränken. Das macht die Benutzeroberfläche zwar etwas komplexer, aber in manchen Fällen lohnt sich das.

Q: Können Sie etwas zu den Kompromissen zwischen Leistung und Auffindbarkeit sagen, d.h. ab welchem Punkt ist es sinnvoll, das Suchsystem härter arbeiten zu lassen, um die Relevanz oder die Präsentation zu verbessern, wenn dadurch das Bedürfnis des Benutzers nach Geschwindigkeit enttäuscht wird?

A: Die Geschwindigkeit ist entscheidend. Wenn die Benutzeroberfläche zu langsam ist, werden die Benutzer wahrscheinlich frustriert sein oder sogar aufhören, sie zu benutzen. Idealerweise wird eine Seite in weniger als 2 Sekunden geladen. Das scheint die Schwelle für ununterbrochene Aufmerksamkeit zu sein (siehe Nah unter http://sigs.aisnet.org/sighci/bit04/BIT_Nah.pdf, Nielsen unter http://www.useit.com/papers/responsetime.html). Berücksichtigt man die Ladezeiten, bedeutet dies, dass Ihr Server auf jeden Fall eine Antwort unter einer Sekunde liefern sollte.

Q: Können Sie Kommentare zu einem Testplan für Ihre Schnittstelle abgeben, z. B. für Nullergebnisse … und so weiter.

TT: Das hängt natürlich davon ab, was Sie in Ihre Schnittstelle einbauen wollen, aber wir testen normalerweise die folgenden Szenarien: * Keine Abfrage – bevor der Benutzer seine Suche begonnen hat * Keine Ergebnisse * Keine Ergebnisse, aber wenn ein Rechtschreibvorschlag verfügbar ist * Rückruf – liefert die Engine relevante Ergebnisse? * Ergebnisse für die Suchanfrage des Benutzers * Ergebnisse für die Suchanfrage des Benutzers, wenn ein oder mehrere Filter angewendet wurden * Ergebnisse, wenn Filter angewendet wurden, aber die Suchanfrage entfernt wurde * Ergebnisse, wenn Rechtschreibvorschläge verfügbar sind * Ergebnisse, die leere Felder enthalten * Ergebnisse, die sehr lange Felder enthalten

Q: Welche Sicherheitsvorkehrungen empfehlen Sie für den Gesamtverlauf, die Suche und die Anzahl der Facetten?

TT: Ein Benutzer sollte natürlich keinen Vorschlag oder Filter sehen dürfen, wenn er nicht berechtigt ist, das resultierende Dokument zu sehen, denn das Wissen, dass der Begriff überhaupt existiert, ist bereits ein Sicherheitsverstoß. Ich bin kein Sicherheitsexperte, aber wir haben dieses Problem bei TwigKit oft gelöst, indem wir die Zugriffsdaten in einem Feld auf jedem Dokument gespeichert haben. Wir fügen dann einen versteckten Filter an die Abfrage an, der die Sicherheitsfreigabe des Benutzers angibt und so die Dokumente herausfiltert, die er nicht sehen darf.

Q: Können Sie einen Ansatz für die Präsentation oder Gruppierung vieler Ergebnisse aus einer föderierten Suchkollektion empfehlen?

TT: Eine föderierte Suche ist wirklich schwierig zu realisieren und ich kenne keine Patentrezepte. Ich habe gesehen, dass sie in einer einzigen zusammengefassten Ergebnisliste dargestellt wird (Kayak), in Registerkarten aufgeteilt ist oder als eine Reihe von Gruppen auf der Seite angezeigt wird (iTunes).

Q: Wie würden Sie den Unterschied zwischen der Suche in einem Online-Shop und der Suche in einem öffentlichen Bibliothekskatalog oder einem Museum beschreiben?

TT: Ich denke, dass die Aufgaben selbst (d.h. ein Buch zu finden) fast identisch sind. Historisch gesehen waren die Zettelkataloge der Bibliotheken komplexer als die Suchoberflächen der Verbraucher. Das liegt wahrscheinlich daran, dass in der Anfangszeit Bibliothekare die Hauptnutzer solcher Systeme waren und darin geschult wurden, fortgeschrittene Suchanfragen einzugeben. In letzter Zeit scheinen Bibliothekskataloge die Einfachheit zu übernehmen, die Benutzer von Web-Suchmaschinen erwarten, sehr zum Vorteil des typischen Benutzers.