Redesign:This is what we did to make our open source app work and look slick

I was more than happy to work on enhancing user experience of this project, so I teamed up with Mateusz - our designer to solve the problem.

At that time the app looked more or less like this:

What struck us at the very beginning (besides the UI), was the long list of pending requests on the left.

We knew the exact user persona behind the app, so we started our path to redesign by thinking of basic user scenarios to understand how users use the app.

Turns out, they are pretty simple:

1. User has a problem with some field and needs help.
2. User was asked for help.
3. User has some spare time and wants to help others.

Having these scenarios in mind, we could now think of a few possible reasons as to the why pending request list was so long.

If the user is a recipient:

• The recipient has to many requests and becomes overwhelmed
• The recipient doesn’t know how to solve the problem
• The recipient has no time to solve the problem at the moment

If the user has no requests, but has spare time:

• The user can’t tell at a quick glance the category of the request
• The user can’t tell the status of the request, nor when it was made
• The user doesn’t know that he can hijack the request

A few of these problems could be solved on the main screen, while others were solved on the request form screen. After making few sketches and having a few calls with Mateusz, we had an initial vision of what we wanted to achieve.

Let's start with the main screen, because it's the most important part of the app.

We removed the big green button and moved it to top bar, as it's more like a configuration option, rather than an action that should be exposed.

Since the recipient of a request is notified by the email (and therefore knows that there is a request waiting for him) we decided to change the way we show the requests on main screen by exposing and adding few details that could be helpful to others like:

• Bigger, more noticeable category name. This was mainly done for visibility reasons, and requests don’t cluster into one long block of text
• Visual status indicator. A quick glance tells the user if the request needs attention or if it is ok.
• X days ago. If request is more than few days on the list, it gets priority for attention.
• X comments. Users know if the request is being discussed or not.

We also moved the recently helped requests to a tab so users can focus on problems that need attention. We plan to introduce a search engine in the future so users will be able to search for similar issues. For a touch of encouragement, we added some statistics at the top of the page saying how many requests have already been solved!

As for the UI, we decided for a really clean and minimalistic look, nothing fancy to ensure that users can focus on solving the core issue. We also decided to make it fully responsive.

And here it is! The redesigned main page:

Making a help request

Beside adding new narrower categories, we also added small changes to the request form. We didn't want this to be some kind of boring ticket system; we wanted it to look like a conversation between team members. Since a lot of us work remotely, we decided to keep user avatars in place.

At this point, the system still selects a random supporter and shows a list of other users that could help in picked category, but we also show the number of pending request. If the system picked someone that is busy, you can select another supporter.

Now, you might ask why we show supporters that already have pending requests? We could filter them out, but we have a good explanation: In a few of the categories, there could be situations where every supporter could have pending request and solving them could need more time. Another answer is that you can see who to turn to next time when you will have problem in this category. The most important answer is that you can check which supporters are in the office and you can just TALK to him/her about the problem :). In such cases it's good to write the solution for the problem in the help request after you’ve chatted.

Receiving a help request.

On the request page, we added a few missing actions.

The first is the 'skip' action. Don't have time? Don't know the solution? Tried to help but failed and need someone with more experience? Just pass on it, and remember to write a comment if any actions were already taken!

We've also added the 'acknowledge' action, so that a requester knows if somebody is already working on the solution for the problem.

At some point, we also noticed that sometimes users just forgot to click the magic 'mark as done!' button, and this also was a reason behind some pending requests being on the list for too long. We've added the "I've received help!" action as a possibility for requester to mark the request as finished.

We also announced to the team that it's OK to take over someone else's requests.

This system just works naturally. We do not enforce solving requests from our employees, or cut their paid holidays if they don't play, and we don't give any bonuses for the highest scores. We strongly believe that helping each other just comes organically from a strong team.

Since this is an open source project, it has its advantages and disadvantages. We were redesigning the app in pull requests step by step, and every one of them was discussed via github by interested people. There were few good ideas suggested by github issues that we considered helpful and added to the app. But because we were designing and developing this as a side project (in our dedicated open-source time), while working full time for clients, there are still a few functionalities waiting for implementation. So take a look for yourself and visit the issues page on github.