May - June 2017

Tackling mental health for Syrian refugees in Germany

My Role



Luke Guilford - UX, UI

Nick Hayes - Adjunct professor

Trost (noun): Comfort, consolation (German)

This is a long, in-depth one, so buckle up. The brief for this project was to design an application related to transport. So we started off putting down everything we could think of and there were plenty of local issues in there, but to be honest, we felt that a lot of them in the greater scheme of things weren’t really necessities, but rather ‘nice to haves’ for a developed society that’s doing ok already.

That’s why we turned towards one of the greatest transport problems of all; the Syrian refugee crisis.

Doing some quick research, we came across an article written by a German aid worker at one of the refugee camps, who identified trauma as a major problem for arriving refugees:

Another issue is that some refugees—maybe more than we will ever know—are traumatized due to their experiences in their home country and/or during their escape. It is impossible to identify all the cases of trauma because we have to rely on the information that refugees give us or the information we obtain through translators.

Storyboarding the refugee experience

As you can see, our initial ideas focused more around the bureaucracy involved with arriving in Germany and the federal asylum-seeking process that they have. We quickly realized after reading through some pretty tough legislation that this wasn’t an area that we could have much impact in.

Information Architecture and Wireframing

We decided to split the app into two sections, one for the aid workers (a backend of sorts), and one for the refugees themselves.

The most useful part of this process is being able to quickly and collaboratively iterate through layouts in the context of the whole system. With the current state of digital prototyping/wireframing tools, it’s very difficult to attain the same level of efficiency on the computer.

Wire-framing took a while for us because there were several fairly complex areas of the app that displayed a lot of information. It was useful to be doing this on a large whiteboard in class because when we got stuck, which we did a couple times, we were able to ask Nick for input, and everyone could draw and talk over the problems in real time. Nick was really valuable at this stage, helping us to see places we could distill complex concepts into simplified, smaller chunks.

For example, our analytics page (which displays the refugee population’s health) was initially set up with a large graph that was too overwhelming, and Nick suggested that rather than showing the entire dataset, we could filter out the outliers and display those instead. That way, it would be easier for an aid worker to quickly identify those that needed the most help.

Ah Android...

In Syria, nearly 90% of smartphone users have Android phones. So that meant we were going to be designing for Android, which neither Luke or I had much experience doing.

To make the app accessible to as many people as possible we were looking to use familiar Android UX patterns rather than reinventing the wheel.

However, I quickly realized that I didn’t really know anything about said Android patterns. For example, while trying to figure out what these icons on Android phones mean:

I found out that Android has two kinds of back button:

The first, called an ‘up’ button, takes you back to the last screen you were on inside the app. It moves up through the app’s navigational hierarchy.

The backwards triangle icon which is always displayed on the phone itself, takes you backward through the last screens you viewed anywhere in the OS, meaning it will take you out of the app if necessary. Images from

Good to know.

Next challenge: right-to-left text

The Arabic language spoken in Syria is written from right-to-left, while German and English are left-to-right. The space constraints we were working with on a mobile app were quite tight, so we had to take this into account from the start.

To account for the switching text directions, we set global alignment that wouldn’t change for all of our interactive UI elements, and gave the text its own area within which to change, as shown in red:

Designing the community system

I got halfway through making digital wireframes in Sketch and was thinking about what else we might need, when I realized we’d overlooked something pretty big in our mapping;

The ability for users to report content/block users.

Now, seeing as this forum is intended to be a place for people to feel safe talking about their mental health experiences, it’s pretty embarrassing actually that we forgot this. I was reminded of a tweet I saw once by Tracy Chou, a software engineer who does a lot of advocacy work for diversity in tech:

And a section of the conversation that came from that:

And they’re right, I’m in the privileged position of not having much experience using these tools because for the most part I don’t experience any real harassment online.

How to fix it

So to fix this I did some research into (good) existing tools, such as Talk by the Coral Project.

The main takeaway I got from this research is that it’s important for users to be in control of what they see and the information they share. I set up some goals for the community area/forum design:

I also mapped some of the assumptions I had about the subject.

I did some research into issues specifically surrounding mental health and trauma, such as PTSD:

One of the most difficult parts of living with PTSD is how memories of a traumatic event can be triggered by stimuli in everyday life. So I decided we should give users the ability to filter out content they don’t want to see. 

I did some micro-wireframing to figure out how to allow users to complete 3 main actions related to managing what they see:

  • Blocking a user
  • Reporting a post (for moderation by the aid workers)
  • Muting categories of topics

Category muting

I figured this would probably best be done by using popup dialogue boxes that retain some context as to where you are, rather than pushing to a completely new screen. I sketched out that flow below:


Users can granulate their reasoning for reporting a post to give the moderating aid workers more insight into the problem.

This is the wireframe of the category muting flow. Notice that you have the ability to report the post and block the user at the same time as muting the category. For convenience, like. Buttons are also disabled until all required actions have been completed. This is both an affordance and a backend consideration, since we’re trying to be as realistic as possible.


We wanted to choose a colour palette that would be soft, soothing and not immediately associated with any of the parties involved. For example, we avoided red and yellow since they’re the colours of the German flag, and Islam (many refugees coming to Germany are Muslims) is often associated with green.


We settled on Lora as the heading face because it was friendly but also bold enough to lend hierarchy. We paired it with Roboto to ensure that the app still felt like a native Android experience.

Text inputs

I had quite a hard time designing text inputs that were clean but clear enough to be usable. Default Android text inputs have subtle underlines rather than boxes, but I mocked up one of these and it felt like the line was signifying a divider:

I experimented with several layout configurations and ways of explaining the box for the main input on the forum homepage.

I decided on the final one (highlighted in blue) since the actual input area had its own discrete box to avoid confusion with the explanation text saying ‘here’.

Another decision we made was to use purple for actionable elements, i.e. things that would perform actions when interacted with.

Daily question flow

The daily question feature allows aid workers to ask refugees targeted questions designed to extract as much useful information about general mental health as possible. As such it’s helpful for them to have some kind of aid to get the most out of the questions they ask.

So here I’m working through iterations of how we could suggest edits to the aid workers as they fill in the input. An intelligent engine would formulate sentences in the background based on the success or failure of past daily questions and what kind of information the aid workers have specified they’re looking for.

Any time a phrase could be improved, the app will highlight it in red and tapping on it will show possible alternatives, like a more powerful version of spellcheck.

I tried a couple versions of what the replaced text would look like and felt like the one on the right looked too much like a hyperlink, so went for the one with a box around it, same format as the red highlighting.

PTSD survey

During my research into trauma endured by refugees it became apparent that PTSD (Post-traumatic stress disorder) was one of the main mental health disorders encountered by refugees, but aid workers had trouble diagnosing such large numbers of people.

We created a survey for the refugees to complete, based on the PCL-C checklist used by medical professionals. Initially we debated whether to include the survey as something that would need to be manually performed by aid workers with each refugee, but it seemed like this didn’t really make anyone’s lives easier. In the end we put the survey in the on-boarding flow, so refugees would be required to complete the survey before having access to the app.

The next question button is greyed out until an answer is given.

I wanted the explanation of the service to be as simple and sensitive as possible at the beginning. We also translated an Arabic version to make sure the layout wouldn’t break.

Forum question cards

The cards that displayed questions in the forum are a very tight space that need to display a large amount of information. The one I struggled with the most was displaying whether or not a question has been answered.

Below is the first iteration. We liked how it was compact but we needed the horizontal space it was taking up for longer names. We also weren’t sure if a simple tick would get the point across that it was answered. The green box didn’t make it clear that there were 20 comments either.

This is better, but the answered badge is too eye-catching and takes up an entire horizontal row, and we still hadn’t given the username the space it needed.

This is the final iteration, with less emphasis placed on the badge and the username given the space it needs by moving the comments up onto the same row.


Motion allowed us to create affordances within the interfaces. For example, in the following gif, the text input morphs into the page header, which indicates to the user the action that has occurred and gives them context as to where they are in the app’s flow.

And in this one below, the recommended passage moves into place in the input field to demonstrate where the new text is coming from, which gives the user a better idea of how the feature works.

Below, when a new comment is posted it animates in from the side to both give the user confirmation their action has succeeded, and show them where it went so they don’t have to look for it.