How I work
In this post I write about the processes and methods of my work. I want to highlight that this is a lot about the team you work with. So I write about the experience I had with the great team at ImmobilienScout24.
Our design team is in average about five people. Two researchers and two to three designers. We work interdisciplinary with the developers and product managers together. Since I joined the team at the beginning of 2016 we transformed from a slight waterfall model to a matured design and develop process. It means, we are not just adjusting ideas defined by management and co, but rather really taking part of giving a direction and lead of the development. That's realized by putting the user from the very beginning of everything we touch in the center (obviously) and by running methods and principles I'll present.
We are part of the app department and responsible for the iOS and Android app. Since apps taking more and more emphasis in our business we are about to redesign and rebuild them. And that not by creating a big bang and publish something completely new, but working on the existing app and redesign it step by step. And there are several reasons for this: Users are more likely to accept small changes rather than a big because they are creatures of habit. A change means, they have to take the effort to get into it again which makes them feeling mad, even if the changes are improving their experience. But also it has a better impact on our design- and develop process. The big keyword is Iteration. By keeping changes and releases small we can exactly analyze the user reactions and the data to adjust in further iterations.
Every iteration starts either by learnings from previous iterations or new hypotheses and assumptions. Through research understanding phases we get a clue on the performance of the user experience and can figure out what we should tackle. Coming from the business site, there might be assumptions like a new feature will increase conversion or income but also there are KPI's which needs to be considered. With further ideation and testing, we figure out, if those assumptions are right and if there is a need. We do this by analyzing tracking data and using many research methods.
Depending on the state of design and development we use different research technics. When we start to touch a completely new section of the app, we analyze the actual state. It can be clustered into two fields:
We check everything relevant we can get out of our data. That might be tracking data, download numbers, ratings in stores and more. In some cases, data from other departments like 'desktop website' can also be used - it depends on the kind of data and the similarity of the user experience. A/B tests are also really common in our process. If we ship a new design or feature, we publish it in the beginning just to a small percentage of users. On one hand, it is really helpful for the developers so they can see if bugs are occurring without affecting all users of the app. And on the other hand from the design perspective, we can check which impact this change has to be able to adjust if necessary - also without affecting all users.
Listen to the user: Since user experience is about to focus on the user needs, it's no surprise that you also get in touch with real users. On our platform, we constantly running surveys out to users to get their feedback. We cluster and summarizes this and take it into our ideation processes. We also invite users constantly on one day of every week into our office. The use cases we test are sometimes really different. So we need users, who fit the testing. In our case, mostly we want to test with users who are actively using the app. To find them we use data out of user accounts. (All handling with user data are secure and anonym.) In our office, we have an observation lab with camera, sound and desktop synchronization from the testing room into the observation room. There is even a fancy police-observation-style mirror! But that's not crucial. Usually, we invite five people over the whole day. Our researcher is running the test with the participant and on the other side, there's us designers but also developers, product people, and many others. It's important to be there over the whole testing day. You understand way better the problem the users have, as you get summery. Also, it's possible to iterate directly during the test. If there is a learning out of the first test, we could make a little change in the prototype for the next user. It shouldn't be too big changes between the participants, otherwise, it's hard to compare the outcomes. Also, it's important to keep in mind, that this kind of test is a qualitative test. You just ask five users. So it's about to compare and prove the results also with data and the expertise of the team.
Another testing method is guerilla testing. You simply go out on the street, to a café or train station and ask people if they would mind to take some minutes for testing. Next to our office, there's a train station. Train stations are perfect because the people on the platforms are just waiting for their train and you don't really interrupt them. But the chance to find people who are also your target audience is very low. This method is mostly suitable for research regarding the UI or information architecture.
Research and user testing should always be the fundament of design. It's actually quite impossible to create a good product in isolation. Constantly tests in every state of design is gold. You are able to quickly adapt the approaches into new directions for better results.
Ideation and Design workshops
After we defined the problem and we know on what we work next, we doing ideation workshops. We prepare those workshops beforehand by bringing relevant information out of the previous analyses and research together. We have or we create personas who help us to be focused. An important task is to prioritize the problem(s) we are going to work on. It's the first step to keep things small and to be focused within the workshop. Furthermore, because prioritization is always king. For the workshops, we have always non-designers participating. Developers, product people and other have always great ideas, insights and know what's technically possible and on top, they open us other perspectives. We create assumptions which are the goal or needs. An example: "We assume that the user needs a better orientation for the usage of the markers on the map." Since the assumption maybe was even part of the early research, we could go into more detail with some learning. "We assume that a random clustering of markers on the map - bases on the zoom level - is confusing the user." Now we could combine those two assumptions and start a brainstorm session for 10 minutes.
In this stage, it's all about ideas. As usual: No idea is a bad idea! There is no restriction of just scribbling ui's. In my case mostly it's even more effective to just write down the ideas. Afterward, everybody is presenting his ideas, giving feedback and maybe having a little (!) discussion. Then the next brainstorming session begins. Everybody is allowed to grab ideas from others to evolve as much as possible. In the end, we rate the ideas but also the designers think separately about everything. Now if we decide for some ideas, we're ready to go to create prototypes.
With all our assumptions, we could always be totally wrong. So it's important to clarify if the approach is right before spending to much time with the details of design and development. Here's where prototypes are stepping in. There are many ways we create prototypes: We use InVision for simple click dummy's, Principle for more interaction, also we testing always the current state of development and we even just show screenshots. Probably the craziest prototype we've ever done was by paper. But in fact, it's quite useful! It takes not that much time to create and everybody can do it without any design tools. And while the feeling of interaction is different and not meaningful it still can start conversations with the test participant about this idea. In the following image, we tested the idea of a quite illustrated space range slider. The outcomes were that this kind of interaction makes the user having a negative impression even when he set a high but small range because the active range is quite small.
Prototypes must not be perfect. There is anyway often not the time to create a fully functional prototype as you would experience in a real app. You need to be aware, that sometimes the user just struggles because of a bug in the prototype. But as better they, the more accurate is the outcome.
All this processes and methods just work out well, if you're having great people around you and the space for 'craziness', failure and out of the box thinking. In the last year, we established some new processes and some of them might not seen as productive as they are.
So what wasn't new and is anyway part of Kanban, Scrum and co are short daily meetings in the morning to give the whole team the chance of exchange information about their work. Also, Retro-Meetings in the end of every sprint to clarify issues within the workflow and the team but also to highlight thinks that run well.
A new method we established in design workshops are warm-ups. Warm-ups are little games, mostly forcing you to stand up for getting awake and fresh, to boost the team spirit and free your head. The games take just three to five minutes and really making a difference to begin a meeting. We even sometimes use it for other kinds of meetings. A game can be as simple as you just stand in front of a college and clap in each other's hand with a particular order. If you mess up the order, you have to react in the next clap different ... I promise, that will make the people laugh. And how else you want to start a meeting?
Read here more about those warm-ups
Thanks to Caroline Smith, Lena Sarp , Rimas Albert, Leonie Brewin, Paul Befort and the rest of the team at ImmobilienScout24 for the time we've enjoyed together over the past few months.