Due Dates: Various, in phases
Points: Design Review: 60pts; Prototype Deliverable: 150 pts
Rules: Teams of three (preferably based on Proj0 teams)

Overview: Now that we have some basic idea of User Centered Design and Evaluation, it's time to flesh them out, combine them with some programming skills, and apply them in a realistic design effort. Our particular focus in this assignment will be to use the user and task analysis skills we are gaining to develop an initial design of a relatively small application; you will then develop a working prototype. This is the application that you will do usability testing on for your final project. So, in some sense, you will be graded twice on it:

• Part 1 (this project): Design and Prototype. All the design, including early user involvement and testing, up through the alpha prototype presentation. In case you're unclear on what an alpha prototype means, it translates roughly to all elements in the project work well and are bug-free enough to user test effectively and meaningfully. This means that you might have simple non-pretty versions of buttons, icons, colors, etc., but all layout/sizes/functions/controls are there and reflect final look and feel accurately.
• Part 2 (The final class project, upcoming, detailed specs at that time): Test and Refine. The final deliverable is a beta-grade product, well-refined through usability testing. You will report extensively on the user-testing and the results/improvements that it led to.

My point is that doing a nice thorough job on this initial stage (Part 1) will pay big dividends when you need something solid to test/refine!

The Scenario:

You are working for a small but aggressive software engineering firm, Ohmigod Zenmaster Inc. (OZ), that is starting up with venture capital. OZ has based its business plan (and won its startup capital) on it's expertise in developing highly usable, specialized cloud technologies (mobile and web applications) for niche markets...an area that is exploding these days. What business area or market does NOT want its own mobile app these days?!

Your team has been tasked with developing one of OZ's most promising new concepts, namely, a cloud-based system for streamlining nightlife around the whole world. It uses a very standard service-based business model: Create a concept that users around the

Preliminary analysis by OZ's market research gurus shows that there is fabulous niche market opportunity for a ZenGo app in the area of large scale beverage service. The number of beverage service venues has exploded in recent years, ranging from bars to street fests to large sporting events. This has not only led to incredible growth in the market, but has also increased competition between venues like crazy; only venues that offer truly easy and modern service will survive. And this is where OZ thinks it can help, leveraging the idea that anyone who someone has a smartphone these days...

A main hassle in any venue larger than your sleepy local pub is just getting your drinks. Depending on the exact venue, you either have to hang out at your table until you can get the attention of an overworked server to place your order...then wait forever to get your drinks...all the while not knowing if your server forgot you, brought the drinks to the wrong table, or what. Or you go to the bar/drink booth yourself, and stand in some mad press of people trying to make it up to the counter to order; then you place your order, pay, and sort of hang out trying to see when your order comes out. Chaos! It's bad on the other side of the counter too: Servers have to visit tables multiple times (take order, bring it, stop and ask if more drinks needed), there are continual errors in noting down the right drinks and getting them to the right place, and even at the bar itself, there is all this inefficiency as people come up, order, struggle with cash and credit cards, and wait around for drinks.

The idea behind Thirstbuster is straightforward: let's streamline this whole process and make it a more relaxed, efficient and profitable outing for everyone. Basically, the idea is to build a smartphone app that users download, and connect to an account that they've set up on Thirstbuster. When they go out and visit venues that are "Thirstbuster enabled", they can use the app to totally streamline the whole process of getting drinks, monitoring their tab, and paying up. More specifically, the concept has two main pieces:

• Venue Owners can visit the Thirstbuster website, where they can register their business: They put in the basic info for their venue (name, location, description, link to their website, and maybe opening and closing times and dates). This also creates them an account where their money collects; Thirstbuster handles all the money collection and disbursement. [Note: In real life, one would surely outsource this whole banking mess by connecting with credit card providers, Paypal, etc. We just want to keep it simple for our purposes here, to allow us to focus on better (GUI design) things]. They also have to specify how drink service works at their venue: counter self-serve (drinkers come get their own drinks) at the bar, table-service (somebody brings drinks to a table), or both. Venues owners also must enter (and can maintain) their beverage menu, i.e., the drinks that can be ordered, guided by your beautiful UI that makes this easy and organizes drinks for efficient browse/access by all. Once the venue is registered, they get access to a cloud-enabled web app where they can run the show at their venue, taking and processing drink orders in delightfully efficient fashion.
• App users can download the client-side app from whatever app store. When it launches, they are forced to put in minimal info: at least their name...plus make the all-important connection of the app to their paypal or visa. Then they're ready to go out on the town! In a real implementation, the app would probably launch and show a map of the Thirstbuster-enabled venues around the user. We will keep it simple and focus on the purchase transactions: the app will open as if the user is "in" a particular bar that is already registered as a Thirstbuster venue, and action will commence from that point.
• There is a super simple "table service app" which is separate (or as hidden mode in main app), and is used by servers at establishments. It is ultra-simple: just notifies servers when there are orders to pick up and deliver; and provides a way for customers to acknowledge order receipt, see below.

A hot night on the town: how Thirstbuster works in action
There are many small design details that you, the design team, will need to analyse and creatively resolve as part of your design process. But the basic idea goes like this:

1. Customers enter the venue and get situated (at at table, at their sporting arena seat, out on the lawn, whatever).
2. If it's a venue that offers table-service, assume that customers pick up "a number" on the way in the door, e.g., one of those numbers on a stand they give you to put on your table after ordering pizza up at the counter, so the server knows where to bring it. So for table-service scenario, it asks you to enter that number; for self-serve, it's irrellevant where you're sitting. If the establishment offers both table-service and self-serve, you can put in a table number OR specify "none, self-serve".
3. The users can efficiently browse the drinks menu the current establishment in the app and order their drinks. This starts a tab for them in the system. Drink orders can be edited freely, and then are submitted at some point, at which time they appear on the barperson's Thirstbuster screen. All through the process, the users can view their order and see its status: "Received" "Being filled" "Ready for pickup/delivery (depending on mode)", "headed your way", and "Completed". In fact, they can see the progress info for every drink within the order as it is processed and then completed.
4. The barperson uses the web app GUI to work on and fill the orders: As each drink is tackled, the barperson first marks it as "in progress" (he/she has started working on it), then checks it off as it is completed and placed on a tray for delivery. To keep it simple, assume that trays have automatic markers (rfid, near-field chips, an LED display, whatever) so that drink orders can be kept apart and immediately identified by servers/customers arriving to pick them up, i.e., you don't have to solve this thorny problem. Clients can literally watch their orders being filled on their apps as the barman checks off the drink items. They can also edit their order at any time: any drink that is not yet "in progress" can be canceled...and one can add drinks any time before the order picked up (either by server or customer, depending on mode); after that, you'd have to place a new order.
5. When the order is complete, its status changes to "ready for pickup". In self-serve mode, this would ping the customer to come get their order at the bar pickup area; in table-service mode this notifies the servers via the server app.
6. Orders are either picked up by customers (self-serve mode) or delivered by servers (table-service); in the latter case, the order enters the "coming your way" status when the server grabs it at the bar.
7. You must invent and implement a simple, fast, but secure way to acknowledge receipt of an order by the customer. This is critical! You don't want servers delivering drink orders to the wrong people/table...while the app charges the person who actually ordered it! Similarly, you don't want customers receiving their drink orders...and then later claiming they never got the drinks. You need to think of a clever way to handle this...it has to be secure (if the class can think of a way to trick it, you're in trouble!) yet also very fast.
8. The second that receipt of a delivered drink order is acknowledged by the customer, their payment is charged to their payment method (that they registered with Thirstbuster to start off), the order status is paid, the amount shows up in the merchants Thirstbuster account, and life goes on. This prevents anyone from ever walking out on an open tab (!!), and customers love it because they can just leave any time.

Some other cool features could include:

• Clients can track their tab at an establishment over time somehow...for that evening, for that month, whatever clients need. For instance, this might be useful when you're trying to figure out what your buddies owe you at the end of the night! Maybe the client side even allows marking drinks (with icon, whatever) in orders to help users track whose drink it was...it's up to you to be creative and study your users carefully. A clever design would probably allow clients to set a preference on how long to keep histories.
• Both client's mobile app and the venue owners web app should provide some reporting functions of interest to that particular end-user. For the client maybe: total spent (night/month/etc) across all establishments visited, breakdown of drinks, whatever else you discover that users want. For owners, maybe sales stats on all drinks, money inflow across nights/weeks/month, and stats on timing of order fulfillment (e.g., you can see that there's a big gap between orders being ready and them getting picked up by servers for delivery...so you can crack the whip on your lazy servers, or hire more servers, whatever). You get the picture: provide some nice value-added for all sides.

That should give you the basic framework. In the end, it's up to you as product/GUI designers to create a elegant, feature-rich, and highly usable products! In the real world, your work would be evaluated by the famous "sink or swim" method: you get one shot to impress users (and reviewers, MacWorld, whatever), and if you blow it, you're applying for food stamps. In the classroom setting, we need to have some framework for thinking about grading and evaluation, so I've created this table to provide a rough outline of functionality expected. It includes a number of feature ideas, but ultimately your user studies could show the need for different features and you could substitute them...so it's a guideline, not prescriptive. When you submit your product for review, you'll print out this table, annotate it to reflect what features your app actually includes, and turn it in with your deliverable.

The Assignment:

This project will be done with loosely coupled pairs of teams. In each pair, one team will do the mobile app(s), and one team will do the web-app. The reason it is "loosely coupled" is that there is no absolute dependence between the two; it is ultimately each team's job to provide at least a basic test harness for their product. This means that a mobile app team must have some test harness to talk to their app and simulate the web-app side; and a web-app team must have some test harness to simulate the mobile app side for testing purposes. All I'm saying here is: the very easiest and coolest way to meet this need is for your test harness to be the web/mobile app of your partnering team; then you can gang up for later user testing too. But in the end, it's your call; I never want to hear the excuse "Our app can't be demo'd because our partner team flaked out". Cover all your bases! Note that grading for the two loosely-coupled subteams is completely separate: separate deliverables, separate presentations, etc.

Mobile App implementation: A mobile app team can choose any available mobile platform to implement on, i.e., Android or iPhone. I will say that Andoid is more accessible and widespread and is therefore my official recommendation...but I don't want to cramp your team's style. This is about GUI and functionality, after all. Note that a mobile app team is responsible for both the Thirstbuster-customer app, and the simple little Thirstbuster-server app we mentioned. See the functionality outline for detail...

Web-App implementation: Similarly, web-app teams can use any frameworks they like to implement the web app side, so long as it runs in all major browsers. Frankly, I don't even care if you choose to implement the barperson's interface as a desktop application, if that's your forté. Again, the point is to create highly usable interface...who cares what's behind the scenes. Note that a web-app team is responsible for providing a main "business registration" web page, that establishes and configures a business, and for the barpersons interface that does all the daily work. See the functionality outline for detail...

The end user groups are different between the two (barpersons vs. customers) with very different goals/needs, so consistency across the interfaces is not a big issue...although you might want to coordinate on some colors, icons, etc. But of course the two teams will have to coordinate on how to share drink menu (suggestion: JSON file shared on the server) and on the message passing between web app and mobile app.

The functionality outline gives some more detailed scoring guidelines, but my basic expectations are that systems that are complete and robust but clunky/ugly/spartan represent the C and low B range. Grades go up from there with refinement, well-thought-out features, and effective use of usability techniques to create elegant and pretty interfaces.

Phases for Part1 of the BIG PROJECT:
There will be several phases associated with this project:

• Project formation (due Wednesday March 9, by email). Deliverable: Email to me from some person in your two-team group, with all others in your two teams in CC, declaring your grouping. Specifically, I want: The name that you are choosing for your overall Thirstbuster product; (2) The team that is doing WebApp half, including (old) Team name, members, and initial thoughts on implementation approach/frameworks; (3) The team that is doing Mobile App half, including (old) Team name, members, and implementation platform. Plus a specific designation of contact person (with email) for each subteam.
• Design Review: (due 4/1; 60pts) To document and present your user studies and resulting insights and design implications. Consists of a clean, concise writtten report.
• Prototype Deliverable: (due 4/18, 150pts total) This is the final delivery of your alpha prototype. Consists of a tight 7-minute "elevator talk" presentation of your prototype to the class, a written document, and a private demo session in Dr. D's office.

Some notes:

1. IMPORTANT: You MUST use Github to organize your codebase within your team! This is a project requirement, and will (a) teach you a valuable team development tool and (b) allow me to easily review your code at the end...while saving a lot of trees and ink. If you haven't used distributed version control, you're in for an awesome treat.
2. Although this is a futuristic application, it is "near future" and is chosen to be something that everyone living in the modern world can relate to. Thus, a huge group of potential users or them exists at NAU and in the surrounding community. This means that you should have no shortage of knowlegeable (or at least opinionated) "users" to survey, interview, and otherwise analyze in your design process.