mirror of
https://github.com/TheTaz25/denis.ergin.git
synced 2025-07-07 19:28:49 +00:00
feat(slides): add ux slides to system
This commit is contained in:
parent
6cf3710dbe
commit
8d35d0a055
13 changed files with 712 additions and 0 deletions
27
src/components/slides/ui-ux/design-thinking-intro.astro
Normal file
27
src/components/slides/ui-ux/design-thinking-intro.astro
Normal file
|
@ -0,0 +1,27 @@
|
||||||
|
<section>
|
||||||
|
<section><h2>Einführung in den Lösungsprozess "Design Thinking"</h2></section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Design Thinking ist ein Prozess, der in letzten Jahren viel "Traktion" erhalten hat. Mit Design Thinking will man Probleme lösen und neue Ideen Entwickeln.</p>
|
||||||
|
<p>Eine Grundidee hierbei ist, dass Personen aus verschiedenen Bereichen in diesem Prozess teilnehmen. Damit sollen möglichst viele Perspektiven zu einer Problemstellung erreicht werden.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Nach Definition benötigt es drei Kernaspekte, um gelungene Lösungen und Innovationen zu entwickeln:</p>
|
||||||
|
<ol>
|
||||||
|
<li>Es soll ein Nutzen für den Menschen entstehen</li>
|
||||||
|
<li>Die Lösung muss technisch umsetzbar sein</li>
|
||||||
|
<li>Aus Wirtschaftlicher Sicht benötigt die Lösung eine "Marktfähigkeit"</li>
|
||||||
|
</ol>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Im Verlauf der Vorlesung werden wir einen "6-Schritte-Ansatz" des Hasso-Plattner Instituts verwenden um einen Design-Thinking-Zyklus zu bestreiten.</p>
|
||||||
|
<p>Mit dieser Methodik trennen wir unser "Projekt" in 2 grobe Bereiche auf: Ein Problemraum und einen Lösungsraum. Jeder dieser Räume enthält drei Schritte mit denen wir ans Ziel kommen sollen.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Wichtig ist zu beachten, dass jeder Schritt zu einem anderen Schritt springen kann, basierend welche Informationen wir haben oder noch benötigen.</p>
|
||||||
|
<p>Design Thinking ist ein iterativer Prozess (analog zur klassischen Software Entwicklung).</p>
|
||||||
|
</section>
|
||||||
|
</section>
|
51
src/components/slides/ui-ux/dt-declare-view.astro
Normal file
51
src/components/slides/ui-ux/dt-declare-view.astro
Normal file
|
@ -0,0 +1,51 @@
|
||||||
|
<section>
|
||||||
|
<section>
|
||||||
|
<h4>Sichtweise definieren</h4>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>In diesem dritten Schritt treffen wir eine erste "Entscheidung": Wir definieren unsere Sichtweise. Dazu haben wir verschiedene "Tools".</p>
|
||||||
|
<p>Mithilfe der Sichtweise werden wir eine "Design Challenge" definieren, die in der 2. Hälfte des Prozesses als Zielsetzung dient.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h5>Personas</h5>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Personas sind eine möglichst akurate Beschreibung einer fiktiven Person, die ein möglicher Nutzer für unsere Applikation ist.</p>
|
||||||
|
<p>Vorgestellte Eigenschaften sollen ein gesamtheitliches Bild des Nutzers für alle im Projekt teilnehmenden Personen darstellen. Dazu gehören klassische Demografische Merkmale wie das Alter. Zusätzlicher gehören aber auch z.B. Zitat zur Persona die deren Wünsche und Anforderungen an das zu entwickelnde Produkt abbilden.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Eine Persona sollte einen relevanten Teil einer Nutzergruppe für unsere zu entwickelnde Applikation abbilden.</p>
|
||||||
|
<p>Entsprechend sollte es auch mehrere Personas geben. Für jede Relevante Nutzergruppe eine Persona.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h5>User-Journey-Map</h5>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Mit unserer Entwickelten Persona können wir nun auf eine "Reise" gehen. Genauer gesagt auf eine Nutzer-Reise (User-Journey).</p>
|
||||||
|
<p>Mit den bisher gesammelten Informationen können wir einen kompletten Anwendungsfall definieren, den eine Person in der Theorie hat.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Dabei wird nicht nur ein Fokus auf die unmittelbare Nutzung unseres Produktes gelegt, sondern wie die Persona dazu gekommen ist, das Produkt zu nutzen, sowie wie es nach der erfolgreichen unmittelbaren Nutzung weiter geht (optional).</p>
|
||||||
|
<p>Zusätzliche Informationen in einer User-Journey-Map sind z.B. die empfundenen Emotionen der Persona während der Journey, sowie mögliche Kommentare die getätigt werden könnten.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Bevor wir uns mit dem Lösungsraum auseinander setzten, können wir nun diese "Position" nutzen, um eine kurze Re-Iteration durchzuführen. Wir wollen nochmal betrachten, welches Problem nun wirklich gelöst werden soll.</p>
|
||||||
|
<p>Gängigerweise wird wird hier eine Fragestellung erarbeitet, um eine Prüfbare Situation zu erschaffen. Eine Solche Frage könnte lauten:</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>
|
||||||
|
<em>
|
||||||
|
Wie kann ich meinen Studenten dabei helfen, sich bestmöglich mit dem Modul Web-Engineering I auseinander zu setzen, auch wenn sie keine Karriere in dieser "Niche" anstreben?
|
||||||
|
</em>
|
||||||
|
</p>
|
||||||
|
</section>
|
||||||
|
</section>
|
121
src/components/slides/ui-ux/dt-ideate.astro
Normal file
121
src/components/slides/ui-ux/dt-ideate.astro
Normal file
|
@ -0,0 +1,121 @@
|
||||||
|
<section>
|
||||||
|
<section>
|
||||||
|
<h4>Ideen finden</h4>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Nun fängt der womöglich <em>intensivste</em> Teil im Design Thinking an. Wir entwickeln Ideen um das vorangegangene Problem zu lösen (Design-Challenge).</p>
|
||||||
|
<p>In diesem Schritt teilen sich die Projektmitglieder in kleinere Gruppen ein, Ziel ist es verschiedene Lösungen für das gleiche Problem zu erarbeiten.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Es werden verschiedene Methoden und Theorien verwendet um auf eine oder mehrere Lösungen zu kommen. Auch in diesem Abschnitt des Design Thinkings wird iterativ gearbeitet um Ideen und Lösungen zu verfeinern.</p>
|
||||||
|
<p>Je nachdem, was für ein Problem wir lösen, haben wir aus unserem UX-Koffer verschiedene Ansätze</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Als Menschen haben wir einen "Bausatz" wie wir die Welt um uns herum wahrnehmen und verarbeiten. Die Psychologie hilft uns dabei diesen Bausatz zu verstehen.</p>
|
||||||
|
<p>Als Designer können wir dieses Wissen verwenden um intuitivere, Menschenzentrierte Produkte und Erfahrungen zu kreieren.</p>
|
||||||
|
<p>Anstatt einen Nutzer ein neues Verhalten aufzuzwingen, können wir Prinzipien der Psychologie dazu verwenden eine Unterbewusste "Führung" zu erstellen, die besser auf unseren Nutzer anspricht.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Nachfolgend möchte ich euch ein paar dieser Theorien vorstellen.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<!-- --- -->
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h5>Jakob's Law</h5>
|
||||||
|
<p><em>Nutzer verbringen einen großteil der Zeit auf anderen Platformen. Der Nutzer tendiert also dazu UI-Paradigmen aus anderen Platformen zu bevorzugen, die er bereits kennt.</em></p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p><strong>Erwartung</strong></p>
|
||||||
|
<p>Die Nutzer werden ihre Erwartungen, die sie an ein vertrautes Produkt geknüpft haben, auf ein anderes übertragen, das ähnlich aussieht.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p><strong>Unstimmigkeiten minimieren</strong></p>
|
||||||
|
<p>Bei Änderungen sollte den Nutzern eine gewisse Zeit lang eine (alt)-bekannte Version zur Verfügung gestellt werden um Unstimmigkeiten bei großen Änderungen zu minimieren.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<!-- --- -->
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h5>Parkinson's Law</h5>
|
||||||
|
<p><em>Jede Aufgabe "bläht" sich solange auf, bis die Verfügbare Zeit aufgebraucht ist.</em></p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p><strong>Zeitlimits</strong></p>
|
||||||
|
<p>Wir sollte die Zeit limitieren die es braucht eine Aufgabe zu beenden, die ein Nutzer erwarten würde.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p><strong>Dauer</strong></p>
|
||||||
|
<p>Wenn wir die tatsächliche Zeit um eine Aufgabe abzuschließen reduzieren, wird dies positiv aufgenommen.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p><strong>Autofill</strong></p>
|
||||||
|
<p>Funktionen wie "Autofill", die die Eingabezeit bei notwendigen Eingaben deutlich Reduzieren. Dies sorgt für eine schnellere Bearbeitung von Aufgaben wie der Kauf von Online-Produkten.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<!-- --- -->
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h5>Stroop Effect</h5>
|
||||||
|
<p>Die Unstimmigkeit, die ensteht, wenn wir versuchen zwei widersprüchliche Attribute miteinander zu verknüpfen.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p><strong>Reaktionszeit</strong></p>
|
||||||
|
<p>Unsere Reaktionszeit verzögert sich, wenn wir mental versuchen Informationen zu verarbeiten, die in wiederspruch zueinander stehen.</p>
|
||||||
|
<p>Beispiele: (Grüner Himmel, Lila Gras, Rote Zitrone, Blauer Apfel)</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p><strong>Kontext berücksichtigen</strong></p>
|
||||||
|
<p>Das Design von Interaktiven Elementen sollte im Kontext Sinn machen. Als Beispiel sollte eine "Jetzt Kaufen" Button auf einer Website nicht das gleiche Design wie ein "Abbrechen" Button aufweisen.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<!-- --- -->
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h5>Hick's Law</h5>
|
||||||
|
<p>Die Zeit, die wir benötigen um eine Entscheidung zu treffen, erhöht sich mit der Anzahl und Komplexität der Auswahlmöglichkeiten.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p><strong>Auswahl Reduzieren</strong></p>
|
||||||
|
<p>Durch die Verringerung einer Auswahl, in Situationen in denen eine schnelle Entscheidung notwendig ist, reduziert die Entscheidungszeit.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p><strong>Kleinere Schritte</strong></p>
|
||||||
|
<p>Durch die Aufteilung von komplizierten Aufgaben in kleinere Schritte, können wie den mentalen Aufwand reduzieren.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p><strong>Empfehlungen</strong></p>
|
||||||
|
<p>Durch die Platzierung von Empfehlungen können wir eine Überforderung bei Nutzern vorbeugen.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<!-- --- -->
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h5>Das Prinzip des geringsten Aufwandes</h5>
|
||||||
|
<p>Menschen tendieren dazu den Pfad auszuwählen, der den geringsten Mentalen und / oder Physischen Aufwand benötigt, um abgeschlossen zu werden.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p><strong>Zeigen, nicht erzählen</strong></p>
|
||||||
|
<p>Wenn es die notwendigkeit gibt, dem Nutzer etwas zu erklären, dann ist es besser konkrete Beispiele mit Erklärungen zu verwenden, anstatt es nur zu erklären.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p><strong>Schrittweise Erweiterung</strong></p>
|
||||||
|
<p>Es ist besser Inhalte Stück für Stück anzuzeigen, anstatt den gesamten Inhalt auf einmal zu präsentieren. Außerdem ist es gut, den Nutzern die Möglichkeit zu geben ob sie weitere Inhalte sehen wollen oder nicht.</p>
|
||||||
|
</section>
|
||||||
|
</section>
|
98
src/components/slides/ui-ux/dt-inspect.astro
Normal file
98
src/components/slides/ui-ux/dt-inspect.astro
Normal file
|
@ -0,0 +1,98 @@
|
||||||
|
<section>
|
||||||
|
<section>
|
||||||
|
<h4>Beobachten</h4>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Um unser Problem besser zu verstehen und um unsere Hypothesen zu bestätigen (oder zu widerlegen) müssen wir uns "harte Fakten" beschaffen.</p>
|
||||||
|
<p>Vorrangiges Ziel ist es auf Nutzer:innen und Betroffene zuzugehen und mit diesen zu sprechen. Dabei wollen wir auch auf empathischer Ebene ein Verständnis für den Nutzer und dessen Problem entwicklen.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Eine Aussage die im Laufe dieses Schritt entstehen soll ist, ob das Problem das zuvor benannt wurde, auch tatsächlich existiert.</p>
|
||||||
|
<p>Je nach Ergebnis ist es möglich kleinere Korrekturen an den Annahmen zu treffen, oder diese komplett zu überarbeiten.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h5>Nutzer-Interviews</h5>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Interviews lassen sich in 3 Kategorien einteilen:</p>
|
||||||
|
<ol>
|
||||||
|
<li>Strukturiert</li>
|
||||||
|
<li>Semi-Strukturiert</li>
|
||||||
|
<li>Nicht-Strukturiert</li>
|
||||||
|
</ol>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Mit Interviews wollen wir Daten generieren. Diese wollen wir interpretieren und daraus lernen.</p>
|
||||||
|
<p>Über Interviews haben wir die Möglichkeit Informationen folgender Art abzufragen:</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<ul>
|
||||||
|
<li>Gegenwärtige Fragen: Fragestellung zur Lösung eines Problems im gegenwärtigen Kontext</li>
|
||||||
|
<li>Vergangene Fragen: Wie sich die der Prozess zur Lösung eines Problems in der Zeit gewandelt hat</li>
|
||||||
|
<li>Zukünftige Fragen: Was sich der Nutzer zur Lösung eines Problems in der Zukunft vorstellen kann.</li>
|
||||||
|
</ul>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Natürlich haben wir zu jedem Zeitpunkt auch die Möglichkeit andere oder vertiefende Fragen zu stellen:</p>
|
||||||
|
<ul>
|
||||||
|
<li>Pro's und Contra's zur aktuellen Lösung</li>
|
||||||
|
<li>"Haben Sie das immer schon so gemacht?"</li>
|
||||||
|
<li>Besondere Merkmale die dem Nutzer in den Sinn kommen</li>
|
||||||
|
<li>Fragen zur Findung des Lösungsweges</li>
|
||||||
|
<li>etc.</li>
|
||||||
|
</ul>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h5>Fragebögen</h5>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Während Interviews eine größtenteils Qualitative Informations-Generierung sind, sind Fragebögen vornehmlich auf quantitative Informationsgewinnung ausgelegt.</p>
|
||||||
|
<p>Wir haben hierbei auch die Problematik, dass wir nicht dynamisch auf Antworten eingehen können, sondern den Nutzer eher "durchleiten".</p>
|
||||||
|
<p>Auch ist es wichtig, dass Fragebögen nicht zu "viel" abfragen. Da ein Nutzer in einem Fragebogen jederzeit die Möglichkeit hat, diesen auch abzubrechen falls "es ihn langweilt" (eine Option).</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Eine Option für Fragebögen ist die Verwendung von "Aussagebewertungen auf einer vorgegebenen Skala"</p>
|
||||||
|
<p>Wir können damit <i>relativ</i> genau Informationen Abfragen ohne dass sich der Nutzer des Fragebogens zu viele Gedanken machen muss.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h5>Feldforschung</h5>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Ziel der Feldforschung ist es, den Nutzer in seinem "natürlichen" Nutzungskontext zu beobachten.</p>
|
||||||
|
<p>Stichpunkt ist hierbei <strong>beobachten</strong>. Wir wollen den Nutzer nicht ablenken sondern nur als passiver Beobachter Informationen sammeln.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h5>Quantitative Nutzungsdaten aus eigener Datenaggregation</h5>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Mit dieser Methode werden Informationen beschrieben, die durch Tracking-Verfahren (nach Zustimmung des Nutzers) auf einer Website gesammelt werden.</p>
|
||||||
|
<p>Hierbei können wir verschiedene Arten von Informationen erhalten:</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<ul>
|
||||||
|
<li>Klick-Strecke eines Nutzers</li>
|
||||||
|
<li>Scroll-Heatmaps</li>
|
||||||
|
<li>Verweildauer auf Seiten</li>
|
||||||
|
<li>U.U. Mausbewegungen</li>
|
||||||
|
</ul>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Mit der Beendigungen dieses zweiten Schrittes sollten wir echte Daten gewonnen haben. Diese Daten helfen uns ein tieferes Verständnis im Problemraum zu schaffen und zu testen ob die aufgestellen Annahmen korrekt waren.</p>
|
||||||
|
</section>
|
||||||
|
</section>
|
20
src/components/slides/ui-ux/dt-prototype.astro
Normal file
20
src/components/slides/ui-ux/dt-prototype.astro
Normal file
|
@ -0,0 +1,20 @@
|
||||||
|
<section>
|
||||||
|
<section>
|
||||||
|
<h4>Prototyp entwickeln</h4>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Mit den Entwickelten Lösungen können wir nun einen Prototypen erstellen. Damit ist aber nicht gemeint, das eine tatsächliche (Software) Lösung entwickelt werden muss.</p>
|
||||||
|
<p>Vielmehr kann man alles was es gibt verwenden um das erarbeitete Konzept visuell darzustellen.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<ul>
|
||||||
|
<li>Lego</li>
|
||||||
|
<li>Papier</li>
|
||||||
|
<li>Weitere Materialien</li>
|
||||||
|
<li>Skizzen</li>
|
||||||
|
<li>Theateraufführung</li>
|
||||||
|
</ul>
|
||||||
|
</section>
|
||||||
|
</section>
|
19
src/components/slides/ui-ux/dt-test.astro
Normal file
19
src/components/slides/ui-ux/dt-test.astro
Normal file
|
@ -0,0 +1,19 @@
|
||||||
|
<section>
|
||||||
|
<section>
|
||||||
|
<h4>Testen</h4>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>In direkten Versuchen dürfen die Gruppen untereinander die Lösungen "vertesten".</p>
|
||||||
|
<p>Dabei werden neue Einblicke als auch Feedback zur erarbeiteten Lösung gesammelt.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Weitere Schritte nach dem "vertesten" im Design-Thinking Prozess:</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>In der Theorie würde eine Erarbeitete Lösung von allen Personen ausgewählt und tatsächlich implementiert werden.</p>
|
||||||
|
<p>Zur Nutzerakzeptanz können Methoden wie "Feature Flags", Beta-Releases und "A/B-Tests" verwendet werden. Ziel ist, neue Features an einem bestimmten Anteil der Nutzerschaft zu testen, Fehler zu finden und Thesen zu prüfen, ehe die Lösung für alle Personen ausgerollt wird.</p>
|
||||||
|
</section>
|
||||||
|
</section>
|
70
src/components/slides/ui-ux/dt-understand.astro
Normal file
70
src/components/slides/ui-ux/dt-understand.astro
Normal file
|
@ -0,0 +1,70 @@
|
||||||
|
<section>
|
||||||
|
<section>
|
||||||
|
<h3>Unser Problem verstehen: Analyse im Problemraum</h3>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h4>Verstehen</h4>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Da im Design Thinking mehrere Bereiche bei der Erarbeitung beteiligt sind, ist es wichtig, dass zu Beginn ein gemeinsames Verständnis für das Problem entsteht.</p>
|
||||||
|
<p>Mit dem erarbeiteten Verständnis für das Problem, sind wird dann auch in der Lage ein Ziel zu definieren, das erreicht werden will (mitunter mit Umwegen).</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h5>Stakeholder Interviews</h5>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>In diesem Kontext verstehen wir Stakeholder als Personen oder Gruppen von Personen, die Teilhabe am Projekt (oder besser gesagt dem Resultat) haben. Dies sind unter anderem:</p>
|
||||||
|
<ul>
|
||||||
|
<li>Der Budget-Geber</li>
|
||||||
|
<li>Vorraussichtlicher Nutzer der Software oder Person(en) mit direktem Kundenkontakt</li>
|
||||||
|
<li>Das Entwicklungsteam</li>
|
||||||
|
<li>Vertrieb & Marketing</li>
|
||||||
|
<li>ggf. weitere Abteilungen / Personen</li>
|
||||||
|
</ul>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>All diese Personen werden auf die ein oder andere Art und Weise mit dem Produkt oder der Lösung arbeiten. Diese haben also auch ein berechtigtes Interesse am Erfolg des Projektes.</p>
|
||||||
|
<p>Nicht jede Personengruppe hat die gleiche "Macht". Es ist wichtig seine Stakeholder zu kategorisieren. Es wird auch unter anderem eine Matrix angelegt, in der festgelegt welche Personen und Bereiche auf welche Art und Weisen informiert werden, wenn es Fortschritte im Projekt gibt.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p><strong>Was ist das Ziel?</strong></p>
|
||||||
|
<p>Das Stakeholder ist ein bi-direktionaler Austausch. Wir als Designer wollen den (wichtigsten) Personen unser Projekt vorstellen und einen Organisatorischen Rahmen bilden.</p>
|
||||||
|
<p>Gleichzeitig wollen wir auch "Insider"-Informationen sammeln. Also Informationen die typischerweise nicht niedergeschrieben sind und nur einem kleinen Personenkreis bekannt sind, aber durchaus wichtig sein können.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h5>Marktanalyse</h5>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>In der Marktanalyse beobachten wir die Lösungen von Alternativen Produkten oder von Produkten von der Konkurrenz.</p>
|
||||||
|
<p>Wir betrachten dabei die für uns wichtigen Interaktionspunkte und schätzen dabei ein ob diese das Produkt besser oder schlechte machen.</p>
|
||||||
|
<p>Aus diesen Informationen können wir lernen, was wir gegenüber anderen Produkten verbessern können aber auch welche Fehler wir direkt vermeiden wollen.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h5>Sekundär-Forschung</h5>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>In der Sekundärforschung verwenden wir bereits existierende Informationen aus anderen Quellen um uns mit der Fragestellung des Problems auseinanderzusetzen.</p>
|
||||||
|
<p>Die Informationen können durchaus verschiedener Natur sein:</p>
|
||||||
|
<ul>
|
||||||
|
<li>Statistische Auswertungen</li>
|
||||||
|
<li>Forschungen</li>
|
||||||
|
<li>Weitere Datenquellen...</li>
|
||||||
|
</ul>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Damit ist unser erster Schritt im Design Thinking Prozess (ggf. fürs erste) abgeschlossen.</p>
|
||||||
|
<p>Mit den gesammelten Informationen sollten wir nun Kernaussagen auf unsere Problemstellung definieren können. Aus den Kernaussagen können wir wiederum Hypothesen aufstellen.</p>
|
||||||
|
<p>Mit diesen Hypothesen gehen wir in den 2. Schritt, in dem diese auf die Probe gestellt werden.</p>
|
||||||
|
</section>
|
||||||
|
</section>
|
27
src/components/slides/ui-ux/index.astro
Normal file
27
src/components/slides/ui-ux/index.astro
Normal file
|
@ -0,0 +1,27 @@
|
||||||
|
---
|
||||||
|
import Title from "./title.astro";
|
||||||
|
import UI from "./ui.astro";
|
||||||
|
import UX from './ux.astro';
|
||||||
|
// import Iso9241210 from "./iso-9241-210.astro";
|
||||||
|
import DesignThinkingIntro from "./design-thinking-intro.astro";
|
||||||
|
import Understand from './dt-understand.astro';
|
||||||
|
import Inspect from './dt-inspect.astro';
|
||||||
|
import DeclareView from './dt-declare-view.astro';
|
||||||
|
import Ideate from './dt-ideate.astro';
|
||||||
|
import Prototype from './dt-prototype.astro';
|
||||||
|
import Test from './dt-test.astro';
|
||||||
|
---
|
||||||
|
|
||||||
|
<div class="slides">
|
||||||
|
<Title />
|
||||||
|
<UI />
|
||||||
|
<UX />
|
||||||
|
<!-- <Iso9241210 /> -->
|
||||||
|
<DesignThinkingIntro />
|
||||||
|
<Understand />
|
||||||
|
<Inspect />
|
||||||
|
<DeclareView />
|
||||||
|
<Ideate />
|
||||||
|
<Prototype />
|
||||||
|
<Test />
|
||||||
|
</div>
|
77
src/components/slides/ui-ux/iso-9241-210.astro
Normal file
77
src/components/slides/ui-ux/iso-9241-210.astro
Normal file
|
@ -0,0 +1,77 @@
|
||||||
|
<section>
|
||||||
|
<section>
|
||||||
|
<h2>Nutzerzentriertes Design nach ISO 9241-210</h2>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Das Ziel der Norm ist es, interaktive System (Produkte sowie Dienstleistsungen) zu entwickeln, die eine gute Nutzbarkeit (Usability) erzielen.</p>
|
||||||
|
<p>Dabei werden aber nicht nur theoretische Informationen gesammelt. Durch verschiedene Methoden werden Informationen direkt von echten Nutzern der Applikation gesammelt.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Um ein gesamtheitliches Konzept zu erarbeiten, ist es dabei notwendig verschiedene Sichtweisen auf Probleme zu haben. Dies hilft dabei, verschiedene Bereiche einer Firma "abzuholen" und mit in die Gestaltung des Produktes einzubeziehen.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<strong>Strategische Sichtweise</strong>
|
||||||
|
<p>Betrifft die Betrachtung aus der Gesamtheitlichen Firmenebene (Was sind die Geschäftsziele, was erwartet der Markt?)</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<strong>Entwicklerische Sichtweise</strong>
|
||||||
|
<p>Betrachtung von Trends in der Hardware- und Software-Entwicklung sowie langfristige Planung des Produktes auf Code-Ebene</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<strong>Vermarktungssichtweise</strong>
|
||||||
|
<p>Einbindung von Marketing und Sales in den Prozess zur verbesserten Vermarktung des Produktes</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<strong>Gestaltungssichtweise</strong>
|
||||||
|
<p>Fokus auf Nutzbarkeit für alle Nutzergruppen (Barrierefreiheit, Produkt-Design, Ergonomie)</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<strong>Experten-Sichtweise</strong>
|
||||||
|
<p>Konkrete Betrachtung von "Power-Nutzern". Dies betrifft sowohl die eigentlichen Nutzer eines Produktes als auch Personen mit Fachwissen in einer Domäne.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h3>Planung</h3>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Ziel der Planung ist es, den Aufwand abzuschätzen um eine gute Usability und UX zu erreichen.</p>
|
||||||
|
<p>Nach der Aufwandsabschätzung, müssen die Inhalte geplant werden:</p>
|
||||||
|
<p>Identifikation von Methoden und Resourcen, Integration in andere Entwicklungstätigkeiten, Festlegung von Verantwortlichkeiten sowie von Informations und Rückmeldewegen, Definition von Meilensteinen und zeitliche Abgrenzung des Gestaltungsprozesses.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h3>Verstehen und Beschreiben des Nutzungskontextes</h3>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>In diesem Schritt versuchen wir eines zu verstehen: den IST-Zustand bei der Benutzung des Produktes (oder von verwandten Produkten).</p>
|
||||||
|
<p>Selbst wenn wir ein neues Produkt auf "den Martk bringen wollen", sind wir wahrscheinlich nicht die ersten die das machen - beziehungsweise es gibt schon Methoden die Versuchen ein Problem zu lösen, es aber noch keine gesamtheitliche Lösung gibt.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Wichtig sind dabei folgende Informationen:</p>
|
||||||
|
<ul>
|
||||||
|
<li>Wer sind die Stakeholder? (Nuzter und andere)</li>
|
||||||
|
<li>Gibt es bei den Nutzern auffällige Merkmale? (Alter, Berufsstand, etc.)</li>
|
||||||
|
<li>Welches Problem versucht der Nutzer zu lösen?</li>
|
||||||
|
<li>Wann und Wo wird das Produkt genutzt?</li>
|
||||||
|
</ul>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h3>Nutzungsanforderungen Festlegen</h3>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Mit den gesammelten Informationen wollen wir nun prüfbar formulieren. Diese prüfbaren Ziele müssen nicht unbedingt Änderungen in der Benutzeroberflächen enden.</p>
|
||||||
|
<p></p>
|
||||||
|
</section>
|
||||||
|
</section>
|
3
src/components/slides/ui-ux/title.astro
Normal file
3
src/components/slides/ui-ux/title.astro
Normal file
|
@ -0,0 +1,3 @@
|
||||||
|
<section>
|
||||||
|
<h1>User Interface & Experience Design</h1>
|
||||||
|
</section>
|
137
src/components/slides/ui-ux/ui.astro
Normal file
137
src/components/slides/ui-ux/ui.astro
Normal file
|
@ -0,0 +1,137 @@
|
||||||
|
<section>
|
||||||
|
<section>
|
||||||
|
<h2>User Interface Design</h2>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Im bisherigen Verlauf dieser Vorlesung haben wir bereits ein paar Webseiten bauen können.</p>
|
||||||
|
<p>Die meisten würden sicherlich keinen Schönheitswettbewerb gewinnen. Wir schieben aber mal den Zeitmangel als Grund davor und belassen es dabei...</p>
|
||||||
|
<p>Diese Slides drehen sich aber genau primär darum: User Interface Design</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Was macht für euch ein Gutes User Interface aus?</p>
|
||||||
|
<p>Wo begenen euch "User Interfaces"?</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>User Interfaces existieren nicht nur auf dem Bildschirm!</p>
|
||||||
|
<p>Alles was im weitesten Sinn bedient werden kann, hat ein User Interface, angefangen bei Alltäglichen Gegenständen wie Stiften bis hin zu hochkomplexen Systemen wie Autos.</p>
|
||||||
|
<p>
|
||||||
|
<a href="https://www.theuncomfortable.com" rel="noopener noreferrer">The Uncomfortable</a>
|
||||||
|
</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Natürlich beziehen wir uns hier auf das Design von Web-Interfaces</p>
|
||||||
|
<p>Aber was zählt den nun in gutes User Interface Design ein?</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<ul>
|
||||||
|
<li>Ein logisches Farbkonzept</li>
|
||||||
|
<li>Negative Space (whitespace)</li>
|
||||||
|
<li>Interaktives Feedback</li>
|
||||||
|
<li>"Wiedererkennbares" Design</li>
|
||||||
|
<li>Durchdachtes Layout und Navigation</li>
|
||||||
|
</ul>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h3>Farben</h3>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Mit Farben können wir Informationen vermitteln, aber auch Gefühle hervorrufen.</p>
|
||||||
|
<p>Zusätzlich können wir mit bestimmten Farben auch Firmen oder ganze Bereiche identifizieren:</p>
|
||||||
|
<ul>
|
||||||
|
<li>Mit Blau kann man oft Technologie-Firmen assozieren</li>
|
||||||
|
<li>Grau-Silber deutet auf eine elegante und/oder teure Marke hin. (Stichwort "Zeitlos")</li>
|
||||||
|
<li>Mit Grün verknüpfen wir die Natur, Wachstum, Gesundheit, etc.</li>
|
||||||
|
</ul>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Farben dienen aber auch dazu, Zustände anzuzeigen</p>
|
||||||
|
<ul>
|
||||||
|
<li>Rot zum darstellen von Fehlern</li>
|
||||||
|
<li>Grün für Erfolge</li>
|
||||||
|
<li>Blau für Informationen</li>
|
||||||
|
</ul>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Auf was sollten wir bei der Anwendung von Farben achten?</p>
|
||||||
|
<ul>
|
||||||
|
<li>Farb-Kontrast (Hintergrund und Vordergrund)</li>
|
||||||
|
<li>Verwendung von Differenzierbaren Farben im "Grayscale"</li>
|
||||||
|
<li>Ggf Anwendung der 60:30:10 Regel</li>
|
||||||
|
</ul>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h3>60:30:10 Regel</h3>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Die 60:30:10 Regel ist ein Leitsatz / Guideline, in welchen "Mengen" Farben angewandt werden sollen.</p>
|
||||||
|
<ul>
|
||||||
|
<li>Die Basisfarbe soll in einem Umfang von 60% auf der Website verwendet werden</li>
|
||||||
|
<li>Eine "Unterstützende" (Sekundäre) Farbe soll in einem Umfang von 30% angewandt werden</li>
|
||||||
|
<li>Akzentfarben (Primärfarben) sollen zu 10% auf einer Website angewandt werden</li>
|
||||||
|
</ul>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Basisfarben sind normalerweiße "großflächig" als Hintergrund verwendet und sollten neutral sein (hell oder dunkel, maximal ein leichter Farbstich)</p>
|
||||||
|
<p>Sekundärfarben sind in besonderen Bereichen anzuwenden (Sidebars, Karten, Menüs) und sind tendenziell eher "ausgewaschene" Farben</p>
|
||||||
|
<p>Primärfarben sind "Farbstark" und sollten der Farbe des Unternehmens (Brandfarbe) entsprechen</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Weiterführende Informationen sind unter den Begriffen "Farblehre" und "Farbentheorie" zu finden.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h3>"Spacing"</h3>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Unter dem Begriff "Spacing" sind auch die Begriffe "Whitespace" oder "Negative Space" zu sortieren. Alle Begriffe beschreiben letzten Endes das gleiche.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Mit Spacing können wir verschiedene Sachen erwirken:</p>
|
||||||
|
<ul>
|
||||||
|
<li>Typografie: Lesbarkeit verbessern</li>
|
||||||
|
<li>Visuelle Abtrennung von Inhalten</li>
|
||||||
|
<li>Verbesserung von Interaktiven Elementen - (44px Regel!)</li>
|
||||||
|
</ul>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Aus Entwicklungs Sicht reicht es, ein ausführliches Set an Spacing-Variablen zu haben und ein Grid-System definiert zu haben</p>
|
||||||
|
<p>Hier hilft CSS-Grid!</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<h3>Typografie</h3>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Die Wahl des Schriftsystems für die Webseite liegt im Normalfall im Aufgabenbereich der Designer, wir als Entwickler sind primär für die Einbindung auf der Webseite verantwortlich (sowie die Einstellung der Schrifteigenschaften)</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Typografie an sich ist ein sehr komplexes Thema, eine schnelle Übersicht aller wichtigen Begrifflichkeiten lässt sich im <a href="https://m2.material.io/design/typography/understanding-typography.html#type-properties" rel="noreferrer noopener">Material Design</a> finden.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Je nach Zielgruppe und Inhalt der Website, sind verschiedene Schrift-Formen möglich.</p>
|
||||||
|
<ul>
|
||||||
|
<li>Serifen-Schrift</li>
|
||||||
|
<li>Monospace Schriften</li>
|
||||||
|
<li>viele weitere...</li>
|
||||||
|
</ul>
|
||||||
|
</section>
|
||||||
|
</section>
|
54
src/components/slides/ui-ux/ux.astro
Normal file
54
src/components/slides/ui-ux/ux.astro
Normal file
|
@ -0,0 +1,54 @@
|
||||||
|
<!-- Self-Explanatory -->
|
||||||
|
<!-- User Guidance -->
|
||||||
|
<!-- Innovation vs Tradition -->
|
||||||
|
<!-- Tools to measure -->
|
||||||
|
<section>
|
||||||
|
<section>
|
||||||
|
<h2>User Experience Design</h2>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<b>Abgrenzung</b>
|
||||||
|
<p>Insgesamt bildet die User Experience ein deutlich breiteres Spektrum ab, als man durch das reine User-Interface abbildet.</p>
|
||||||
|
<p>Nüchtern betrachtet ist das UI-Design eine Unterdisziplin der UX. Im Umkehrschluss wirken sich Entscheidungen im UX-Design fast immer auf die UI aus.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Mit dem UX-Design haben wir deutlich mehr Tools, Konzepte und Möglichkeiten, um "Probleme" zu beheben.</p>
|
||||||
|
<p>Realistisch gesehen haben wir mehrere Hebel in der UX, in die gewirkt werden können. Primär achtet man beim UX-Design auf den Nutzer, der unser Produkt nutzt.</p>
|
||||||
|
<p>Ein weiterer wichtiger Stakeholder ist nun auch das Geschäft / die Firma, die das Produkt entwickelt.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Das heißt nun damit auch, dass wir das User Interface nicht nur für den Kunden verbessern, sondern auch darauf achten müssen, dass das "Produkt" profitabel sein muss. (Stichwort Dark UX Patterns)</p>
|
||||||
|
<p>Hauptziel sollte aber bestmöglich sein, die Erfahrung des Nutzers mit unserem Program (und im nächsten Schritt auch "außerhalb" unseres Programmes) zu verbessern.</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Ähnlich zur uns bekannten Software-Entwicklung ist UX-Design auch ein iterativer Prozess und kann in Agilen Strukturen wie Scrum eingesetzt werden. (Je nach Firma sind dann auch gerne UX-Designer in Teams mit Entwicklern platziert.)</p>
|
||||||
|
<p>Zur Frage "Wie man 'korrekt' Designed", gibt es ein paar Möglichkeiten. Eine Möglichkeit ist hierbei die ISO-Norm 9241-210 (Menschenzentrierte Gestaltung)</p>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Der komplette Prozess nach ISO 9241-210:</p>
|
||||||
|
<ol>
|
||||||
|
<li>Planen des Gestaltungsprozesses</li>
|
||||||
|
<li>Versehen und Beschreiben des Nutzungskontexts</li>
|
||||||
|
<li>Festlegen der Nutzungsanforderungen</li>
|
||||||
|
<li>Erarbeiten von Lösungen</li>
|
||||||
|
<li>Evaluierung der Lösung</li>
|
||||||
|
</ol>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<p>Eine alternative ist der Design-Thinking-Prozess:</p>
|
||||||
|
<ul>
|
||||||
|
<li>Verstehen</li>
|
||||||
|
<li>Beobachten</li>
|
||||||
|
<li>Sichtweise definieren</li>
|
||||||
|
<li>Ideen finden</li>
|
||||||
|
<li>Prototyp Entwickeln</li>
|
||||||
|
<li>Testen</li>
|
||||||
|
</ul>
|
||||||
|
</section>
|
||||||
|
</section>
|
8
src/pages/slides/flexi-pool/05-ui-ux.astro
Normal file
8
src/pages/slides/flexi-pool/05-ui-ux.astro
Normal file
|
@ -0,0 +1,8 @@
|
||||||
|
---
|
||||||
|
import Reveal from "../../../layouts/Reveal.astro";
|
||||||
|
import Slides from "../../../components/slides/ui-ux/index.astro";
|
||||||
|
---
|
||||||
|
|
||||||
|
<Reveal title="User Interface Design and User Experience Design">
|
||||||
|
<Slides />
|
||||||
|
</Reveal>
|
Loading…
Add table
Add a link
Reference in a new issue