Foosio is a fantasy football app where you can create your dream team and compete with others based on real players’ perfomance and outcomes.
The main challenge was to give the user the most freedom possible within the team creation process. So unlike other fantasy games we let the user play around with their team's formation, avoiding predefined ones that are difficult to change in later steps. Users have their own strategy for team creation and we don't force them to follow predefined steps. After all, we built a game and not a tax form :-). During tests users selected three or four favourite players, and then they started to think about the formation. They filled up the empty positions at the end. This flexible process set us apart from our competitors.
Another challenge was to create a fun, detailed and engrossing game that would not turn into math homework. We wanted to let the user focus on the main interaction and rather than on calculating statistics while preparing for the game, because the most exciting part of ‘Foosio’ is when users create their team, searching for the right combination of 11 football players. There is a limited budget and each potential teammember has a different value. Users focus on finding underdogs: those footballers who cost less but bring more points. At this point we show them not only their remaining budget but also the average budget left per player. They don’t need to waste their time crunching numbers. It is a simple calculation for the programmer, but it lets the users focus on player selection.
Another critical interaction within the game is when users change their minds and want to swap one of their players for a better one. At this point, show them both the new possibilities and keep the replaced player as a sticky element. They don’t need to remember the name, average points and value of their current selection.
Redesigning a complex loan calculating website was a very exciting challenge. I am going to discuss one interesting snippet of the redesign as a case study about how quantitative user research can guide UI design and dramatically increase user retention.
Bankmonitor is an online calculator helping users compare loan offers of different banks. Banks hate that it makes choosing the best offer so easy, and that it makes it impossible to win customers with sub-standard offers.
The loan calculator worked in the following way:
1) Users arrived from organic search to page1 where they could fill out a simple calculator form to get some initial results: top loan offers.
2) They arrived at the results page (page2). At the top of the results page there is a more advanced calculator in case the user wants to fine tune their search.
Discovering the hidden loop, where users are leaving. In Google Analytics’ User Flows we noticed that users were going back and forth between Page1 and Page2, and there was considerable user drop-off.
We did a couple of user tests to follow-up on the issue. It turned out that the calculator on Page2 looked so different from the calculator on Page1 that users simply thought it was something else, not a more advanced calculator. They didn’t take a second look. As a result, whenever they wanted to refine their search, they went back to Page1 and resubmitted it.
In the new design we merged Page1 and Page2. A simple calculator was readily available at the top and advanced features hidden under a link. Rather than two different calculators, the site now had a single calculator with extendable features.
Another challenge was to understand how individuals actually choose a loan when they need money for a new home.
The assumption was that the process of choosing the best mortgage offer was to:
1) look for the ideal house
2) realize that you don't have enough money to buy it
3) visit Bankmonitor.hu to find out which bank would loan you the missing amount for the best conditions.
Therefore Bankmonitor.hu asked for the amount of money the user needed and the duration of the loan - then calculated the best offers.
How people really choose mortgage?
To get started, we did a couple of user interviews with people who have recently took out a loan. As it turned out the actual process of buying a house looks more like this:
You don't have a dream house in mind, but you want one as big and nice as you can afford.
How big and nice can you afford? That depends on how much banks are willing to lend you, which is dependent on a number of things, but most importantly on the size of the installments you can pay.
So you go to Bankmonitor.hu to calculate mortgages based on how large installments you can repay safely.
Once you know how large of a mortgage you can get, you go out and find the best house in that price range.
You find the real estate and agree on the purchase price.
Go to Bankmonitor.hu to compare mortgage offers for exactly the loan amount you need.
We came up with a simple calculator design that serves both use cases well.
To wrap up: assumptions are great to start with, and often assumptions are correct. But they are correct in a way that they are only part of the story. UX research can reveal the rest of the story, and provide a big advantage over your competitors.
This project is a social networking site that aims to connect neighbors. Once you register and give your address, the system connects you with people in your surroundings so you can communicate with them, ask for their help, share things, organize common activities and so on.
TThe site existed for more than a year when I joined the project and their main problem was that people actually couldn't find what they were looking for. They separated 7 sections and grouped all posts below each other in the UI in big boxes. The last ones were below the fold and noone could find them. It was an obvious problem when we looked at the analytics, as they showed that less people reacted on posts in the lower sections.
When we started to run user tests on the old website it turned out:
- people could not really fit their posts or thoughts into these 7 categories.
- it was unclear how the users should respond to posts, or how they could know if a post is still valid or not
- most users were sceptical that they can trust a stranger who is only their neighbor
- most profiles were very empty, without pictures or personal information, making it seem there was no real community behind the site
First we tested tagging model, in which the users themselves can add custom tags to their posts. This way the category system of the site is user generated, making it more organic.
We also introduced a status sign for the posts so that the owner can inform the userbase if the post is no longer valid or relevant.
We encouraged users to upload more personal data about themselves so they can trust each other and added functionality for giving feedback and saying thanks. We also introduced a side feed that tells success stories about neighbors who helped each other.
Pontolo is a loyalty point collector app that seeks to bundle loyalty cards, so that you can keep all your points from your favorite places in one place and can check in on offers and sales.
The client defined the target group: middle aged women at home, probably with kids. We started user testing the concept and faced some surprises.
The main idea was to give each user a barcode for their phone. After purchasing something, the user would present the barcode to the waiter, who would scan it with their own phone's app. The user's account would be updated with the loyalty points, nice and easy.
It turned out that the target group was not aware of this technical possibility. We gave our test subjects the task to show their barcode to a waiter without much further elaboration, and they were under the impression that they were supposed to tell a number, or to show a floating code icon in the app that was actually the button to open the code screen.
It was clear that we had to find a way to introduce them to this technical capability so they know how to use the application. We created an onboarding concept in which we visually show a person holding her phone in her hand while accessing the barcode. We also enhanced the code screen to show a how to hold your phone during scanning graphic.
Also on the code screen we shows a graphic how to hold your phone when someone tries to scan it.
The big takeaway from this project is that even though you may think you know your users, and just because you create a nice look and feel concept that the users like, they won't necessarily be able to use your application. You have to carefully test the prototype to see the bottlenecks and change the concept according to the user's needs.
Analyzing and understanding yourself is exciting. That's why when we found an old psychology test based on picking colors we decided to turn this visual experience into a new application. We explored some concepts and found that emoticons can work even better than colors.
We ended up designing a concept for an application that aims to track your feelings, give you an overview of your past and enable you to understand yourself better.
We started to explore the Lüscher psychology test, based on picking colors from a group. You pick the one that makes you feel the best when you look at them first, then you repeat the process with the remaining colors until none of them are left. As a result you get information about your existing situation, your stress sources, your restrained characteristics, your desired objective and your actual problem.
This is a pretty fun and interesting test because you don’t have to think too much: just intuitvely choose colors. You don’t have to deal with words, or definitions. And the result is surprisingly satisfying, giving feedback and helping you to think deeper about your feelings and problems.
Based on the Lüscher test we started to explore opportunities to combine feelings with colors. We wanted to help users understand their feelings in a structured way, so that it can become an everyday habit that aids understanding and triggers positive change.
First of all we created a paper prototype to see the decision making process of the users. What helps them? Colors? Words? Faces? Does it help if the user is presented as an avatar?
It turned out during the user tests that there are two ways of selecting a single emotional state:
1) picking: you select one right away,
2) excluding: gradually eliminate the emotions that are not in play until only one remains
We also observed some interesting things like that some users like to organize the faces spatially before selection. The initial disorganization of faces was a bit confusing. We thought about presenting the faces in an organized manner. We also found that the spatial metaphor, that some emotions are closer to you than others, works. Users get it.
It was very interesting to see how they used the space around their virtual avatar. Some users pulled those emotions closer to the head that had some connection to their current emotional state. It also turned out that they have a tendency to pick more emotions, and even prioritize among them. Usually one is not enough to describe how they feel.
We created a digital prototype as well to see what happens if we group the emotions and the user has to go through a two steps choosing process.
In this framework it turned out that users prefer one step choices. When they saw the second screen with the list none of them were very happy about it. The users also seemed bored when choosing from a list.
RRegarding the copywriting: the question “How do you feel today?” was quite confusing. The users often felt they should merge all their feelings from that day so far, which is not a simple task. The other question in the paper prototype test "How do you feel now?" worked better.
You can read more about the project and methods on formforthought
Xively is a connected product management platform that provides companies the ability to build, launch and run their connected devices.
I worked as a UX and UI designer on the software's user interface. My job included creating clickable prototypes and concept for several use cases. It was my responsibility to lead the UX research activities, inlcuding interviews and user tests. Based on those we could identify the main personas for Xively and iterate on the prototypes.
Besides that I took part in the creation of the Xively Design Guidelines which includes visual design and user experience guidance of Xively. It is a very complex system that has to take all the aspects of a flexible IoT framework under consideration so that UI serves the user's needs in any case.
This was an especially exciting challenge for me because creating such a complex and holistic design system requires a deep understanding of both the product and the users. It has to walk through all the edge cases and topics that can appear on the UI and give an adequate answer so the users never feel lost when using the product.
At SAP I worked as a member of the central design team. Our responsibility was to support and trigger design change inside the company. At the heart of this work was a design framework built to redefine old SAP software.
I worked extensively on two topics: Supply Chain Management and Recipe Management.
In Supply Chain Management the main challenge was how to visualize the network of the supply chain in an interactive way so that the user can understand what is happening with the goods, where problems are occuring, who could solve them and how. Furthermore we wanted them to understand how their process could be optimized through their networks.
In Recipe Management my task was to understand universal properties of the complex hierarchical system of recipes at different companies and create a UI that helps the user to understand their system and manage the recipes easily with the minimum amount of work.
At the University I took part in two masters programs: media design and visual art education. These two fields merged into one in my diploma project where I decided that I would like to design an application for teenagers presenting Hungarian poems. These poems are mandatory to learn in high school and, despite their beauty, are quickly forgotten or remain underappreciated.
I was really interested in new ways of reading based on an observation of how people process information. Instead of following a linear path, we often rather scan things and gather information from more places at the same time. I wanted to see if it is possible to represent a linear text in an interactive way.
I started with one poem which takes place on a famous bridge in Budapest. My goal was to organize the information about the text in a very intuitive and fun way so the student won't get overwhelmed and bored with information in block text. I tried to use minimal visual effects to keep the text in the focus. For example I only "put" the poem on the bridge visually.
It was very interesting to test the application with teens. I tested the collaborative parts too by involving highschool teachers who used the app during their classes. Afterwards we interviewed students about what they thought of the app usage during the lecture, and also we tested the rest of the app for individual learning outcomes.
We heard some interesting responses. It turned out that students hate carrying their books, especially as they google the texts on their phones anyway, rather than opening a book. White paper with black letters were often deemed simply too boring.
The collaboration part between teachers and students was extremely well-received, because they could share their thoughts on the lesson and results with teachers and other students from within the app itself.
You can read more about the project in Hungarian here.