I work as a full-stack Product Designer at RealEyes. I am responsible for all product related design and research tasks, working closely with the developer teams and providing the product team with user insights.
Realeyes measures how people feel as they watch video content online, enabling brands, agencies, and media companies to optimize their content and target their videos at the right audiences.
People share access to their webcams while they watch ads. Using computer vision and machine learning, Realeyes track their facial expressions and report in real time about how the audience truly feels about the content.
End users can analyze the emotion and attention data collected about the viewers on a dashboard, making it the key interface between the client and the service Realeyes provides.
One of the main user personas is an agency-based marketing professional working to optimize an ad for their client. The other main persona is a big brand’s employee using the services to understand how their campaign performs. Both users want to identify the emotional triggers in the ad that drive the analytics.
I focused on the second persona, since they typically have less training in marketing and can use extra help in interpreting the results on the dashboard. The challenge was to present the results in an actionable way.
For example, users were always interested to see the viewers’ expressions of happiness throughout the video. But they didn’t know what to do if there was a sudden fall in happiness, or if the ad induced a consistently low level of happiness. In the former case, they asked if the scene should be cut. In the latter case they wondered if they should start over with new creative work.
It seems that these are quite subjective questions and without not much expertise in marketing the end user might be not able to make informed decisions. We conducted user interviews with current and potential clients in this role and found that most were confused and intimidated by the complexity of the interface. They couldn’t understand everything on the UI and couldn’t make sense out of the data.
After making this observation, I started to design and iterate on a new dashboard that provides the user with more actionable answers to their questions. We introduced a simple checklist to diagnose what the user’s ad is doing well, and how it could be improved. We also added Natural Language Processing data, so users can see what kind of positive and negative thoughts viewers had after watching the media when they answered open ended questions.
The new dashboard enables the user to effectively compare different aspects of the video across different versions and against their competitors.They use it to improve their campaign for the target audience and increase sales.
Another important aspect of the Realeyes platform is how it interacts with our viewer participants. These are the people around the world that are paid to watch media provided by Realeyes’ clients and answer questions. This is how Realeyes collects emotion and attention data for clients. The main problem we face is that participants often begin the process, earning money for their time, but then drop out of the session when prompted to share their webcam. Clearly people are uncomfortable being watched, even when we emphasize that only the algorithm will ever watch the video.
Another important aspect of the Realeyes platform is how it interacts with our viewer participants. These are the people around the world that are paid to watch media provided by Realeyes’ clients and answer questions. This is how Realeyes collects emotion and attention data for clients.
The main problem we face is that participants often begin the process, earning money for their time, but then drop out of the session when prompted to share their webcam. Clearly people are uncomfortable being watched, even when we emphasize that only the algorithm will ever watch the video.
I conducted lot of usability tests with users from different countries. We knew that cultural norms, for example the different emphasis on privacy for German and American participants, play an important part. The interviews confirmed this impression, suggesting a difficult but effective way to minimize dropout: tailoring the UI and copy by location. On the top of that we also made the choice to differentiate mobile and desktop users.
I also created a popup survey to ask mid-session leavers why they decided to stop participating. We got hundreds of answers, so I could really focus on the main problems and iterate on different designs with usability tests. A/B tests showed a significant improvement in conversion rates, validating this research-oriented approach to design.
I also improved an internal tool that operations uses when turning client specifications into data collection work. For instance, clients may be interested in how a specific demographic reacts to their ad: Chinese women with dogs, aged 30-45. Often the client is interested in multiple overlapping and intersecting groups. In addition to those Chinese women they may also want to test their ad on East-Asian parents, for example. Operations had difficulty launching data collection with these complex restrictions on participation, and they were solving the problem in an ad-hoc way by asking developers for bespoke solutions for every case.
I was asked to set up a system for this workflow, and saw it through from interviews with various teams to prototyping to testing. We created an MVP in a short time frame and improved its value by iterating on its flexible basic structure. We significantly improved the time it takes to launch new data collection and made operations between teams run much more smoothly.
I worked as a UX researcher and designer on this project for Auchan Hungary. They wanted to introduce non-food products to their long-working webshop. This sounds deceptively simple, but the previous site was not designed with the storage, delivery, and availability constraints of non-food products in mind. The challenges become apparent at checkout.
Say you want to buy a fridge, some bread, and a lightbulb in a single order. You would like the fridge to be delivered to your home. It can arrive five working days later at any time from 8:00 - 16:00. Bread delivery needs to be scheduled in a two hour time slot this week. It might be possible that your chosen bread is not available since it is an FMCG (fast-moving consumer goods) product so you should also pick acceptable substitutes. The light bulb is small and standardized, but since it is in a different storage facility and a different delivery company is responsible for it, there is no promise it can be scheduled to arrive with your bread. Auchan wanted to know how to communicate all that without losing their customers.
To begin with I restructured the information architecture of the available products and their categories. I had the constraint that I couldn’t change the UI framework, so I had to fit a mix of food and non-food products into relatively few categories.
User interviews and in-person card sorting tests helped a lot here. I watched users group the categories and name them. We learned a lot how users think, how it might be better to rename some categories, and how their overall background effects the way how they think about certain labels. Housewives with children are a great example: many times they created broad groups like “Kids” or “Children” including things like “Books” or “Games”, which are clearly not exclusively children's products. These insights helped me put together a strong architecture for the new site.
Turning to the checkout process, my main idea was to allow multiple carts per user by delivery type. In the real world, you would be pushing three carts in front of you and placing items into them based on their delivery status. Of course online the system does this for you automatically. Users can check their carts, including delivery notes, on every page using a cart preview popover. I experimented with different color codes and icons for carts in the prototype. In the desktop version a calendar for expected delivery is always close at hand.
Another twist in the story was that payment had to be different across carts. For food products you could use your Auchan loyalty card, while for other types of goods you cannot pay in cash. At the payment page I had to emphasize the differentiation and make it as smooth as possible since the user sometimes had to pay more than once.
User research helped a lot to iterate on the initial ideas and after several rounds I could finalize the wireframe. It was a good experience to see that even such a complicated process with lots of limitations can be made clear to users. I tested with very different people from all social classes and backgrounds and did my best to make it work for everyone.
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.