Operation Give Back

Selecting an Problem to Address

My GWC chapter wanted to design and build a product to benefit the community. As a group, we wrote down issues we could address on separate sticky notes. After the sticky notes were placed around the room, each member marked the issues they found particularly meaningful or important.

We collected the sticky notes, grouped similar issues, and narrowed the selection to a few problems with the most marks. Amonng these, we eliminated suggestions based on the feasibility of possible solutions and the extent to which they could make a positive impact.

Our group decided to address what students felt was difficulty finding student-friendly volunteer causes/organizations to contribute to. Often, opportunities are limited to those above a certain age, so we wanted to consolidate opportunities for younger individuals.

Solution Planning

Based on the skillsets of group members and our time limitations, we decided to create a Ruby on Rails volunteer match site (Operation Give Back) specifically for students. After brainstorming features that would be essential or desirable in the final product, we used kanban to oragnize sticky note tasks and goals on poster board.

Interface Sketching

After determining essential features, group members sketched variations of possible interfaces for each desired app function/page. For each page, votes were cast to determine the most favored design. The top choice would then be modified to fit development contraints and practical needs.

As one of my most planning-intensive projects, OGB taught me that while extensive planning may be best-practice, that doesn't mean it is suitable for all circumstances. Due to the time-consuming design process, a ridiculously small amount of time was left for actual coding/development. While sketching/problem identification/brainstorming is important, it should never come at the price of getting something done.