emotional response to the 360 dashboard

Unfortunately, the New Xbox Experience was installed onto my Xbox 360 console a few weeks ago so I cannot use the old dashboard. But fortunately, my roommate hasn’t used his console in a couple months and still has not downloaded the update. So I was still able to do my little observation. I took one of my other roommates, fakely-named Justin, and set him up with the dashboard. I asked him to explore a little, find a couple songs, videos, things in the marketplace, etc. This is particularly interesting because he does not play videogames. Ever. He things videogames are a waste of time and just rot people’s minds. The fact that he has never used the dashboard is why I chose him as a test subject.

Justin overall did not like the dashboard. He did not enjoy the experience, he had difficulty finding things, and he was confused throughout the whole process. However, I will argue that it does not reflect the quality of the dashboard itself. I argue that it is a direct reflection of the user. This user experienced frustration at every screen, on every blade, and just with everything because he did not know how to use it. He had trouble even using the controller to navigate. This user has trouble using a PC as well, so, it is only fitting that when I put an Xbox 360 controller into his hands that he did not adjust well.

Not everything about this observation was bad news. When he was frustrated, he was more frustrated at himself than with the dashboard or the controller. He actually thought the dashboard looked pleasing to the eye. He liked the colors, and he used them as representations of the blade. Instead of “media blade,” he referred to the place that has the music as “the blue one.” He liked how everything on the blades was organized by either a list a list or a box. He did not seem excited, but he did say that he liked it.

Overall, I would say this little obseration was a success. A completely brand-new user was introduced to the interface and “liked it.” Although he had difficulty navigating, it was more so because of the inexperience of the navigation tool–a controller in his hands. Little emotion was shown, but there was enough to significantly support the argument.


The question that I had in regards to our prototype was wether or not the current users of oncourse would be able to re-adjust to the new format of the oncourse. Our design in many ways tends to have major differences from the current version of Oncourse. Our design relies heavily on the visuals. According to our survey many users are unhappy with the current interface and in my opinion our design is definitely a great improvement. The current interface offered by oncourse is far too complex in regards to the basic needs of its everyday users.

What sets our prototype from many other samples apart is the visual aspect of our data presentation. I believe that many users might not be at ease during their first encounter with our prototype but I believe that it will help them generate a better understanding of the basic functions of Oncourse. We have two different proto types and we need to figure out which one will be a better options in accordance to the feedback which we will receive from our subjects. For many oncourse simply means a frustrating experience. Users are forced to use the oncourse in order to fullfill their desired tasks and therefore having an interface which will enable users to feel more comfortable and have an easier experience throughout the entire process will definitely help the users.

Prototype Winner

We have chosen to use “variation 1” as our final design.


We chose this because out of approximately 11 test runs, it was the most favored. We were given the following feedback from our prototype testing:

-variation 1 is more eye-pleasing than variation 2

-the side tree menu is liked but not noticed

-like the idea of the new classes be automatically customized

-big icons were liked, makes Oncourse more visual

-makes understanding Oncourse easier and better

-user shouldn’t need to use the help section for Oncourse

-make sure you can modify the right side options (lab/discussion) can be customized and adjusted accoridng to class

-make sure when hovering over links user knows it is click able or not

So, keeping all this feeback in mind, we have chosen to use variation 1. We will slightly modify a few things that will improve its design based on the feedback we recieved.


The main question I have is whether all of the already confident Oncourse users, who got perfectly used to it’s not the most efficient, but still working interface, would be confused and misled by the developed design? In other words, the question is whether the developed design is revolutionary (we invented something new) or evolutional (consistent with the previous design, but improved)?

The paper prototype will definitely help us in this identification, because it is the only way we can test the design and experience it in action. The testing process should be limited in time and involve comparison of both the old fashion Oncourse and the new one. For instance, we can give the user a particular task (such as changing the order of tabs in a predefined order) and have compared the time it takes the user to perform such task on the old Oncourse to the time required to perform the same task on the developed Oncourse (surely we can simulate the new Oncourse in our prototypes). If the person does it in the same amount of time or less, we got perfectly working design that is consistent with previous and it is going to substitute old Oncourse without affecting experienced users. In other case, we have invented something new, which means that both inexperienced and experienced users would become inexperienced and therefore, we have more people that would have to get used to the new design.


I am confident that the design our group made for a better Oncourse will be generally accepted as a vast improvement to the piece of crap that is there now. We put quite a bit of thought into it. The ultimate goal of every design is maximum efficiency and usability, and my question for our design is the following: Is our prototype of Oncourse designed so that the user says to him or herself ‘Wow, this is much better.’

Not everybody is going to agree that any particular design is the best, and that’s okay as long as it meets the goals of the user. For Oncourse, the user wants to find information quickly and easily. Nobody is going to want to use Oncourse, but if our design can get a user to find the information without having a sense of accomplishment while doing it then we know it’s good. This system should be like “Yeah, so what?” when a user wants to find something.

We used two different methods in our design to make the Oncourse experience fail-proof. We have blatantly obvious buttons in the middle of the page that are clearly labeled with places the user will go. We also have the tree structure in the background on the left side. If the user feels more comfortable using that then more power to him or her, and if for some farfetched reason he or she cannot find the information through the main part of the page then the tree is always there as a backup. Both of these methods are quicker, easier, less confusing, and better than what Oncourse has now.

To ensure that our group achieves the result we desire, our user testing simply uses detailed observation of the user. All we have to do is watch and see how much trouble the user has, how long it takes him or her to find the information, and most importantly listen for that sigh of frustration. That sign of frustration is what we all let out when logging into Oncourse. If we can eliminate that and let the user accomplish the task feeling like he or she did something completely easy then we will have succeeded. I am confident that our design does that.


The question I wanted to see answered is … “Does our design really makes Oncourse easier to use”? It’s somewhat of a broad question, but the entire point of the re-design is to make it easier for users to navigate Oncourse and allow them more customizability. It’s hard to make a new interface and transition people into it without causing some negativity. People don’t like to spend time relearning something. However, that is why I’m hoping the design is simplistic enough and based enough in other interactions that it will not require “learning” and rather allows a user to quickly get from point A to point B.

I’m hoping that if our paper prototyping goes well, people will respond positively rather than negatively and answer this question. I think a way to observe this is both watching the user and their reactions, but also timing it.  We also can ask them post-test how they feel about the new Oncourse and if it confirms what we believe, or if there is something we could change to make it even easier.

Questions about prototypes

My main question deals with if our prototype not only accomplishes our goal of making the use of Oncourse more efficient and simple but also can be learned with a small enough learning curve that people will actually consider it worth the effort to learn the new interface. This is important because we may have a great new interface that simplifies everything so much once the user learns how to use it but if the learning part takes too much time or is too difficult the user may give up on it out of frustration.

Our prototype interviews should give us some insight to this since if the user just completely does not understand then we obviously did something severely wrong. If the user does something wrong and even after they finish and it is explained to them they are still confused then that should tell us about the potential learning curve of using our interface also. A great and efficient interface is wonderful but especially with an application such as Oncourse you want the user to be able to just log on and start their task right away without too much searching or consulting “user guides”.