Term Project Stage 1 Complete Look at the Term Project Outline and make sure you have completed all the deliverables stated there. In addition, write and submit the Team Retrospective. Deliverable: Iteration Retrospective as a pdf . (Begin work on Stage 2!)
Principles of UI Design: Read this article about about principles for a clean visual design Select two of the principles and find two examples of web sites or mobile apps that VIOLATE those principles. Write a 1 page paper with images, explaining the two principles in your own words, showing the examples that you found, and explaining why they violated the principles. Deliverable: Submit to Latte, as pdf
Two Screens of your App: Read a second article to inspire you on how to create cheap sketches and mockups: Everything you need to know about UX Sketching.
* Now, design and sketches of the two most important screens in your app. Work independently to see how different ideas come out. Try to use some of the principles from the articles above. You may use any tool(s) you want - pencil and paper, watercolors, photoshop, but really I recommend www.balsamiq.com. It is important that you work neatly and clearly so we can appreciate your ideas. I will be looking specifically to see that you thought about hierarchy, placement, sizes, alignment, balance and so on. Deliverable: Post a pdf containing the two images, and your commentary. We will review them together in class
Teams do more out of the building testing: Decide on and do more out of the building testing: survey, 1-1 interview, landing page, anything else you can think of. Make sure you know and indicate what the hypotheses were that you were testing as well as the methodology and results of the test. Record your work and the results. Remember we are looking for non-trivial amount of outside testing. You will need it for your term report.
Each team shows off their two screen samples
Each team discusses their out of the building experiences
What’s the difference between a mockup and a prototype?
Note that hardware and software are very different in this context
Mockup typically is static and non-functional
Prototype typically is somewhat dynamic and somewhat functional
But there is a definite grey area in between
What’s the purpose?
It’s a classic MVP testing one ore more hypotheses
Therefore the amount of “fidelity” depends on what the hypotheses are
Pick the approach that is the cheapest way to check those hypotheses
Only create one when the cheaper or more important hypotheses have been tested
(Software) Mockups and Prototypes, from cheap to expensive
But also makes it less painful when it has to be changed totally
Allows a user to take over and cross things out and suggest other ideas
You can take this as far as you want.
Smaller snippets for the various ui widgets (e.g. drop down menus)
Make a “screen flow diagram” by connecting the different sheets of paper with lines showing the transitions
It is similar to a movie ‘storyboard’
Here is my example: not good UI.
Why I insist on ‘paper prototyping’
How ugly can it be?
Role of the UX Flow Chart
“Get out of the building”!
It’s so much easier to grab one or two or more real humans
Evidence from 2 or 3 random people is often enough, but really you don’t need for than 5-10..
Can be conducted at any stage
Online mockup or ‘wireframes’
The difference is how hard/painful it is to make changes - which is inversely proportional to how open you will be listening
This could be testing a paper prototype
early, when it is easy to make big modifications,
or later with actual software - when it’s more difficult to make changes
Decide on a task(s) for user. “Log in and post a picture”, “Check and update your privacy settings”
Decide on the type(s) of users.
Decide on what knowledge or assumptions they will start with (new user, experienced user, musician, programmer, etc.)
Rules of thumb to follow
Try to get the ‘victim’ to narrate their thought process
Make sure they know that if they are confused, it is the fault of the software, not their fault
If and when they get stuck, engage them in a conversation by giving them small hints
Ask them for a suggestion on how it would be clearer, for example:
“Let’s say you want a plain pizza and you see this screen, what would you do?”
“Oh you can’t decide, well tell me, what are you looking for right now on the screen?”
Running the test
Mistakes are ALWAYS the fault of the software not the user. Make sure they know this and don’t feel like they have to appologize when things go wrong.
Ask them to narrate their thought process: “I am not looking for a button called security or privacy. Oh here’s one called settings, maybe that’s it. I am going to click it. Hm, I expected to find security related stuff here but instead I see…” etc.
Keep it simple
You don’t need a one way mirror, video recording etc etc.
You don’t need 10 subjects. Usually after 2-3 you already know what the problems are