How I iterated a design solution through user evaluations within an academic environment.
How a startup team of three reacted to customers' feedback in a fast paced environment.
How I designed a wishlist feature for an e-learning campus in an agile environment.
After being introduced to the UX world during my master's degree at RWTH, I knew I needed to pursue this path. That lead me to write a master's thesis with UX design focus.
Together with my partner in crime, Tina, another RWTH student, we built kiwi, a UI design pattern library. It was inspired by Christopher Alexander, the father of the pattern language. Why a UI design pattern library? One word: academia.
My main goal was to collect, design, and connect UI design patterns scattered around on the vast internet. For the scope of my thesis alone, I focused only on mobile patterns.
Tina extended the library with UI components and guidelines.
Whoever has ever written a master's thesis knows the drill. As many other glorious soldiers, I wore several hats over that one year, from academic researcher to UX designer, UX researcher, UI designer, web developer, life-choices-questioner, and so it goes. 🥲
We targeted product designers, developers, and design students with the aspiration to assist them in their workflows.
To guide our design decisions, we first sought to identify the pain points of our target groups in their workflow. We discovered that:
For the purpose of this portfolio, I will focus only on one particular case study during the design of kiwi. As we navigate complex systems, it is observed that patterns work best not in isolation, but when they are used together with other fellow patterns. That's how they create an experience based on validated best practices.
Hence, when creating kiwi, one of the biggest challenges was to visualise these relations between the 108 UI patterns which I had collected and designed. Based on the academic research, I defined 6 different relations that patterns could have with one another.
So far so good. Now, let’s move on to the design iterations of visualising pattern relations.
We iterated the design through user evaluations with usability testing, qualitative interviews, SUS, and UEQ. Let's have a look at the iterations below.
The first attempt at visualising the relations looked like this, a flat schema with labeled arrows that connect pattern names with one another. The arrows are labeled to the scientific relations defined before.
We evaluated this first design with 10 potential users from our target group. The main lesson that we learned was that the users couldn't understand pattern relations through the scientific labels only, they were missing a sense of hierarchy.
Alright, let's have a look at another try... Still a flat schema, but organised in a hierarchy and the arrow labels are simplified to a more common language. E.g. from "this pattern is a sub-ordinate of this other pattern" to "this pattern contains this other pattern".
The next 5 potential users who evaluated this design weren’t happy with the amount of information they had to parse. Even though the language was simpler, it was still a lot of complex layout.
We had to change strategy, so we circled back to the idea that patterns work best together ... that’s what we had to show!
By now it was clear to us that the best way to show how patterns are connected with each other is to visualise how this works in practice through an interactive prototype. We called this an application type.
Another way how patterns are related are when they belong in the same category, e.g. shopping patterns, navigation patterns. We also made this clear through the information architecture on the website.
Another touch point of showing relatedness was in the pattern pages themselves.
The new idea went through 5 small iterations evaluated with 5-6 potential users each. Above are shown the final designs after another evaluation with 7 more participants. Check out the iterations in this figma prototype.
In the design world, there is always the debate whether users read or not. Considering that context is king, given the use cases of our target groups, i.e. rapid prototyping, learning UX design, or implementing good design, depicting pattern relations through text and name dropping (as we initially started) wasn’t the solution.
You can find kiwi at designwithkiwi.com. I don’t suppose anyone uses the website for practical purposes, and upon reflection, adding the pattern designs & relations in the Figma community could have been the solution all along.
Our work on kiwi was published in the MobileHCI’19 conference in Taipei and the paper is referenced on the ongoing study of UI design patterns.
The three main takeaways for me from this challenge were:
