UI Design Seminar

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!)

Project guidance

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.

First things first, in our efforts to not go insane grading things at the very last minute, we’ve decided that April 15th is the drop dead date for turning in homework. We will accept homework up until the presentation starts, but any homework turned in after 5:15, April 15 will not be accepted or graded.

With that little bit of fun out of the way… it’s time for the final project assignment. We have it all put together in a nice printable one-page PDF, so feel free to download it, print it, lose it, repeat and rinse.

CS 4963 Final Project Assignment (PDF)

But in case downloading and viewing a pdf is too cumbersome for the go-go lifestyle of the modern college student, I’ll give you the whole thing here too.

CS4963 – FINAL CLASS PROJECT

In groups of two, design an application that uses Twitter for a specific user and a specific use case.  Present your design in a lightning five-minute presentation (not unlike Ignite).

But why Twitter?

Twitter has a rather simple API, so if you do prototype your design, it’s pretty easy (even for designers like us) to get something up and running using it.  Regardless of what you think about Twitter, it’s an interesting infrastructure—essentially a broadcast short message medium— with many possible uses.  .

So I have to build something?

We care more about your design. You can make a paper prototype, you can wireframe and spec the thing out completely and NOT write a line of code, and still do well on this project.

Why groups of two?  Urgh, the logistics of that….

Two reasons.  One: on a small scale, it simulates working with other people on a design team.  Plus, brainstorming design ideas is MUCH easier when you have someone else to bounce ideas off.  Two: we’re trying to make this simpler for you…so that you can divvy up the work in two, and this will not be an epic undertaking.

If teaming up for a project is simply not do-able, you need to contact Matthias or Jason ASAP. To repeat… it will not be OK to just show up on the presentation day as a single person unless we’ve OK’d it ahead of time.

What’s expected for this? What should our presentation cover?

Your presentation should cover each of the things we’ve talked about: User Research, User Stories, Information Architecture, Visual Design, Interaction Design, and UI implementation. (If you fully implement the functionality, talk about how you implemented it. If you didn’t implement it, talk about your plan for implementing it.)

We should hear about:

• who is using your project and what they need;
• the user stories that your app will satisfy;
• the sketched screens of your app;
• the visual style guide and show detailed visual comps;
• the interaction and motion standards;
• most importantly, explain your design decisions;
• and sell it with a walkthrough or prototype.
• For bonus points, test it with your intended users.

You don’t have to use Powerpoint, but visual aids will obviously be necessary. Next Thursday you can work through your projects in class—we can help you with ideas and designs in person and answer any further questions you might have.  (Feel free to contact us via e-mail, too.)