Design
The final design of our interface comprises four tabs and one pop-up. Our interface diverges dramatically from our original paper prototypes. We made many design decisions that we felt would contribute to learnability, simplicity, and efficiency.
...
Severity | Description of Problem | Possible Solutions |
|---|---|---|
Major | Batch Removal of Midnights from Watch List. The user found that there was no support for removing more than one midnight at a time from the watch list at a time. | Use checkboxes instead of 'x's. Then have a "clear all" button at the bottom. |
Major | No Log Out. The user wished to, but couldn't figure out how to, log out. | Include a logout button that will log the user out. |
Minor | Quotes Page Aesthetics. The user felt that the quotes page was very information-dense, and suggested color coding bids and asks. | Color code bids and asks. |
Good | *Very Nice. *The The user felt that the interface was very nice. | None. |
Major | Confusion Over Buy/Sell. Despite verbal guidance, the user was still confused by the bid/ask terminology. This happened to two users. | This is a problem we have been trying to deal with ever since the beginning. We don't have a solution yest, other than some sort of help section. It should be a one-time problem for any user, though. |
Major | *Unintuitive Enter Press. *The user pressed the enter key to complete a bid, but instead, the bid was cancelled. We were able to replicate this event, though not with a 100% success rate. | Something fishy going on in the back-end. Need to explicitly say what happens when the enter key is pressed. |
Major | Button Relocation. Sometimes the buttons on the bid ticket pop-up would appear outside of the boundaries of the pop-up. The user was able to realize this and complete the task, but still remarked upon it. | The way we chose to change the content of the pop-up led to this error. While the buttons could move down, they didn't move back up. We need to fix the back-end to compensate. |
Minor | Text Field Relocation. In certain windows, the text box for entering prices on the bid ticket pop-up would appear on the next line, confusing the user. | Increase the bid ticket size. |
Minor | Watch List Ordering. The user noticed that after deleting an item from the watch list, the order of the items in the watch list would change. | We can't figure out the reason for this, but a possible solution is to re-sort the list after deletion of an item. |
Good | Table Formatting. The user liked the table formatting, and also that his username was bolded. | None |
Cosmetic | Table Formatting. The user thought it'd be nice to change the color of the column corresponding to the current day of the week. | Change the back-end to do this, though we feel it is unnecessary. |
Major | No FAQ. The user looked for a FAQ while exploring the website and didn't find one. | Take advantage of the fact that the user might actually want a FAQ and put one in. This can help alleviate the bid/ask distinguishment problem. |
...
Our interface was designed for the brothers of ZBT, a very specific audience that is more or less an expert experienced user in the realm of trading midnights. Yet we found ourselves constantly criticizing the design for being too specific in terms of language. Fundamentally, we were trying to merge the midnight trading concept with that of financial trading, which turned out to be more of a challenge than we had initially anticipated.
...
Another issue that our group realized was that designing for the UI often affects how the backend is implemented. During GR4, we cut corners in the code by relying on some visibility hiding tricks to give the illusion that we in fact swapped pages. In turns out that while this was extremely fast to prototype, it limited the capabilities of the back button in the browser. We had to rethink some of our strategies during GR5 in order to get the backend to work, given our coding decisions in previous iterations.
All in all, we learned a lot through the process. We were somewhat surprised by the number of times that we scrapped our design and started from the beginning, but we feel that this was necessary, since our final design was quite different from the original, and we couldn't see how it could have evolved as such. What we found the most useful was asking other people what they thought. We sought input from a variety of people: people not in the class, people not in course 6, graduates of the class, etc. It's amazing how drastically different people's views can be.
We took a few design risks in this project. As has been mentioned time and time again, we avoided explicitly stating what a bid/ask was. This clearly came back to bite us, and if we could redo the project, we'd just throw in a FAQ page to take care of it, regardless of whether or not such things are poor taste. If we could redo the project, however, we'd also do a few other things differently. We'd definitely keep seeking more input from not just the target audience, but everyone. While there are certainly aspects that input from the target audience is essential for, the general population is also quite useful for input. We'd also have spent more time in the beginning coming up with, and nurturing, different ideas (as mentioned earlier, we started from zero a lot).
We tested our interface by appealing to our friends to test it for us. This definitely was a good choice, since they were very diverse and provided useful feedback. Keeping an open mind was one of the greatest contributors to this interface's success.
...
Acknowledgments
Special thanks to Sean Chang and Mason Tang for their input.