Project Design
So, you want to propose a project but you aren’t quite sure what you want it to do?
Or maybe you have the germ of an idea, but it hasn’t been fleshed out yet?
Your starting point should be the main proposal document that lays out the guidelines for the project. However, I wrote this document to give you some more tips on dreaming up a project. This isn’t a design class, so we won’t go too far into the weeds, but I want to give you some design tips that might get you started.
Design Thinking is a process that has five non-linear steps. Like our Agile process, we are never done with a step we can always go back a revisit them as we learn more. here are the steps with some (very) brief descriptions:
- empathize: Empathizing is about understanding your users and the problem you are addressing. When thinking about your users, you can think about demographic data (like age, identity, socio-economic status, etc…), but you should focus on what their goals are, what they struggle with, how they live their lives. The idea is to put aside your preconceived ideas and assumptions and start to think about what would actually help your users
- define: This is where we get specific. Who precisely are your users? How will they use your app? When and where will they use it? What will your app do?
- ideate: Start generating a lot of different ideas about how you will address the problem you identified. Your goal here should be to both think inside and out side of the box about ways to view the problem you are addressing.
- prototype: Create some simplistic models or sketches of some of your solutions and make them a little more concrete.
- test: Try out your solutions and see if they seem promising.
Finding a “problem”
We usually talk about applications as solving a “problem”. This doesn’t necessarily mean that there is a real problem or that the application will solve it (though identifying pain points is a great place to start). It could just be a cool thing. We had a proposal a couple of years ago (that didn’t go forward) that was about building a tool that could be used to construct non-linear choose your own adventure style stories. We have had some games as well. I think it is perfectly acceptable to create things that bring people together or add some joy to the world without there being an underlying problem to be solved. Despite that, we will continue to use the terminology (we can always frame the “problem” as a lack of joy etc…)
Some proposals are clearly about satisfying a problem or desire the proposer has themselves. That is fine, but not sufficient. You should think about who else is in your class of people with the same need. Are their needs exactly the same as yours? Is there a group of people who don’t have the same problem, but would still benefit from the solution? How do you include them? It can help to start general and then narrow in as you understand your user base.
If you don’t have a problem you are already thinking about, there is an exercise I like to get my students in 466 to do. It is best done as a group, but you can do it individually.
I’ve given you some times for these activities. You can adjust them, but I think it is helpful to work to a timer. All of this can be done on pieces of paper, whiteboards (take over a classroom), or a virtual whiteboard like FigJam.
For five minutes, write down as many different categories of users you can think of. Don’t restrict yourself in any way, but try to be specific. They could be specific groups on campus (e.g., CS/Theatre double majors, field hockey players), people in the community (e.g., delivery drivers, florists, community organizers), or just whatever (e.g., cigar box guitar builders, deep sea divers, Doctor Who fans). Go crazy.
Spend another five minutes think about contexts where someone might use a web application (e.g., eating lunch in Ross, during CS class, sitting on the Youngman Field bleachers at 2a). Don’t worry about your users, just stream of consciousness (though you might want to remember that you ultimately want to build a web application so places without computing device or web connection should probably be avoided).
If you are working with some other people take some time now to go through the things you have all written. Laugh about them, compliment each other for the clever ones.
Start writing down app ideas for fifteen minutes. These don’t have to have anything to do with the things you wrote previously. part of the earlier stages was to get your mind released from locked down assignment doing student mode. However, if you are stuck try combining a random user group and context together and propose an app that could support the user group in that particular context. You can also riff on a particular idea as well – come up with variants.
At the end, read off all of the ideas together. Mark ones you like. As you are going, feel free to continue to riff on the ideas. A great approach is the tool used those who are good at improv: “yes, and…”. You build up the previous idea and add a little bit more (yes, and… will also serve you well throughout the development process as you have to make design decisions as a group).
Revisit the ideas you like and start thing a little bit about practicality of them. At the end of this process, you will probably have one or two viable ideas to work with. If not, you will have opened your mind a little and may find new thoughts start to come to you. The process can also be repeated.
Refinement
Once you have your idea, start to refine it. Go through the empathize and define steps and start to work out the details of your user and the nature of your solution.
You probably do not need to go beyond this step for the proposal.
Design
Once you have a project team and a project, you will want to engage a little more in the design process.
You can start with a version of the process above aimed at features or requires. Everyone should start writing down requirements from the obvious to the out there. Then as a group you should go through them and decide how to classify them: central, good if you have time, long shots, or not feasible.
Once you have a set of requirements, you should start drawing interfaces that satisfy them. Everyone should draw a couple possible interfaces individually or in sub-groups. I recommend that everyone come up with at least one “obvious” interface and one out there one. Walk through them all as a group and then decide on a direction.