The goal of this project is to design and test an interactive system that solves a problem of significance to a group of users.
Please choose a topic of genuine interest, because then you'll be more engaged in solving the problems that arise.
Because this is an HCI course, the design solution you come up with needs to involve some interesting human computer interaction. This may seem obvious, but some examples of problematic projects from the past include:
A system that detects whether people litter in a public space (unless you focus on the police side of it, there's not much interface)
A system that warns a victim of domestic violence when her attacker is within 300 feet based on RFID (a great idea, but there's not much interface)
A system that automatically recognizes produce at the grocery store so that you don't have to type in the ID number (another good idea, but not much interface: "I think it's a pear. You want to challenge?")
The system doesn't have to be complex, but it'd be nice if there were some challenging design issues.
A website redesign is not complex enough (e.g. redesign of an ISU department's website)
A redesign of Gmail's user interface in which you move the buttons around is not complex enough -- it doesn't qualify as much design thinking. A good reframe that does require good design thinking would be if you say you're going to redesign it by changing the dominant interaction metaphor, e.g. you're going to redesign it for elderly people by adding speech recognition and comment on the resulting time savings
Overall grading comment: My intent is to design the milestones and grading system so that if you do everything I ask below, you get 90% (A-). If you do an impressive job, you get 100% (A). This assumes that my system is relatively objective, which it can't be by the nature of design, but I wanted to let you know the intent.
Everything is due on Monday by midnight Central Time, of the week listed. This timeline can be negotiated, and I'm happy to react if you turn in milestones early. The more you plan ahead, the better. The oral presentation date is determined by the Grad College deadlines for MS thesis oral presentations, which means it needs to happen by around Week 13.
Week 1 -
Week 2 - M1 Your Idea
Week 3 -
Week 4 -
Week 5 - M2 Understand the Problem
Week 6 -
Week 7 - M3 The Design
Week 8 -
Week 9 -
Week 10 - M4 Prototype
Week 11 -
Week 12 - M5 Evaluation
Week 13 - Oral Presentation (if graduating this semester)
Week 14 - You're usually done by now because of graduation deadlines.
Week 15 -
Decide on the user group and problem or need you will aim to address with your system. (This is just your hypothesis of a problem or need that exists, for now. You'll use M2 to investigate whether it really does exist or whether there's another more important problem in this space to focus on).
Create a working title for your system
Describe your users briefly (e.g. 50 words or less)
Explain how you expect you will have access to at least 6 members of this user population for interviews (M2) and concept testing (M5)
Describe your system idea in 100-300 words
Tell me what problem or need you're addressing
Tell me your strategy for addressing the problem. Make sure this includes;
what form will your system take: app? website? VR application? robot? smartwatch? etc
what high-level mechanics are involved: e.g. a LLM? chatbot? is it a two-sided marketplace? does it make use of gamification? etc
Describe yourself and your relationship to this problem (50 words or less)
Are you working for a company that does related work? What role do you play at that company?
Will you be working with a team? If so, what skills with other members be bringing?
What made you choose this project?
Include pictures or screenshots if appropriate.
I will comment and help you refine your idea.
You may want to rely on technology that does not exist yet. This is may be ok if you approve it with me. I'll say "yes" if the technology will likely exist in the reasonably near future. E.g. high-quality gesture recognition would be ok, but matter transporters, no. If I'm not sure, I'll ask you for evidence that this technology might exist one day, e.g. an article.
Here are several system examples:
NeighborMatch:
Problem: It's expensive and redundant for every household to own their own power tools, lawn mowers, camping equipment, etc -- especially for things that they don't use often. It could be useful for neighbors to be able to borrow these items from each other.
Strategy & Mechanics: An app and website that facilitates a two-sided marketplace of borrowers and lenders, so that those who want to borrow items can find people nearby who can lend them.
User group: People in suburban or urban neighborhoods
"Writers' Muse":
Problem: Fiction authors can feel stuck at times in generating creative ideas and scenes. They need help getting past this writer's block, and sparking creativity.
Strategy & Mechanics: A document editor application (designed primarily for desktop) where authors draft their story, and can also make use of a generative AI feature (built using a large-language model (LLM) that has been trained on a large corpus of fiction books) to help generate ideas for or an outline of a scene, chapter, or story. They would have to type a prompt to the generative AI feature, to get a response.
User group: Fiction authors (either professional writers or aspiring ones)
SnackBot:
Problem / need: Office workers at workplaces that offer free snacks may enjoy these snacks, but be too busy or forget to grab a snack some days. They might benefit from a system that makes getting snacks easier.
Strategy & Mechanics: A web app that allows employees to order snacks and drinks to be delivered to their desk by a snack robot. In addition, a system starts tracking (using facial recognition) what employees take themselves from the office snack shelf and drink cooler. The collected data is fed into an AI algorithm that learns employees' snacking habits, including the types of snacks they like to consume and the usual times that they get them. Once the algorithm has enough confidence, the snack robot will start to pick out snacks and deliver them to employees without them prompting.
User group: Office workers at workplaces that offer free snacks
Advice on scope: don't try to pack too much into your system. Identify just one user problem / need to solve for, rather than several. To ensure a great final capstone deliverable, depth is better than breadth (going deep on understanding one problem and designing a solution for it, rather than shallowly designing multiple features).
You get all 4 points if you do what I ask above. 5 points if you sound professional and your idea seems compelling.
The way for your idea to be compelling is not to try to sell me on your system idea (your submission should not sound like a sales pitch!), but to identify and clearly describe the problem you're addressing such that I can say "yes, I can see how that's a problem or need that exists" and "yes, I can see how there could be such a solution in this space" (and that doesn't rely on a far-fetched technology, and there aren't obvious constraints that would prevent it from being possible).
Understanding the users, their goals, and their challenges is key to designing a good system. This is not the time to brainstorm ideas for solutions, do mockups, etc. Resist those natural problem-solving urges; that comes later. First you have to understand your users and their tasks. You're doing user-centered design. You're looking and listening.
Find at least six (6) users and interview them in the spirit of contextual inquiry or ethnography. Make sure these users fit the criteria for your user group outlined in M1. For example, if your user group is environmentalists, confirm before interviewing them that they meet some minimum level of environmentalism that you define, e.g. they donate or spend a certain amount of time or effort on environmental causes. Further, make sure that they identify with the problem you are trying to solve. For instance, if you find a suburban homeowner willing to talk but they don’t see borrowing tools/items as a need they have, don’t interview them; continue searching to find someone who does. If you struggle to find people who identify with the problem you had in mind, this is a good signal to reframe the problem to something else. With each user you hit a ‘dead-end’ with, you can inquire about what pain points they have related to your topic, to get ideas of what problems resonate more that you could switch your focus to.
When you do find a user who fits your user group criteria and identifies with the problem you are trying to solve, interview them to understand their current behaviors (e.g. what if any systems have they tried or are they using now? what do they like or dislike about them? what are their biggest pain points?), tasks they are trying to accomplish, and needs and desires for better solutions, as it relates to your problem space. Explain to them what you're doing; you don't need to go undercover. If you and they feel comfortable, take pictures. Pictures are often most effective when they feature the person doing something, not just the person and not just the system they that work with, userless. Pictures of the artifacts that they interact with (tools, papers, desk) can be useful too, though.
Some people call this stage Establishing User Requirements or Functional Requirements. Requirements documents vary a lot between companies, however, please read this section carefully lest you fall into a default mode of doing what you're used to. This stage is about understanding the users' needs and the tasks they will want to accomplish. Thus this milestone is about users' requirements, but some "Requirements Documents" are more focused on the system than what I want here. This report should be focused on the users themselves and how the system might help them.
Based on your interview insights, note at least three (3) tasks that the users will want to accomplish with your system. If your system will be fitting into an existing work context, those tasks might be tasks they're already accomplishing, but with your system they'll do it a new way. E.g. for a cell-phone, tasks might be "call a phone number never called before" or "edit the name of a person stored in the phone." For a usage domain that doesn't exist yet, e.g. a system that allows home owners to water and monitor each other's garden plants, you'll need to talk about tasks they will want to do, e.g. "Get a view of the current plant status" or "Increase the water for a plant."
Note that even though you're talking to users, this data gathering is not subject to IRB requirements (Human Subjects permission) because of the policies on Capstone projects: https://compliance.iastate.edu/wp-content/uploads/sites/4/2023/03/IRB-oversight-student-projects.pdf.
Lastly, it is important for User Experience folks to display some product sense, to be aware of what is needed for a system to be feasible from a business perspective. So in addition to your User Requirements gathering, one of the sections below is about the business perspective, and may require some brief internet research to answer.
Write a report (submit a Word doc or some other format) that answers the following questions in approximately 1000-2000 words. You may draw on writing you did for M1. You don't need to use these questions as specific headers, but that may help your organization. The relative sizes of the sections can be inferred from the point values: the measures section is shorter than the rest. At the end, summarize what you've done by working with your users and how it will influence your designs.
USERS (5 points)
If the problem you’ve decided to address or your user group has shifted since your M1 submission, state the new user group and problem you’re addressing.
How did each of your 6 users describe the problem, in their own words? (This is our way of verifying that you did in fact talk to 6 real people who identified with the problem you are trying to solve, so we're looking for verbatim quotes here, [or close-to-verbatim if you didn't record the interview and just took notes].)
What is your understanding of why they care about this problem? What underlying needs do they have?
Besides the user group you will focus on, what other stakeholders are there for your system (both users, as well as non-users who are impacted by your system)?
TASKS (5 points)
What three tasks do your users want to complete?
What are the key steps of the tasks? (You might consider a narrative like a user scenario or a structured task analysis.)
What is the task environment where users will perform these tasks in the real world? In the car? In an elevator? Only sitting down, only standing up? In a hurry? (Mention physical environment as well as time constraints and culture if appropriate.)
Are there images that describe the tasks or environment well?
ANALYSIS (7 points)
What breakdowns occur while users perform their tasks currently (that your system will address)?
What do they see as their needs for better tools?
What system(s) are currently available to accomplish these tasks?
What are their strong and weak characteristics?
What functionality should your system include to accommodate users' tasks, but in a way that is differentiated (and better) than other alternatives?
Overall, what are the other design implications for your system, based on what you learned? (e.g. what aspects or details of your design will be most important to get right? Are there particular ways they should be designed? Or, what constraints will you need to consider?)
MEASURES (3 points)
Imagine that in the future, your system idea is actually built and being used by users. What measurable criteria would you want to use to evaluate the success of your system (e.g. number of users? usage metrics? self-reported satisfaction metrics, etc)?
BUSINESS PERSPECTIVE (2 points)
If built by a for-profit company, how would your system make money? What requirements does this add, to the design? (Paid apps, subscriptions, or ads are some ways to make money. Selling the data collected by your app could be another. There could also be other ways.)
What will be necessary for your system to be feasible, and how would you ensure this happens? (For instance, if your system idea depends on a certain stakeholder group to provide data or to agree to be part of it, how would you incentivize their participation?)
RESEARCH-BASED (3 points)
Use academic references where appropriate in the report (perhaps ones you read in the HCI core courses) to justify your approach and analysis and to demonstrate your ability to cite research as the basis of your decisions. Please use APA formatting for your references, e.g., The earth revolves around the sun (Galilei, 1613). A great guide to APA format is can be found at Purdue's OWL site.
If you do all that I ask above, you'll get at least 23 points. If you do it well, you'll get 25.
Now that you understand your users, it's time for brainstorming and iterative designing until you have the design you want to build and test. For your design, provide sketched and scanned or digitally created images of the interface at various stages during one or more of the tasks. This is not a working prototype. Smoke and mirrors is not the point right now. I just want enough information to convey the design architecture itself.
It will be helpful if you can brainstorm with someone.
Write a report or presentation with your design. A total of 25 points will be assigned to this portion of the project as detailed in the grading matrix below. The outline of your document should look something like this:
SUMMARY (2 points)
Brief summary of the system, its users' needs, and the tasks it will support. (Feel free to re-use content from before.)
REQUIREMENTS (2 points)
Functional Requirements (describe more formally than in M2). This is where you're telling us more specifically what the system must do. You can frame it from the user perspective, e.g. "The user must be able to: 1) .... 2) ...." or in the traditional "The system shall 1) and shall 2)..." We're not as concerned about the specific format, as long as it shows a more mature set of requirements that are driving your design.
DESIGN SPACE (2 points)
What design tradeoffs did you explore, e.g. "high quality vs. complexity" or "long battery life vs. mobility." There may be many tradeoffs; describe at least the 2-3 primary ones.
What are the harder requirements to support? Why?
THE DESIGN (10 points)
Describe the design itself, with justification for your design decisions throughout based on user feedback and references.
Give an overview, in which you categorize your design vision in terms of where it fell in your tradeoffs and why, e.g. "This design offers high quality but requires heavy cognitive load. This decision was based on user feedback on... "
Include the sketched and scanned or digitally created images of the interface at various stages during one or more of the tasks here.
Give at least one usage scenario written from the user's perspective that includes several tasks. This helps you avoid a presentation that's just "Here's my screens!" and instead tells a story of how a real user will use them.
FUTURE TECHNOLOGIES & SOCIAL IMPLICATIONS (6 points)
Comment on the ways that emerging technologies affect or inspire your design. This is the part of the course where you demonstrate your knowledge of emerging technologies and HCI-related technologies, e.g. that you might have learned about from Alex Stoytchev or Tony Townsend (approximately 1 page).
Discuss any ethical issues that may arise from your design, as well as the social implications of your design if it were successful (approximately 1 page). E.g. with smart phones, some people worry about members of families not communicating as well at family dinners because they're distracted, or you could talk about txt-msging undermining political regimes. If you were designing software for sending instant videos across the network, you could worry about the privacy of people in public who might get filmed.
RESEARCH-BASED (3 points)
Use academic references where appropriate in the report (perhaps ones you read in the HCI core courses) to justify your approach and analysis and to demonstrate your ability to cite research as the basis of your decisions.
Create a digital prototype of your design that can be tested with your users, e.g. in Figma, html, Flash, or PowerPoint. In M5, you'll be showing this prototype to five (5) users. The prototype needs to show how at least one task would be done in your system, end-to-end.
Prototyping
Remember that the feedback you get from people depends enormously on the degree of polish of what you show them. If you show a beautiful graphic website/app, you might hear, "Well, I don't really like the color scheme." But if your prototype is a simplified digital interface, people will realize you're still in the early stages and give much more useful feedback, e.g., "I'm not sure what that button does!" You want communicative but unrefined images.
When prototyping, remember that they key is developing the interface, not the back-end functionality. You can use a "Wizard of Oz" approach during testing to simulate how the system would respond.
Create a document or website or video, etc (anything digital) presenting your prototype.
Make sure you document:
Your prototyping strategy - 3 points
what level of fidelity did you go with? Why?
Justify your approach by citing at least 1 academic literature source
Description of prototype (include images if appropriate) - 10 points
Its features and screens
The tasks it supports (presumably the tasks you've mentioned above)
The tasks / features it doesn't support, and why that's ok (just mention briefly)
Reflection - 2 points
Reflect on the prototyping process: what was the hardest part of this milestone? What, if anything, would you do differently when prototyping for a future system design project?
What did you learn about your design, and about prototyping generally?
Write about a page.
There are many ways to conduct evaluation, ranging from concept testing to usability testing to heuristic review to focus groups. Each method has its pros and cons. Think about what makes the most sense, for your project.
The point of the evaluation, however, should be to understand what's working about your design, and what changes are needed to make it better. And, as this is your first round of evaluation on the design, it's important that you don't just focus on how usable your design is, but also how useful: do users see it as a good solution to the problem you are trying to address? Why or why not? (Improving the usability of a system that users aren't going to use would be a futile effort!)
Test with at least 5 users. The users should meet the same minimum criteria you established in M2 to ensure they were part of your target user group (e.g. environmentalists). They ideally should also strongly identify with the problem you are trying to solve, though for this milestone it’s fine if some don’t identify with it as strongly (e.g. suburban homeowners who care a bit about borrowing tools, though it isn’t a huge need). You may recruit the same users you talked to during M2 for the evaluation if you wish. This is helpful, as they will already have context about the problem space you are aiming to address, and can give good detailed feedback about your solution.
During the test session
When you meet the user, explain what you're doing. Explain that you're testing the interface, not him or her. If there's confusion, it's bad design, not the user's fault. Remember that it can be intimidating to be a participant in a user study, so be extra nice. The user will be trying to please you, which could distort your data (i.e., prevent you from hearing critical feedback). Therefore, be very open and receptive to anything and everything the user may say or do in order to gain trust.
Present the system to the user and give a brief overview. Do not show how to do the tasks, but give a general idea of the system to set some context. "This is an interface for a robotic lawn mower. You would see this touch screen inside your house and use it to control the mowing of your lawn. This image shows your lawn currently, and this map shows the position of your mower."
After the introduction, stop to get their initial impressions of the system (in terms of the high-level solution, not the aesthetics or design details!). Ask for elaboration to understand if their sentiment is positive/negative/neutral, and why. Then, introduce the first task scenario and show the starting point in the prototype for that scenario. ("Let's say you are going to be on vacation, and want to set the lawnmower to mow your yard while you are gone.") Ask them to describe what they see on the screen and what they would do next. Advance the prototype through the steps for that task, to respond as the real system would (you might use a Wizard of Oz technique to simulate the system's behavior). Also take notes, describing why and when the user made comments like, "This is cool!" and "What in the world is that?"
After all your task scenarios, interview the user to get their overall feedback. Before asking these questions, make sure they no longer have any confusion about what your concept is or how it works - you might have to explain how it is intended to work, if it was still unclear. This will allow you to understand whether your solution, once understood, is a good one (you can always improve the clarity of how it is communicated). Ask questions such as:
* Now that you have seen the full concept for this system, how compelling is it to you? (Follow-up: explain why it is compelling or not compelling)
* How would you describe this to a friend or family member?
* How well do you feel the system solves the problem of <problem you are aiming to address>? Why?
* How would this concept improve (and/or not improve) the experience of [activity related to concept]?
* How would you use this concept in your daily life?
* What stands out to you as great about this concept?
* What stands out to you as concerning about this concept?
* What parts, if any, were confusing?
* If the system was built and ready to use, how eager would you be to use it? Why?
* What changes would you make, to make the system more useful for you?
For data gathering, it will be most valuable if you present users with the exact same tasks and exact same prototype. Even if user #1 gets really dislikes some aspect of your system, resist the urge to change it before user #2, because you don't know whether the other users will have the same feedback. Don't change things unless the issue significantly disrupted the evaluation process or prevented you from getting important feedback on some other aspect of the system.
Think about privacy: assign your users fake IDs to use in your write up to protect their identity. Ask for their consent to take pictures and if you want to post any identifying photos of them on your website.
Report
Write a document presenting your method and results. Email it to me as a PDF. Aim for approximately 10 pages.
The outline of your document should look something like this:
Brief summary of the system, its users, and the tasks it will support. (Feel free to re-use content from before.)
Evaluation Details
Your users (demographics, background, etc) - work with at least 5 users
The task scenarios you gave to users
Your interview questions
Your testing environment (At a bookstore café? At the user's home?)
Results: Present your data
No need to discuss the data here; that's the next section
Be sure to include how many users, some data from each user
For qualitative data: Include quotes and a summary of any overarching themes. Also summarize what was learned in terms of concept feedback and usability issues. Categorize usability issues this way:
Severe; must fix
Major problem
Minor problem
Cosmetic problem (more related to prototype itself than system)
New feature request
For any quantitative data, give raw data since stats like average don't make sense with a small sample size, e.g. "3 of 6 users said..." or a chart showing a bar for each of 6 users with their ratings.
Discussion
What do you conclude based on your data? What do the data mean?
Was anything surprising?
What are the main implications for your design?
Reflect on your evaluation process: what was the hardest part of this milestone? What would you do differently when doing concept testing for a future system design project?
Grading for M5 - Evaluation Report
Summary: 2 points
Evaluation: 6 points
Results: 6 points
Discussion: 6 points
TOTAL: 20 points
This presentation will serve as your MS Oral Defense, and will be done in front of your committee.
If you are not graduating this semester, then you should prepare your presentation now, using the details below, but you will not present it to a committee until the semester that you are graduating.
Your Challenge: Design Pitch
Imagine that you are a designer within a large company like GE or IBM. You were given initial funding to do your work so far, and the R&D managers want to know which designers should continue in the product development process. Your goal is to convince the managers (your committee members) that you are a competent designer and deserve to continue refining your design.
This is not about a business plan. This is about convincing others that you're a thoughtful, creative designer who can draw on research in the HCI field to justify your design decisions.
You need to present your problem, your final design solution, show your prototype, and report what users said about it. Along the way, try to convey that:
* You thought about the design space appropriately
* Your approach is user-centered
Note that if you had negative user feedback, that’s ok. That’s normal in design. You want to appear as a competent designer that listens to users and will react appropriately to the feedback.
Your Presentation
You'll be given 30 minutes to answer this challenge, and 30 minutes for questions. Use slides (e.g., PowerPoint, Keynote, Prezi, etc.).
Your presentation should contain either the same information you turned in previously for earlier milestones or a summary of it. It should clearly delineate (perhaps in separate pages):
The design problem and target users
Your approach to the solution (approach is not the same as the solution; it's more your strategy and technique for the solution, e.g. focusing on a particular set of tradeoffs or using certain assumptions to narrow your design space)
Your actual solution (the mockup)
Your user feedback / evaluation data. Include:
Your methods of gathering the data
The results
Your reaction to the results, e.g. how you would change the design and reflections on your own design process
Where you can, in the presentation, drop a name or two of academic references. Obviously this would be infrequent in a more business-oriented presentation, but it can add credence to your work when you show that you know the experts. E.g., when you mention why you chose a low-fidelity prototype or your approach to evaluation, you could cite someone about why that was an appropriate choice.
Tips
Frog Design’s Product Cases
Frog Design has great examples of design briefs on their website portfolio. Almost every link on this page presents a problem and Frog Design’s solution in a succinct case.
How to Give a Pitch (YouTube)
Note that these links are about venture capitalist pitches, which are not the same as an internal design pitch, because they include more detail on the market place, competitors, financials, etc. But the spirit of these presentations is similar: they should be fast, direct, with not many slides.
Making your pitch Business Week reporting of Columbia Business School's entrepreneurship competition
Elevator pitch tips from Sean Wise, aka the Mentor Capitalist and author of Wise Words
Ryan Blair listens to an elevator pitch given by CEO of Nerdstogo.com
What the committee will be looking for:
Presentation was within 30-minute time limit
Design problem (1), solution (2), mockup (1) and user feedback (2) were clearly articulated in presentation
Response to R&D panel questions demonstrated the depth and breath of your knowledge of the design challenge and solution
Iowa State's Grad College requires that you convert your milestone docs into one large doc with a special title page from the Grad College. You then turn that in to the digital repository in the ISU Library. See details here about how to do this: https://www.grad-college.iastate.edu/masters-nonthesis-requirements
If you are seeking an industry role after graduation and have a personal portfolio website, we highly encourage you to put your capstone project on your portfolio site, as well.
Here's a reminder of how to interact appropriately with users / informants when you're doing your capstone. Because this is a class project, you don't need IRB approval as you would for a study that you'll publish, but you do need to do the following, per the IRB policies page (see the bottom of this page: http://www.compliance.iastate.edu/irb/policies/university.html):
You identify yourself as an ISU student who is performing the activity to fulfill a course requirement, and the course is specifically identified.
You give my name, the supervising faculty member to contact for questions is provided.
You name the persons who have access to the individual data and/or summarized results are specified, if any (e.g., instructor only, company/organization/agency).
Participants are informed that their participation is completely voluntary, that they can skip any questions they do not wish to answer, and that they can stop answering questions at any time.