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.
Data analyze: 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.
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