Nedby

About Nedby

Living in a building can be messy and full of unwanted distractions.

As of right now there's not an obvious tool to deal with communication in buildings, and help deal with daily problems.

Some people use WhatsApp groups that don't help focus on the tasks at hand and add undesired noise and distractions. A few use half-baked apps. Others avoid any solution all together.

Nedby is a task focused tool that helps connect between people living in a building and it's managament company.

The Challenge

Help people in a building connect and act quickly when something needs attention, yet keep distractions to a desired minimum.

Goals

  • Research and discover features to include
  • Develop an interactive prototype of the residents app

My Role

I led the research and design of the project.

The Method

  • Discover the problem
  • Define it
  • Develop the solution
  • Deliver

Early Research

I started the process with the bussiness goals in mind, and used the Lean UX Canvas to  organize all the information I had about the project.

The users I focused on are family parents and young students.

The main problems I decided to focus on are communication between residents, and between residents and the management.

Users

  • Family parents
  • Young students
  • Management company workers
  • Old couples

Problems

  • Communication between residents
  • Communication between residents and the management

Competitive Research

I researched eight competitors. One of them in Israel where the main market is targeted, is focused on providing a similar service. The other big direct competitor being WhatsApp groups.

Weakneses

  • Slow and unintuitive UI
  • Not being task focused
  • Focusing too much on being a chat app - which in turn creates distractions
  • Lack of relevant features

Strengths

  • WhatsApp - Already installed and doesn't have any learning curve for users
  • Existing parterships with management companies

User Research

Five people were interviewed, two students and three family parents. Here are some of the main learnings.

Crowdsourcing

Challenge to get people to contribute. Since it's such a big part of the app it has to work for the service to reach its' potential and really solve the problems it's supposed to solve.

The option to rate problems as more important.

Choice

It was also important to give people the choice to filter the reported problems so that they can see things that are relevant to them only.


More

They'd like to know the status of reported problems.

They don't want another WhatsApp group and notifications of people that won't stop talking about irrelevant things.

Personas

Using data from the interviews, I built 2 personas: Phil the family man and Sarah the student. I also built a proto-persona for Maya the manager, which will come in handy when building the management's version of the app.

Let's focus on Phil...

Phil the family man

Now let's build the solution!

User Stories

We'll focus on two processes, adding a new report and adding a new poll.
I've highlighted the three relevant user stories below.

Sitemap

I mapped the app and then verified the architecture with card sorting.

User flows

Let's see Phil's user flow when adding a new report.
He'll be able to choose whether he wants to report a problem, make an announcement, ask a question or add a new poll.

Sketches

Crazy 8

I started by sketching a few quick ideas and then started seeing things about some of them that I wanted to explore further. I ended up realizing I wanted to include a dashboard in the app, so I designed that as well.

Dashboard

The whole process for designing the dashboard took me back to the drawing board.

I ended up listing and ranking eleven possible widgets. Each one of them thought from a possible action that the user seeks to perform. After that I wrote down what information it displays, and what happens when it's tapped/activated.

Final sketch

Out of the eight initial sketches, I ended up taking a few things from four of them and with those in mind I made the final sketch.

Wireframes

I built the wireframes using Figma, improving each version and making sure to answer to all the challenges that arose from the research.

Crowdsourcing

The main solution to the challenge of getting people to be part of the crowdsourced features in the app evolved quite a bit throughout the different wireframe versions. The option to rate problems as more important with the vote up button was there from the beginning of the process. A few new things that were added were: The points system - which has been proved to work for crowdsourced systems like Google maps and Waze, the helper of the day feature which highlights daily who earned the most points by helping the most.

Choice

It was also important to give people the choice to filter the reported problems so that they can see things that are relevant to them only.

An important decision I made was to have my floor in the filters and not the option to filter all of the floors in the building separately. Based on the research I made it was clear that giving people the option to choose between all the floors in the building would just add irrelevant noise.

Prototype

The next step in the process was to take the wireframes and build an interactive prototype. I used Figma for this process as well. For Phil's journey in the app, let's use the user stories we highlighted before (hint: reporting a problem and adding a poll).

Filters

Phil gets out of the elevator in his floor, and he sees the lights burned out, again.

He uses the filters to check if anyone has reported the problem in his floor, but he sees there's only one report about the water heater.

The other available filters to Phil besides his own floor relate to public spaces in the building, which are relevant to him as well.

New report

Phil taps on the Add new button, a card slides up and he chooses to report a problem. In case he taps the wrong button, the option to switch is right there above with the same familiar icons. It's was important for navigation in card based interfaces to be simple, that's why I avoided pages and back buttons.

Phill fills the report's details and adds it. The problem is highlighted as new at the top of the list for the first 24 hours to give people time to up vote it and then it is positioned accordingly in the list.

New poll

Once he's done reporting the problem, Phil has an idea: What if they changed the lighting in the building to LEDs? He should probably check if people would be interested in that.

Phil decides to add a poll.

Vote

Now that the poll is added Phil will wait for people to answer. In the meantime he decides to vote up a report about the trash bins being broken, since they haven't been fixed yet.

Phil goes into the polls menu. There he sees his active poll. Since he hasn't voted yet, he isn't shown the results immediately, he can choose to see them before voting since he created the poll.

Once Phil votes the results are updated and an option is given to change his vote.

Main takeaways

This project was a challenging start from scratch. It made me use every tool I had to understand what were the problems and possible solutions I should focus on.

Sometimes things that don't really cross your mind at first become the obvious solutions to certain challenges, once you've developed an idea. That was the case when coming up with different ways to foster crowdsourcing spirit among users - and what started as a simple idea became the heart and soul of the project.

Next steps
The next step would to design a final UI for the product from the wireframe and branch off of this research another UX process to start building the management's version of the app.

let's connect