The Plunge into Experience Prototyping

Facebook Suggestions

So here’s some of the ideas and hardships we had to endure while redesigning the video app of Facebook (at least a paper prototype version of the app). First, we had to reverse engineer most of Facebook to try to get at the Information Architecture. It was also hard to try to figure out the parts of Facebook which were universal pieces of information, and how they were interconnected. Once this was done, the next task for us was to interpret the pieces of information and then regroup them.

Once this was completed, we were faced with the navigation issues of Facebook. With some differences in the actual pages one is directed with when using the video app, coupled with the “ajaxastic” (our prof’s word) nature of Facebook, made for a tough experience to get a hold of. This also was further complicated by the customizable nature of Facebook, in addition to the on-the-fly reconfiguration of the pages, as dictated by the implementation. In short, we had the task of trying to pin down a dynamic website into a static form, which led to an interesting activity. When we thought of changing the unit of analysis to apps, instead of pieces of information, the task became a little easier, as one could think of Facebook as a holder of modules of information, which is easier to handle.

Awesome Suggestions from Our Class

*Make a video show on Facebook, and have users vote for the best videos to show together on Facebook.

*Use clips from the videos users upload to use as a profile picture

*Have each user be a reporter and report what they are doing with video status updates

*Have different emoticons for each user by importing different clips of our faces

*Integrate the fun of greenscreens with the videos users import into Facebook

*Use comments in video akin to VH1′s Pop Up Video

*Make the error messages more useful, as many of us couldn’t create videos easily onto Facebook

Update On Our Final

We get to make a video prototype of a museum exhibit. This is going to be pretty awesome, as we get to work in groups and get to choose our own exhibit content. Any ideas from in the world on something you would like to see? We also get to have the stipulation that the design itself has to be universally accessible, and we have to simulate through bodystorming what it means to be have a disability. We get to chronicle this into a portfolio of work, including the video. Look here for some fun, as it will be posted!

The Importance of Experience Prototyping

The authors of this piece, Buchenau and Suri, define prototypes as a representation of a design before the final artifact exists. They also define in 3 parts: the concrete sensory experience, the functionality of an artifact relevant to a person, and the contextual factors contributing to the experience.

The introduction to this paper was also brought to us with two great quotes:

“By the term “Experience Prototype” we mean to emphasize the experiential aspect of whatever representations are needed to successfully (re)live or convey an experience with a product, space or system”

“We can say an Experience Prototype is any kind of representation, in any medium, that is designed to understand, explore or communicate what it might be like to engage with the product, space or system we are designing.”

The other last piece of information we were introduced with this paper was that prototypes are demonstrated usually to passive audiences, and experience prototypes are meant to bridge this gap. We also got to experience this as well, as we got to see how animators of Spirited Away drew a dragon, by looking at the natural behavior of eels and golden retrievers.

Stay tuned for more!

Stay Tuned!

So today we had a chance to work in groups dealing with creating paper prototypes of a “new” addition to Facebook, called video. When we are done creating our prototype, take a look here soon!

Also, if you would like to add your two cents about what should be in our prototype of Facebook NewTeeVee, please feel free to post.

Smiles!

400 Prototypes!

After returning from a wonderful Spring Break, we were reintroduced to the topic of prototyping, and the many kinds and purposes they can give to designers. There are a couple different types of prototypes, classified by our professor:

There is a classic notion of what a prototype is. This type of prototype is meant for iterative system design and to help foster the generation of ideas. At some point during the creation of this type of prototype one creates something, and uses this something as a tool for evaluating the ideas and interaction the prototype affords.

There is an exploratory notion of what a prototype is. This type of prototype is akin to what some call “interactive sketching”, and the point of these is to facilitate the communicative process between different people during the design process.

There is a research notion of what a prototype is. This type of prototype is akin to probes, where one makes a version of a system, and “releases it to the wild”. By releasing, we mean to give the prototype to users to get a better understanding of the use of the prototype, and to also get access to their lifeworlds. This prototype will also help the designer to become literate in the realm of the user and be better able to empathize with them, potentially creating better designs grounded from insights from actual people.

Here’s an FYI for those wanting to get a job in the design field: getting good at making these is a skill one should have, and will most likely be tested on interviews, so keep these skills sharp!

In the field today, the term fidelity (faithfulness) is still thrown out as a description for the types of prototype someone wants built. There aer low fidelity prototypes, which are used near the beginning of the design process, and looks very sketchy (literally). High fidelity prototypes are used in the middle or towards the end of the design process, and this type behaves and looks very similar to how the final system will be built.

We usually make UI prototypes, which simulate the interface of something. These mimic the look and behavior of what a system might actually do, but the code behind them is mostly forgery, or done in a “Wizard of Oz” style. Many of these are created in Flash, PowerPoint, and paper.

Some of us may actually get to make technical prototypes. These are prototypes of a system which simulate the behavior of the system. This is usually done from a programming standpoint.

There are even prototypes which emphasize the snapshot of the system one is trying to make. These are horizontal (which capture entire systems superficially, and Information Architects love these) and vertical (which prototype the behavior of a small section of a system) prototypes. There also might be diagonal prototypes (a term I made up), which might blend the nature of both of these (I see these as a first playable or an alpha of a video game, which utilizes the quick overview of a game, but has some parts in higher detail to show where the game is going).

Some in the field might also make the assumption that high fidelity means the use of much technology. This is not true, as some paper prototypes can be very slick, made in Photoshop, use index cards and tape to simulate the behavior (all of which are high fidelity in look and feel), but involve no technology at all. The reverse can be true as well.

An important point to note when creating prototypes is that when the prototype looks especially slick, the feedback one will receive will only be about fonts and colors (pretty much). One may have to use reverse fidelity prototypes to get the feedback one wants about the task flow and such. Creating reverse fidelity prototypes is when a slick prototype is made to look sketchy on purpose, and there is software out there that’ll do just that.

To see paper prototyping in practice, take a look at what Common Craft (opens in a new window) has done with the practice. They make hard concepts simple, just by using paper prototyping skills.

And applause if you get the reference mentioned in the title of this post.

A Tour of Accessibility

We were able to have the luxury of a guest speaker at our last class, whose main focus is on accessibility (which is the focus on trying to make our designs able to be used by a wider audience). During this talk, we learned a great deal about how much accessibility should play into our designs (and that’s just the tip of the iceberg!). Here’s a recap:

* Sometimes people think those who are disabled aren’t too smart, or have a lot wrong with them – but this not the case. Rather, they are very clever and smart in figuring out ways to overcome their problems in their ordinary lives.

* Accessibility is something that is pretty easy to start seeing in the world around us. Take a look at curb cuts in the road, the different types of technologies which assist people, and also in the web.

* Accessibility is not only for those who are disabled, but it also helps those who have the full use of all of their senses as well.

* If one is designing for a government, one has to know about accessibility, as it helps to grant equal access to those who can’t necessarily speak up for themselves. One may also lose their job in this situation if their designs are not accessible – it’s the law!

* It is also cheaper to design with accessibility in mind at the beginning of the design process than to stick it onto a redesign.

* There are many tools out there which can help designers make sure they are following the minimum standards of accessibility, but one should also use common sense when designing as well.

* It is also important to note that 1 in 5 in the US has a disability, making accessibility a big issue.

* Using a screen reader and designing for the blind is just one facet of the accessibility problem. These aren’t the only problems out there.

* Technologies have been created to help people with this issues. For example, motorized tables have been created to make using a computer easier for someone who can’t use a normal table.

* There are standards out in the real world to help designers – one just needs to take a quick look on the web and one can find them! It is actually only a couple additional steps to design and code with accessibility in mind.

* One can begin to start feeling the pain of accessibility issues by role playing – but don’t take it too far (e.g. blindfolding oneself while driving to simulate being blind. This is just a dangerous situation waiting to happen!).

* The only way to start thinking for someone who may have accessibility problems is to tap into our powers of people here at IU. There is the Stonebelt Center. One could take another person shopping who has one of these issues to see how it is firsthand to have issues like these. One can also look at the Adaptive Technology Center of UITS to begin to get an idea as to how IU tackles this problem.

* Usability testing is completely different when testing out a design for someone with accessibility issues. It takes care, patience, creativity, and empathy to do this correctly (this also applies to the whole design process as well!).

Thanks again to our speaker!