FIRST AND FOREMOST
…if you haven’t already, please e-mail us with the names of the people on your team and which day you want to go. We need people to go on Thursday, because, although the presentations are five minutes each, we’ll only have time for five on each day (given five additional minutes per presentation for Q & A and shuffling laptops).
We have one team volunteering to go on Thursday. Who else? (You’ll be done early!)
For those of you who weren’t in the last class (and even if you were there), here’s some additional guidance on the project.
Twitter. Twitter? What’s twitter good for?
It’s a real-time feed, so it’s best for real-time purposes. Things like monitoring and alerts, for example. We brainstormed during last class monitoring such things as:
- your dog
- the beer you’re brewing
- a Woot-Off
- an eBay auction
- your electricity consumption
- the traffic on your drive home
- amber alerts
- your calendar reminders
- your grocery list (detects when you’re in a supermarket using geolocation?)
- the locations and priorities of emergencies in a crisis (like an earthquake) for first responders
Theoretically, you could also use twitter for polling the wisdom of the crowd, since twitter has a critical mass of a LOT of people on it. The problem with this, at least with the current twitter clients and current UIs, is that unless
- you are “popular” and have many followers,
- or get retweeted by someone who does,
- or are lucky enough that someone knowledgeable who likes to answer questions searches for terms or hashtags used in your question,
…then you’re largely out of luck. (These problems aren’t insurmountable, but not many people have addressed them.) If you do have a large number of followers, you can use twitter as a medium for polling, voting, and crowdsourced tasks, and add those to the list of brainstorms above.
I had an idea, but someone’s done it before.
That’s okay, you can still use that idea for your final project. Note how your design is better than their design, and what things they didn’t do that you’re doing (or vice versa: what things they’re doing that you chose NOT to do).
In class you said: KEEP IT SIMPLE.
Why, yes: KEEP IT SIMPLE. Please. You only have a five-minute presentation, and we really want you to focus on the design (design NOT actual implementation), so pick one or two or a ONLY a few user stories, and have your design accomplish these stories really really well.
(You can always talk about functionality that you’re saving for version 2, even if version 2 is hypothetical.)
So what is expected for our project?
In five minutes, walk us through your design process and your design decisions. What’s your process? It’s just what we’ve talked about through this whole semester:
Figure out a use case. Just like our brainstorming above.
Figure out who your user is. (Go interview one of them.) If you’re doing something about car sales, work up a few questions and go talk to a car salesman. If you’re making an app for dog owners, and you’re already a dog owner, talk to other dog owners.
No, really: figure out who your user is. Sometimes in the brainstorm-conversation of interviewing a user, you’ll figure out that maybe the user you’re targeting isn’t the user you want to be targeting. A couple weeks ago, Matthias and I were interviewing a former professional home healthcare provider to find out about what caregivers need when taking care of patients, and what issues caregivers face. We found out that the users we really could help the most were the “amateur” caregivers, the sons and daughters taking care of their elderly parents, for example, versus the professional caregivers. And, in addressing their needs, we could meet the core functionality needed by pro caregivers as well. It simplified the app that we were working on and scoped the features in a good way.
Identify the user stories. You know all about user stories.
Sketch the rough layouts for the UI, keeping in mind the information architecture principles we talked about. Think through (and tell us about) how your user will get from point A to point B, and how they will know they are at point A. Think about what terminology your user uses.
If you don’t have a UI of any kind, …you may want to rethink your project. This is a UI design seminar, after all. We’re pretty flexible on our definitions of UI, but just remember that your users are possibly (probably) not tremendously nerdy like we (you + your teachers) are.
Refine sketches and apply visual design. Clean up your initial sketches. Apply a color palette to your work. Explain why you chose to apply certain textures and colors etc.
(I would suggest keeping your app to only 5-6 screens max, to scope it and keep it simple.)
Figure out the interactions. What’s the flow through your screens going to be? What kinds of interaction—affordances and feedback—are in your app? Walk us through the screen flow in detail.
Walk through all of the above and explain your design decisions. I said this before, I’ll say it again: tell us why you did things the way you did. If you don’t, we’ll probably ask you about it, so be prepared.
If you have time, build it. (It’s nice to have a portfolio piece.)
…holy cow, you read this whole thing. This is a restatement of everything said before, but given conversations during last class, hopefully it helps put things into more context.
Thank you, and don’t forget to e-mail us.