Front Page

Team Fresh City


This is the website for Team Fresh City, part of the HFID class in Fall 2009.


Needs Analysis

Information Gathering
User Goals
Concept Model

Inspirational Designs

Inspirational Designs
Google Docs

Design Development

User Script
Design Process
Usability Report

Design Refinement

Cognitive Walkthrough
Design Refinement Presentation
Design Refinement

Usability Testing

Usability Testing

Final Refinement

Final Prototype Refinement
Generation 2 Prototype
Usability Testing
Final Prototype (Generation 3)
Final Presentation
Final Report

Division of Labor

Division of Labor


01 Dec - 31 Dec 2009



Powered by Pivot - 1.40.7: 'Dreadwind' 
XML: RSS Feed 
XML: Atom Feed 

« Design Refinement Pre… | Home | Usability Testing »

Design Refinement

11 11 09 - 19:17 In this phase, the team further developed the paper prototype and implemented the interface in a high-fidelity prototype.

Final Mock-Up and Cognitive Walkthrough

Refining Paper Prototype

The team spent a significant amount of time during this phase working through the cognitive walkthrough, determining what goals and tasks were associated with our program. The goal of Tradmin is to centralize and facilitate communication associated with paper collaboration. At the beginning of this phase, we reflected on our third prototype. The third prototype had the ability to add comments, send notification messages, keep a buddy list, and add thoughts to a message board. As reported in our Usability Report Conclusions, there was some confusion with the language used to describe the general comments log and editing features. The team also felt that to meet Tradmin’s goals we needed to make sure features were available to fulfill every need. We decided to transform the “notify dialog” into a “private message space” similar to an e-mail client. This is because we realized that our users tend to exchange versions of a paper via email, and put their over-arching thoughts in the email text (which disconnects the paper from the collaborator thoughts). We changed the “general comments” box to a “discussion board” similar to a chatroom discussion or Facebook wall. This makes it clear who is thinking about what and clearly shows where remarks about the project overall can be made.

Prototype 3 vs. Final Mockup


With a revised design, we conducted a complete cognitive walkthrough, identifying the tasks and actions our users would take, in order to determine what functionality needed to be corrected. Tradmin is an add-on for word processors, so the main control allows the user to activate the program. We’ve created it as an add-on because our users are not interested in learning a new word processor. The buddy list allows the user to add and remove collaborators who are sharing the document, an easy way to see who is shared in the document. The comments pane allows the user to add comments about the paper, respond to comments, and delete comments. The discussion board facilitates discussion between collaborators in a public space. The private message space allows the user to send thoughts or requests to a smaller audience. A more detailed description of these spaces is given in Cognitive Walkthrough Prototype Description.

We identified the tasks that the user would need to conduct to meet the goals of the interface:

  1. Getting Started- The user must be able to get to the program to begin work.
  2. Adding and removing collaborators- The program is interested in sharing work between people. This task is integral to the overall goal of the program.
  3. Handling comments (adding, reading, deleting, and responding to them)- our interface deals with the commenting part of the revisioning process. These capabilities enhance the user’s ability to revise their paper.
  4. Sending private messages to collaborators- In case the user has questions or thoughts for individuals within the project, they have the opportunity to message them instead of involving the entire group.
  5. Posting messages to the discussion-This is where the group can leave general thoughts for all individuals about the paper. It is a quick way to involve everyone in the paper.
  6. Sending email notifications- The user can copy a private message to an external email address in case individuals do not check the program frequently.
  7. Continuing the project (or re-entering)- In the revisioning process, this program is used multiple times. The user must be able to re-enter Tradmin with an understanding of what has changed since the last visit.
We also identified a few tasks that Tradmin would need to address in order to meet our user’s needs, but were too big for the scope of this phase. We believe they are important issues, but too big to complete in the scope of this class:
  1. Any edits written directly into the paper will not be tracked or logged. There are many ways to address this need but finding a balance between technology and user values is a complex problem. Microsoft track changes is currently disabled while in a Tradmin project.
  2. Private comments and edits that only you can see- A personal user in the program might want to keep track of what they are doing privately, but Tradmin is set up to be a public space. We haven’t figured out how to balance what you can see and what you can’t because the program is supposed to be real-time.
  3. The option to send some external emails and not everybody- this one is a minor issue, but our current private message set up doesn’t allow for external emails being sent to more than one person/entire group. It’s not a big issue for the program, though we acknowledge this would need to be dealt with in order to keep users from sending emails from their web client that would remove them from Tradmin.


We identified the actions associated with the 7 major tasks we chose to develop, and were able to use our cognitive walk through to correct any functionality issues. We determined that our tasks needed placeholder text or writing fields to indicate where a user should click to type/respond to comments or messages in the discussion. We also determined that comments have a lot of visual cues which are important: the boxes expand when clicked upon (the user doesn’t know the richness of the comment box until clicking upon it), there should be a line from the comment to the part of the paper being addressed, and there should be a way to exit the comment to gain focus on other parts of the screen again. Looking at the right-hand side of the pane, we developed more richness with the private messages section, giving the user the option to send an “external e-mail notification” to get collaborators who aren’t big on technology (or forgot about the paper) to check the project. Our complete cognitive walkthrough, with pictures engaging with the mock up, is available here.

Implementing a High Fidelity Prototype

The tool

Our final interface was implemented into Microsoft Expression Blend. It is a Silverlight based application that allows designers to create a fully functional prototype. We chose this tool because we needed something that could take input data from text fields and convert it into objects that appear on a canvas. We needed a tool that did not require too much programming. At first pass, Microsoft Expression Blend, appeared to satisfy these requirements. Unfortunately, we found that the program requires quite a lot of programming in C# to accomplish the tasks we wanted to represent. As a result, the programmers on the team sunk time in learning the commands to turn code into action. In hindsight, choosing a tool such as pygame, where 3 team members could have developed the prototype, would maybe have been a better choice. However, we were able to implement most of the functionality of the interface. We are missing visual cues in our interface right now, which we plan to build into our final prototype to facilitate “recognition rather than recall”.

The User Manual and Prototype

We proceeded to develop a high-fidelity prototype of Tradmin in Expression Blend. Click to view: High Fidelity Prototype.

Following the development of the high-fidelity prototype, we had an external design review team conduct a heuristic evaluation of our interface. The Heuristic Evaluation includes a description of our product, the type of users, and a list of major tasks we did not cover (copied from our cognitive walk-through). The instructions can be found here.

In the Heuristic Evaluation we had the users walk through the tasks we identified in the cognitive walk-through. Below are those tasks, and a storyboard of the actions one would take to complete it. The red boxes are to indicate where mouse-clicking occurs. Due to some imaging quality issues, the resolution is rather large. Please scroll your browser to the left to view the images completely.

1.    Getting Started: You are currently in Microsoft Word, with your paper open.  Enable the Tradmin function.

The user clicks on “tradmin” in the MS Word ribbon, which then displays an “Enable Tradmin” button. Clicking the button allows the document to become a Tradmin project and all the frames are displayed.

2.    Collaborators: Add yourself and three collaborators to the paper:
    Tom, email:
    Dan, email:
    Rachel, email:
    Laura, email:
Remove Laura from the collaborator list.

Here, we added “Joe College” by clicking on Add Collaborator, typing in the name and email address, and hitting submit. The collaborator now appears in the buddy list region. Also, this name would then appear as a contact when sending e-mails (though this functionality has not been implemented yet). Each color of a collaborator is used in the comments and discussion, so that the user can quickly identify who has been working on what.


3.    Comment: Add an initial comment to the paper.  Indicate that you want to come up with a better title.

  In our current interface, the user highlights the text in the document, and then clicks on the Comments pane. A comment box appears, with a line indicating the region of text being pointed at. The user types in a comment in the text field and hits send. In the future we would like the text to continue to be highlighted and connected to the comment box, but this was difficult to implement in Microsoft Expression Blend.


Click on the big red button at the top right hand corner.  This will fast forward you in time 5 days…

4.    Comment: Scroll through the comments on the paper.  You want to respond to Dan’s comment about the introduction.  Comment on this comment; tell him that you are unsure about his comment. 
Rachel has brought up a good point about the second sentence in the third paragraph, it’s redundant.  Delete this sentence, and her comment.


To respond to a comment simply click in the text field that accompanies an expanded comment, type the thought, and click send. In our paper mock-up, we showed that the user’s response would appear in their color, to differentiate comments. We want to implement that in the next prototype. To delete a comment click the “x” in the corner and it will disappear.

Also, we want a way to expand comments so that their emphasis exists when clicked on, but they are not the same size all the time (the pane gets cluttered). We have not figured out how to do that in Expression yet.

5.    Post to Discussion Board: Tell everyone that you like the overall layout of the paper, but the sections aren’t tied well enough to the paper. 


By clicking in the text field in the discussion, typing a message, and hitting submit, the user can post to a public message board. One bug here is that the name shown defaults to the first user in the buddy list. In a fully working prototype, the first person in the buddy list will be the main user, but we want the system to know that, and not prompt the user to add him/herself as a collaborator.


6.    Open.  Open the unread private message.

The user clicks on the message in the Inbox and it pops up. Hitting “close” will close the message. There are no visual cues in place right now to show it is a new message or clickable –something we desire in the next prototype. Also, “Reply” has empty functionality right now, but we hope to have a window that would appear to respond to that message.


7.    Send private message: Send a private message to Dan.  Ask if his if he thinks his top secret research from Italy could be relevant for this paper too.
Send a private message to Rachel, but copy it to her email.  She only checks the Tradmin file once a week.

  To send a private message, the user clicks on new message. A window appears where the user can write in a collaborator’s name, fill out the message window, choose to send the message to the recipient’s actual email client in addition to saving it in the Tradmin project, and then clicks send to complete the task.


8.    Hide: Hide the Tradmin interface; you want to just see the plain paper.   

The user can remove or see the panel items by toggling “Show/Hide Tradmin”. To ensure that the user still is aware of being connected to a Tradmin Project we plan to have a light indicator at the bottom of the screen to show the user is connected (currently not implemented).


Heuristic Evaluation

Members of the class completed a heuristic evaluation of our project. We’ve attached it for viewing here: fresh city heuristic evaluation. The other team’s biggest concerns were about things we were unable to enable in our high-fidelity prototype, but had noted we wanted in our cognitive walk-through: auto-complete, drop-down menus, having the sent private message appear in the inbox, and giving visual cues for completing tasks. We also noted that we need more undo functionality. The most view-shifting feedback we received had to do with the lay-out of our screen. Ellen suggested we have comments on the right hand side of the screen because people read from left-to-right, and move the messaging system to the left side. We believe these suggestions make a lot of sense, and hope to implement more visual cues and change the frame lay out in the next iteration of this prototype.


In addition the team put together a presentation for the class providing an overview of our design process and the developed interface. We gave our presentation in terms of the design lessons we have learned thus far:

  1.  It was prudent to narrow project scope and do it early
  2.  Revisions on the go were definitely successful
  3.  Focusing and revising the design based on user needs

Task Breakdown

You can find the task breakdown for this phase here. This phase the work began to be split between team members. We initially had planned to have 3 people working on the interface but when we discovered our tool required C#,the team split in half: two on coding, two on presentation and further design refinement.