Good Apps Make Good Neighbors

Strong communities are built one relationship at a time, and research has shown that personal well-being is improved when people build connections in their immediate local area. But these connections can be difficult to form for a variety of reasons -- rental occupants may change regularly, individual lives have different schedules, and the population may reflect a variety of cultures, ages, and family sizes.

MAIN DEFINITIONS

  • Neighbor: A person who lives near or next to another;
  • Neighborhood:The immediate environment; surroundings; vicinity related adjective vicinal; a district where people live; the people in a particular area; neighbors.

DESCRIPTION OF THE SOLUTION

  • Name of the application: GoodHood;
  • Purpose: A free of charge mobile application able to build and strengthen relationships between neighbors;
  • Core functionality: Find neighbors’ profiles for each address provided by the user and create a connection with them;
  • Main Features:
    • Discover your neighbors. Attach location references (address, floor, name on the buzzer) to the user profile and discover who are your neighbors;
    • Say “Hello” to your neighbors. When a new location is added, a standard/custom broadcast hello message is sent to your new neighbors;
    • Neighbor-funding. If you need some ingredients to complete your cake, if you need somebody who takes care of your children for a night, or everything else, ask to your neighbors. Providing symbolic rewards as thanks will help you to know better your neighbors and it will increase everyone's ability to share;
    • Events creation. Create events and celebrate them with your neighbors. A possibility to extend the invitation to neighbors of neighbors is provided;
    • Public shoutbox. Get in touch with your neighbors by writing or commenting public posts.

SKETCH OF THE DESIGN STRATEGY

Business Goals

  • Gain/Retain users;
  • Upsell advertising space.

Target Users

People (single person, families, friends, etc.) who bought or rented a house in which they are currently living.

General Tasks

  • Know your neighbors;
  • Interact with your neighbors.

Technology (or other) Constraints

Mobile devices.

Marketing/Branding Goals

  • Increase brand recognition in the online space;
  • Stable, reliable.

USER/AUDIENCE ANALYSIS

User Profiles

Supposing that our data are coming from an iterative process of analysis on the population, we can summarize them in the following table:
Neighbor
Age/Gender 50% Male, 50% Female, Age 25 - 55, Median 35
Education Some higher Education
Language English
Computer/Web Experience Low to Med
Domain Expertise Med
Task Knowledge Low to Med
Expectation Ease of use

Persona: Neighbor

Doug Heffernan
  • 35 years old
  • Married
  • Delivery Man
  • High School
  • Full-time employee
  • Minimal computer experience
Doug never hesitates to protest his grievances intensely. Some of his misadventures are fueled by his love of food. These basic desires sometimes cause him to think of strange, intricate schemes in order to get what he wants, although they usually fall through in the end, causing constant squabbles between him and his wife. Doug's tendency to give in to his temptations, despite promising his wife otherwise, is another common cause of disagreements. He generally enjoys the simple pleasures of watching sports and playing poker with his friends. [Wikipedia]

MODEL OF THE DOMAIN

After having built a better overview of our users, our goals, and our vision, is time to make a sketch of the domain. As shown in the picture, an important attribute of a "neighbor" is its location. The "location" is an entity in strong relationship with the "neighbor" instance.
In addition is important to differentiate between different types of locations: in an apartment your neighbors are the people living in all the building, in a house, your neighbors are the ones leaving around you.
Model of the Domain (Sketch)
Model of the Domain

PRIMARY NAVIGATION

The primary navigation will be like the one shown in the following sketch. The idea is to have a persistent primary navigation to facilitate the users in accessing the five available sections.
Primary Navigation (Sketch)
Primary Navigation

FLOW: Neighbor-Funding

Create a new Request of Funding

This flow sketches out the creation of a new funding request.

Elements to highlight:

STEP 1

  • On top of the list of the actual active not supported requests there are some filters like: Requests I'm hosting, Requests I'm supporting, and so forth. The filters will be shown only when there is at least one element corresponding to the filter category.
  • The button to create a new request has the following behavior: it disappears (falling down) by scrolling down the page, it appears (rising up) scrolling up the page. At the first access of the section, when the scrolled content is equal to 0, it is visible.

Create a new Request of Funding (Sketch)
Create a new Request of Funding

Browse Funding-Requests and Support one of them

This flow sketches out how the browsing and the supporting of requests are done.
Once that a request has been supported, it will be not visible by other neighbors different from the supporter in the "Neighbor-Funding Section" list.
At the end of this flow, a notification will be sent to the owner of the request.
Browse Funding-Requests and Support one of them (Sketch)
Browse Funding-Requests and Support one of them

HIGH-FIDELITY MOCK-UPS

To speedup the creation of high-fidelity mock-ups I used:
  • Holo Widgets: Available on the Android official website;
  • Flaticon (www.flaticon.com): A large database of free vector icons.

Neighbor-Funding Section

Neighbor-Funding Section
Neighbor-Funding Section

Supporting a Funding Request

Supporting a Funding Request (STEP1)
Supporting a Funding Request
Supporting a Funding Request (STEP2)
Supporting a Funding Request

DEVELOPMENT PROCESS

The process that I would like to use to approach the selected design problem, is a process that is both user-centered and agile. In the following lines is given a high-level overview of the process.

We will have 6 iterations of 2 weeks each, and the process will be split in 4 main phases:

  • Discovery (I1 W1)
  • Design (I1 W2)
  • Construction (I2-I5)
  • Transition (I6)

Phases Overview


Discovery
  • Strategy (objectives and goals of the project, oranizational requirements specification)
  • User/Audience Analysis
  • Task/Purpose Analysis
  • IA Analysis
  • Workflow Analysis
  • Usability Testing

Design
  • Conceptual/Mental model, metaphors, design concepts
  • Navigation Design
  • Detailed Design
  • Wireframing
  • Prototyping
  • Usability Testing

Construction
  • Detailed Design
  • Prototyping
  • Implementation
  • Testing (Usability Testing included)

Transition
  • Implementation
  • Testing (Usability Testing included)
  • Deployment

Some Remarks

  • At the begin of each iteration a meeting is required (evaluation of the previous iteration, planning for the new iteration);
  • Daily Standup meetings required;
  • The Design Team will work one iteration ahead of the Development Team. The Design Team at the begin of the Iteration will test the code produced in the previous iteration by the Development Team. The Development Team will work on the material produced by the Design Team during the second half of the previous iteration;
  • At the end of each iteration done in the “Construction Phase” and in the "Transition Phase", a runnable application has to be delivered;
  • Both the teams have to participate in all the phases;
  • Especially in the first two phases, keep the documentation lean and easy to consult. Don’t produce documentation that will never be read from others. The documentation has to be useful also for the developers.

Team Overview

The number of required resources for the project is from 3 up to 5.
The team needs to have good skills in UX Design/Testing and in Front/Back-end development.