Our idea

Analisa and I identified three issues that we wanted to address with this endeavor:

The first issue is the poor state of civic engagement. We believe that the tried-and-true methods of engaging with government (e.g. contacting representatives, demonstrating and even voting) are not always the most effective way to impact your community and/or country. It has never been easier to create significant change independent of (or in conjunction with) government due to the pervasiveness of computing and internet access. We wanted get students thinking about how they could engage in the civic process and impact their community through the creation of a software product.

The second issue is the frustrating divide between developers and designers (and any other major for that matter). University departments are often silohed, leading to narrow educations. Excluding prerequisites, engineering majors take engineering classes with other engineering majors taught by engineering professors. The problem is once those engineering majors graduate, they will be working with people who are not engineers. We wanted to create cross-discipline student teams (students from at least three different majors) to work together for a common goal where each major had skills both unique and vital to bring to the table.

The last issue is that higher education is often not preparing students for a quickly-evolving workplace. The typical class structure is heirarchical, highly structured, linear and a “hoop-jumping” exercise. We believe that a healthy level of ambiguity and freedom leads to unexpected, serendipidous learning experiences. We wanted to encourage students to go on tangents, to change course, to fail. Our goal was to put the students in the position to learn and then get out of the way. We intentionally provided minimal structure for the students, which gave them an opportunity to deal with ambiguity (a rarity in the college format) and expect them to create their own support structure.

Class process

We had many rough ideas on the program’s structure, but were loose on details. We hadn’t found any examples of this idea in action, so every choice we made was a best guess. Like most first attempts, there was a lot of learning along the way.

Our program worked in conjunction with a USF Android app development course. The only requirement the students had to follow was the product had to be an Android mobile app. We ended up having five students join this program. Two of the students for computer science majors, two were designed majors, and one majored in theology/environmental studies. The entire project (class notes, output, after-class discussions) was tracked, managed and recorded on Basecamp.

We started by running a workshop for the students to generate ideas around the problems they would be interested in solving. For many of the students, this was their first exposure to an ideation workshop. The session ended with dot voting on their ideas. It took a couple more classes to define and hone the problem space. The students ended up deciding to address the average citizen’s subpar understanding around food.

Once the problem was chosen, the students began to ideate on potential solutions. The app’s focus understandably shifted throughout the course of the semester, but it was helpful to have an initial direction to start from. Once that direction was established, the students researched on the subject matter, created mood board, explored what apps existed in this space and interviewed friends and family for light user research.

Based on their research, the team adjusted their focus and began to sketch wireframes of the mobile app. From the wireframes, they defined the functionality and content necessary to make the desired product.

Once the research was completed, the program became unstructured. Each weekly meetup would have no set agenda. We would discuss progress made, cover any questions or problems that came up and react to what the students needed at that point in time. There were weeks where big, visible leaps were made, there were other weeks where progress was more incremental. Our job was to meet them where they were in the process. This format was what made the class special. There were impromptu ninja user research sessions, there were unexpected and difficult discussions about design direction. There was never a routine.

After the team determined the screens and features to be made, the computer science students began developing a low-fidelity representation of each screen, the two design students created the app’s visual language and the theology major managed all content and wrote the copy throughout the app. Analisa and myself provided minimal critical feedback during the design process. We opted to help facilitate discussions so the team to critique their own work. We didn’t want to provide “just do this” feedback.

In the end, the team produced a working app which was the culmination of all their work and collaboration.

After the program ended, a group of the students had the opportunity to share their work with Jay Nath, the Chief Innovation Officer for the City of San Francisco. Having the opportunity to share their app and experience through the semester was a great way to cap things off.

What I learned

Planning is great – when you know what to plan for

Analisa and I only had two weeks to plan out a structure for this program which ended up being a blessing in disguise. There was no way we could have predicted how the semester would (or should) have played out. Since our plan was loose and not wedded to any process, the structure was able to evolve on a weekly basis.

There’s a bit of a learning curve

We put too much on the students too quickly. The combination of the program’s different approach, the lack of structure and the sheer volume of topics covered took some getting used to. Building up the momentum took more time than we expected due to unrealistic expectations. About a third of the way through the semester, there was a “WTF are we doing?” conversation during a meetup. The conversation gave us the opportunity to discuss the inherent ambiguity associated with design. I am certain this will be a common and justified occurrence with future teams. It simply needs to be accounted for and embraced.

Momentum takes time

Isolating the problem the team wanted solve took much longer than expected. We spent roughly half the semester defining problem and researching it. Rather than forcing the team to stick to the schedule, we let the process go where it needed to go. In retrospect, if we rushed this process, I think the students would have learned less and the final product would have suffered.

Managing outside speakers is a logistical nightmare

One idea we had early on was to bring outside designers and technologists in to discuss topics and review the students’ progress. We quickly learned that scheduling these on a weekly basis took much more planning than we could commit to. We think it could be an invaluable part of future programs, but managing that part of the process would require needs to be accounted for.

It’s the student’s project. Give them the chance to run it.

A central tenant to the program was students owned the product and thereby got to make the key decisions. We think putting the onus of decision making on the students is an invaluable learning experience, especially when there isn’t a obvious “right” choice.

This program cannot be canned

The free-form nature of this program makes it too unpredictable to set a repeatable format to follow. The dynamics will vary wildly based on the project’s focus, the student team’s makeup and the facilitator’s approach. Each program will be one of a kind. This is a good thing.

Choose the students carefully

The program’s success was due to the personalities and teamwork of the student team. I question whether you can pull in 5-6 students at random into this program and get worthwhile results. Some key qualities we think lead to good team members are open-mindedness, intellectual curiosity, strong communication skills and the ability to feel comfortable working as a peer and a leader.

Delivering is crucial

The program rides on finishing the final product by the end of the semester. It is key to creating a sense of accomplishment and forcing the team to make compromises and best guess decisions. Delivering a faulty product is a opportunity to learn, delivering nothing is a failure.

Don’t meet in a classroom

It’s not a class, so don’t treat it like one. We met in an informal room around a table. No one sat at the head, no one owned the whiteboard.

Document like crazy!

I should have taken more pictures. In the future, I plan on carrying a point and shoot camera (or a phone with a decent camera) with myself at all times.

Reflection is important

I think it’s important to dedicate time to discuss about what the team learned on a weekly basis. It would have been interesting to add weekly journaling/blogging exercises for the student team.

Next Steps

This idea has potential, and we want to see it succeed. Analisa and myself are going to continue pushing it forward, but it shouldn’t end with us. I want to see other designers and academic institutions taking this idea and making it their own. If you are a designer interested in facilitating a program like this in your local area or a teacher who would like to see something like this at their school, let us know and we love to find a way to help.