From CS 160 User Interfaces Sp10
- Prototyping for Tiny Fingers. CACM. April 1994. 37(4): 21-27. Rettig.
Mattkc7 - Feb 25, 2010 07:21:59 pm
Eric Fung - 2/22/2010 17:03:11
Event handling is effective generally because events are cheap in terms of resource usage. Their cost amounts to a procedure call rather than an operating system message. However, building the event handler requires a complex consideration of the large variety of modifier keys and all their possible combinations, only a small percentage of which will actually be accounted for by the application.
iPhone applications reap the benefits of having 1) pre-built UI widgets such as sliders and buttons, and 2) an object-oriented approach to registering such widgets with their function calls. The abstract class of UISegmentedControl, for example, abstracts away the details of calculating which segment was tapped, or determining whether there was a tap at all. Furthermore, it seems that the widgets communicate with each other and the main program under the Object Connections model, where a widget has a reference to the object (in this case, usually the delegate) performing an action after responding to an event. Actually making the connections--using drag and drop--greatly simplifies the event handling process since it is a lot easier to see what actions are associated with each widget.
Alexander Sydell - 2/22/2010 21:14:05
This article provided a great insight into lo-fi prototyping. I had never heard of the concept before, and upon hearing about it assumed it would mean something along the lines of using an interface building tool to create a few sample screens chained together with a few bits of code. I wasn't expecting it to be as simple as drawing interface elements on pieces of paper and having someone play a computer by swapping the bits of paper around. However, the article shows that there is also a fair bit of work in the preparation - obtaining the right materials and tools, and preparing for user testing. Although it may be a more tedious process than just simply drawing, lo-fi prototyping seems like it's the fastest way to iterate on a design in its initial stages.
Charlie Hsu - 2/22/2010 22:50:34
To be perfectly honest, there isn't much I have to say about lo-fi prototyping that the article didn't. It's a great idea! It would be literally impossible, in our own CS160 group's case, to mockup something in Xcode in a semester and iterate multiple times. Even a well developed paper interface can be made in a few hours with the help of a group of 5. From the loads of valuable information we got back from our Contextual Inquiry assignment, I can easily believe Rettig when he says more iterations are better, and that emphasis should be placed on getting as many user evaluations as possible. The big ideas and content are what are most important to get good user feedback on, and we saw this when we pitched high-level descriptions of features to our dance groups in our Contextual Inquiry interviews. Lo-fi prototypes allow us to focus on those big ideas... because that is all that is in them!
I thought the test technique description was particularly useful. Observers remaining silent and neutral is an important thing to remember; listening to feedback during the Contextual Inquiry interviews was a reminder that we were not our own user, we were not the dance group experts, and that we shouldn't be defensive of the concepts that we worked to think up.
Matt Vaznaian - 2/23/2010 0:14:11
I think the most beneficial part of lo-fi prototyping is the ease at which it lets developers change their models on the spot. Even at the expense of nicer visuals using for example Photoshop, it seems like the most important part of the user interview process is to be able to change models based on feedback instantly between sessions. That way you can already make many improvements during the entire process to be able to offer future interviewees a wider range of models to choose from. I am excited to get the opportunity now to be able to build a lo-fi prototype and test it out. I also really like the idea of using overhead projector paper, I never thought of that before.
Calvin Lin - 2/23/2010 1:06:29
I can see how Lo-Fi prototyping can be very beneficial, but at the same time, there are a couple issues with the process, and thus I believe it must be supplemented with other types of interface testing. Similar to a problem with the Master/Apprentice model of Contextual Analysis, one issue that arises is that the subject we are observing is taken out of his/her normal comfort zone and the ability to perform normal tasks may be affected by the presence of several others watching. The environment takes the subject out of a normal working mindset and a natural flow of performing tasks and transitioning between them. Or more simply put, the interviewee‚Äôs behavior may be different. Thus, the way the subject interacts with the interface may not be how he/she normally would alone and in a natural work environment while in real work situations. Being in a hypothetical situation is a completely different mindset. There are certain situations that simply cannot be modeled with this Lo-Fi testing process and therefore other methods must accompany the process to account for this.
Aneesh Goel - 2/23/2010 2:46:19
One interesting aspect of the lo-fi protoptyping process that stood out to me was the relationship between the testing process and the contextual inquiry methods we learned before. There's a clear tie to the task questions from before in the scenarios you build to put your user through; unrealistic scenarios make it hard to gather useful data, so the results of that analysis are critical. The actual methods involved are also similar; making the user comfortable and having them work as naturally as possible, with an emphasis on their workflow rather than your product. However, there's a fundamental difference that poses a problem I'm not sure the article clearly explained how to solve. Because the person is working in your environment, not their own, in a monitored test, and most importantly is working with a device that might be analogous to their own experience and to your product but is sufficiently different to break their usual workflow - the lag times alone on the human processor would interrupt many normally rapid tasks - it seems difficult to get natural responses out of your test users, and performance anxiety and similar factors combined with the unfamiliarity will certainly skew results in a manner that more high-fidelity prototypes would not. Creating a natural working environment despite lo-fi prototypes seems like a major barrier, and I'd like to see more detail on overcoming that issue.
Jeffrey Bair - 2/23/2010 18:59:26
It is interesting to see how lo-fi prototyping such as making paper designs work well in showing the failures and problems in some of the initial designs. I think it would be helpful for our group as well but it is definitely hard to get skaters (which is our target user group) to sit down and interact with our paper designs seriously, especially since we try to find skaters around skating locations while they're skating. Also our design is meant for skaters who are right on the skating site and it would be difficult to replicate the same type of environment that we can test. I can see this being more possible with desktop applications but with mobile applications it is far more difficult. However, being able to get prototypes out fast and without the hassle of spending a large amount of time coding features is something that is very useful even just for the coder themselves to see how improvements can be made with the design. Also having coders draw out how they think the app should look like gives a much better overhead view of how things should be coded and help with organization.
Wei Wu - 2/23/2010 20:38:31
Rettig's article overall presents a very convincing argument for the benefits of lo-fi prototyping, but the process in which he selects users seems a bit ambiguous. I am not completely sure what he means by "people who fit the same profile as your actual clients," and yet not the actual clients. If, indeed, the people who are testing these prototypes and influencing design decisions are not the actual people who ultimately use the finished product, then there is no way to ensure that those who actually use the product would feel the same way. The so-called improvements made from each cycle of lo-fi prototyping would be obsolete if this were the case. Even if the test users he refers to do have the same set of knowledge and skills as the clients, and are representative of the clients themselves, why are the designers not making this product for them as well? Perhaps there is an aspect of the "business" of UI design that I am not fully understanding here.
Victoria Chiu - 2/23/2010 20:54:34
To know the users and knowing that we are not our users are few of the most important things I learn in this class so far; assumptions do not always match the reality and there are a lot of things that are beyond my assumptions. Testing with the users when we can still make prototyping very fast seems like a good idea. The article emphasizes the advantages of using paper prototype although there are other prototyping tools because developers "easily become obsessed with the prettiness-power of a good tool" and prototype in software "can set expectations that are hard to change." But wouldn't asking users to test a prototype that is closer to final products be more appropriate than asking users to use paper prototype that would probably look and feel very different from the final product?
Mohsen Rezaei - 2/23/2010 21:14:26
One thing that is still unanswered in the interface design techniques is How does the person who play the "computer" should behave toward the test user? Is such a testing like a discussion session that will happen between the user and the "computer" or the user will have to do what he/she sees with no questions asked from the "computer?" Although experience has shown that hi-fi prototyping is "a potentially bad influence" (http://www.telono.com/articles/OZCHI2000.htm), I believe as a step to an interface design it would be actually effective to have hi-fi prototyping after the lo-fi prototyping. This is true, because before actually getting caught up with coding the actual interface we could get the users closer to the actual interface design by having prototypes that are done in interactive softwares like Flash or Adobe Flex. This could actually be done concurrently with the actual code, which helps find out problems with the design way earlier than when it is fully coded in the real/actual system or device.
Jason Wu - 2/23/2010 22:14:53
From this article, I definitely see the benefits of doing lo-fi prototyping over hi-fi prototyping: It is very low cost and takes much less time, allowing user interface designers to go through many iterations of prototyping and formulative refinement in the same time it would take to create just one hi-fi mockup. I'm pretty excited about the upcoming lo-fi prototyping assignment, since it will my group to refine our ideas about the skateboarding app we have proposed and run these ideas by our actual target users. I feel that we are fairly well-prepared for this next step in the design cycle since we have a good sense of what our target user is, and we have performed enough task analysis that we already have some scenarios to test. At the same time, based on interaction with skateboarders during our contextual inquiry, I'm not sure if our target users will actually be willing to spend an hour or so away from skateboarding to poke and prod our lo-fi prototype while a facilitator continuously asks them about their thoughts regarding our paper interface.
I really liked Rettig's suggestion on how to put users at ease when they seem worried they are somehow "flunking" the test. People might not be willing to offer useful suggestions if they feel like they are being scrutinized or if they feel stupid because they don't understand some part of the design. I also liked the suggestion to evaluate test results by piling note cards near their corresponding interface components. For a very visual person like myself, this step will definitely help me generate ideas during a brainstorm how on to fix problems. One thing in the article I don't agree with is the suggestion to rotate the four roles when conducting more than one test session in a day. While the greeter and observers can easily switch roles, it seems that the facilitator and especially the "computer" must spend a great deal of time learning their parts, so the people playing those roles should probably stay in the roles throughout the entire testing phase.
Jonathan Hirschberg - 2/23/2010 22:16:42
Even though the surrogate users may be easier to access than the clients themselves, and may seem to fit the same profile as the actual clients, is the resemblance close enough to allow people to use the results from testing with surrogates to guide the design meant for real clients? Since the surrogates either may not be working for the same company or at the same rank as actual clients (that may be why the actual clients are inaccessible), they are substantially different in this respect, and that difference may cause differences in the results. The main question is whether or not the differences between these clients will result in different user interface experiences.
Eric Fung - 2/23/2010 22:35:01
This reading reminds me of CS169, where I was first introduced to the waterfall model of software development and its flaws when compared to the iterative model. The waterfall model was the more natural model to develop from other engineering disciplines. It assumed software could develop properly in one iteration of plan-design-implement-test. However, the iterative model is proven to be more successful, less stressful and yields more polished results. Its use of repeated testing and redesigning irons out bugs much sooner and in a more focused fashion. Of course, low-fi prototypes are key in making the iterative process as quick as it is.
I think the difficulty of taking up lies in the fact that "interface designers spend 95% of time thinking about design, 5% about mechanics". As computer science students, we probably get most caught up in implementing the solution that looks best at the moment, adding additional elements one at a time as we encounter them. Doing a thorough design that requires exploring many, many alternatives and interviewing people likely makes most programmers anxious, agitated, and antsy to start working--writing code.
The takeaway point is that "you aren't your user", and when test-driving the design with customers, you need to let the design speak for itself, moderating the user and design with neutrality.
Daniel Ritchie - 2/23/2010 22:57:35
Rettig's article makes a strong case for lo-fi prototyping. Reading the article with the question "How will this help my 160 project" in mind, however, raised some concerns.
Rettig describes a lo-fi prototype as essentially like a computer, but with unusually long response time (as the human operator controls the logic). I can see how this allows for a reasonable simulation of user experience with a typical application: buttons, menus, dialogs--many of the traditional interface elements would stand up to extra-long latency.
However, I wonder if a touch-based interface such as the iPhone can make the same claim. With interfaces like these, users expect to directly control application content with drags, swipes, and other familiar gestures. I can think of two ways for a lo-fi prototype to accommodate these actions (both with their pros and cons):
1) Allow the user to directly control pieces of the prototype. This best simulates the actual experience, but it comes at the cost of shifting part of the operator's role to the user. The user might very well break something that an experienced operator would not, thus creating evidence for problems with the interface that might not really exist.
2) Have the user indicate what actions she wishes to perform, but have the operator actually execute them. This keeps the role of the operator distinct from the user, but it essentially reduces direct manipulation interactions to commands. This may not give the user a very accurate impression of the intended experience and might lead to unhelpful feedback.
The best practice probably takes both into account: make the prototype as bulletproof as possible while also taking time to identify which functions a novice user cannot be expected to operate reliably.
Vidya Ramesh - 2/23/2010 23:11:36
The author of this column discussed the various aspects of lo-fi prototyping. Even while he mentioned many of the good aspects of the prototyping, he totally forgot to bring up some negative aspects of this type of testing. No matter how well a paper prototype is made it can never replace hi-fi prototypes for the authenticity of the experience. Paper prototypes also are limited by the wizard of oz techniques and do not allow for quick changes to aesthetic elements (ex. background color, text font) to be made. However, the columnist did bring up some very valid points about the benefits of using paper prototypes. Another interesting point that the author brought up was the fact that during the interview, the camera was never allowed to videotape the interviewee's face. However, a person's face can be a prime source of instinctive, unconscious reactions that the person himself might not be willing to voice. I think that engineering confidence within the interviewee and signing solid non-disclosure agreements and confidentiality agreements before the interviews begin can create trust between the facilitator and the interviewee, but still allow the critical pieces of information that come from videotaping the interviewee's face to be recorded.
Daniel Nguyen - 2/23/2010 23:27:04
A disadvantage that the reading does not mention in regards to lo-fi prototyping is the possibility of overextending the bounds of the designer's technical capabilities or possibilities. When using lo-fi prototyping tools, it is very easy to design an interface with very complicated under the hood capabilities. Something that can be done magically by the human-computer in lo-fi prototyping may not be an actual capability of the actual computer. This would be one of the only places where hi-fi prototyping would be better than lo-fi prototyping, because creating a hi-fi prototype would never allow a designer to surpass his technical capabilities. However, this is usually only a concern for more inexperienced or amateur designers.
Wei Yeh - 2/23/2010 23:53:14
While I really like the idea of lo-fi prototyping, I feel the ways to carry out lo-fi prototyping Rettig describes are very low-tech and, thus, inefficient. First, Rettig suggests that prototypes be built using physical objects, like pencil and paper. Why not use a tablet to draw the UI on a computer instead? That would make testing on multiple users much more efficient, since having multiple instances of a system would be trivial. Perhaps there is some benefit of using physical objects that I'm not seeing? Also, why use notecards to take notes when you could use a computer to type everything up? Why not use lo-fi prototyping software to quickly sketch up lo-fi UIs, construct interaction, and take notes on a computer?
David Zeng - 2/24/2010 0:10:07
While I do see the merits of lo-fi prototyping, there are some concerns that I would like to address. My primary concern is that with only a "lo-fi" prototype, the user would not take the evaluation as seriously, mostly because the product they are seeing is not seen as "complete." While it may be easy to convince engineers to see that lo-fi prototyping is beneficial, most people out there still believe that testing and evaluation should be done with something that is solid and built. I feel like that for some users, we would have to coerce them into believing that the prototype is real. At the same time, at least a small portion of the user experience that they have with using the real product is lost. There are some thing such as speed of performance that cannot be measured with a lo-fi prototype. It may be necessary to get input on that as early as possible, to determine what optimizations are needed for performance and speed.
Jessica Cen - 2/24/2010 0:44:33
When I first read the ‚ÄúConducting a Test‚Äù section on page 26, I was surprised to find how complex the test is even though a lo-fi prototype is being used. However, due to the flexibility and simplicity of lo-fi, I am now convinced that it can actually help the developer team to see if the proposed result will actually help the user and not make his life more complicated. However, I still believe that the person who uses his pointing finger as the cursor is very different from the final, successfully-running result. The people who were tested will surely react differently to lo-fi than to the real thing once it is implemented. For example, the people tested may feel confident with the greeter and the facilitator guiding them through the lo-fi prototype test. But once the user is facing the final result, he might not have the same ease as before when someone was guiding them. Therefore, I believe that conducting a test according to Rettig might not give all the results needed to jump into the final working solution. More testing has to be done in every stage of the development in order to have a successful final product.
Boaz Avital - 2/24/2010 0:47:04
While I clearly see the benefit of lo-fi prototyping and testing, I have a few questions for how do it successfully.
First, and this is especially a problem for us students, how do you get past the problem of the user giving the designers the "benefit of the doubt" with their feedback? If they don't understand something or don't like something, the users may think it was just an artifact of the weird paper process.
On the other end of the spectrum, how do work with testees who just can't handle the paper interface? They just don't 'get' how to use it like a computer or phone.
In the same vein, how do you make the paper give the same cues for actions that a computer or phone does? Digitally, there are ways for buttons to look like buttons, rollover effects to show interaction, etc. These can be hard to do on paper. Then when you get to interfaces that are not made of completely standard elements, the user has almost no leeway for experimentation so doesn't know what actions can happen where, something that would not be as big of a problem on the computer. Even harder would be getting a user into the "iPhone mindset". On the iphone, a lot of actions aren't immediately apparent but are standard to iphone interaction, such as pinch zooming and sliding the screen to go from one picture to the next. How do you get these across without explaining how the whole interface works and thus spoiling the test?
Tomomasa Terazaki - 2/24/2010 0:47:35
This article was very interesting because I now understand that problems with creating an application or any form of software for computer is usually not the level of computer programming (computer language) skill. When making software, many programmers use the Lo-Fi strategy where they use papers and people to simulate a program from computer. The author believes if successful during this level of programming is very important to create the best software for the user to use. He says it is important to prepare the interview, so they have all the equipments and the right interviewees. I find this very true because interview has to be perfect. The interviewer has to be prepared for anything. Also, I believe that it is important to make the interviewees to feel at home because or else they wont give their true feedback. I think it was interesting to read this article because most of the possible error happens from human errors, not computer science. For example it says the programmers cannot fall in love with what they have because they wont change anything that way or they cannot be focusing on making the interface pretty because that should be the last thing to focus on. The most important thing to accomplish is to make software that works and is easy for the user to use. When the author talks about how the testers should not laugh or say anything to the interviewees but I think this is obvious because laughing at someone is wrong on human level so something like that should not happen anyways.
Bryan Trinh - 2/24/2010 2:55:14
When I first encountered low fidelity interface prototyping at a workshop in Hearst thought it was the most astonishingly effective way to try out ideas. This was amplified further when we mixed digital technologies with the analog ones. By taking pictures of each slide with a hand pressing each button, we were able to create the illusion that the button caused the change in display event. Low fidelity prototyping is something that seems ridiculous until you have tried it out.
What seems somewhat counterintuitive is that he "analogness" of the whole thing seems to matter a great deal. A software built for low-fi prototyping that uses familiar Adobe like graphics building could potentially be much quicker than using paper mock-ups, but this diverts the attention of the reviewers from what is important-- the usability.
Kyle Conroy - 2/24/2010 9:38:15
Lo-fi prototyping is a skill that, in my experience, is not applied enough in the design of software, especially web applications. A usual workflow for designing web applications is to create some wireframes, iterate a couple of times, and then throw the design into Photoshop. Then, the graphic designer on the team creates a mock of what the application will look like, finally handling it off to a web designer to cut and slice the image into a real web page. This process is broken because Photoshop is not the web. Font rendering, layout issues, and colors all look and behave differently in Photoshop then they do in common web browsers. This disconnect leads to sites that look great, but do not function well. Therefore, it is my personal belief that after lo-fi prototyping is complete, a design should be translated directly into markup. While this incurs some cost, writing basic HTML/CSS isn't a problem for an experienced web developer / designer. The benefits are huge, as the mockup can be accessed by any team member with a browser and the experience can be checked across multiple browsers all at the same time.
Arpad Kovacs - 2/24/2010 9:39:52
I really enjoyed reading this article; it was concise, concrete, and persuasive in extolling the virtues of lo-fi prototyping. The main benefit of this simple, fast, cheap, and low risk "formative developing" style of development is that it allows designers to iteratively churn out ideas and test on users without any commitment. An interesting side-benefit of lo-fi is that designers and users focus less on the actual presentation of the interface, and more on the content itself. Paradoxically, it seems that achieving a fully-functional model of the interface is essential for success of the lo-fi prototype; otherwise users will not be able to experience the full sensation of interacting with an actual program rather than a mere illustration.
My only concern with the lo-fi approach is whether the reduced speed of interaction (compared to a hi-fi prototype) will influence users' behavior. The instantaneous feedback provided by an electronic interface may encourage users to act more impulsively due to the low time costs of taking action. In contrast, with a human "computer", the delay between issuing a command and observing its feedback may cause a loss of directness. For instance, with the electronic interface, the user might decide to hover over each icon in a toolbar to instantly view its tool-tip, while he/she may find that too slow/tedious in the analog version, and will only inspect icons that resemble the task she is interested in performing.
A related rapid-prototyping approach that we already talked about in class is the storyboard, which is often used in the animation and product design industries to brainstorm and iteratively refine the possibilities for a scene or scenario. Again, the inherent properties of paper craft media - low investment, easy to change - encourage continuous evolution and improvement of the design based on constant feedback. It is interesting to note that there now exists software to make lo-fi storyboards and prototype mockups (such as Balsamiq). I expect that the ability to drag-and-drop premade components, and copy-paste existing ones has driven the interval between iterations even lower than at the time this article was published, and we are now approaching an era when designers can modify the interface on demand, in real-time, to respond to user feedback.
Jungmin Yun - 2/24/2010 11:17:05
I liked this reading because it is very interesting and not that long compared to previous readings. This reading talks about lo-fidelity prototyping. Lo-Fidelity prototyping is an invaluable design tool that is independent of any specific computer system. A lo-fidelity model is constructed early in the design phase so that a working prototype can be evaluated. The lo-fidelity model is a paper and pencil implementation that can be constructed quickly and cheaply. Use of such a model promotes iterative user centered design. However, unlike lo-fidelity prototyping, hi-fidelity prototyping takes long to build and change. So, I definitely agree with with all the reasons that hi-fidelity prototyping is not good for initial steps. I like the idea of using lo-fidelity prototyping instead of hi-fidelity prototyping. I personally use a lo-fidelity technique when I need to come up with ideas and do initial design and hi-fidelity technique when I need to submit my projects because I can easily add, modify, and delete what I draw. Whenever I spend long time to make my design look better, meaning that I focus too much on small details, I sometimes miss some important things. To avoid this, I realized that I need to focus more on the big picture instead of small details after reading the reading saying "Giving too much detail to the testers also distracts them from focusing on the big picture that the designers care most about."
Annette Trujillo - 2/24/2010 11:50:43
I think lo-fi prototyping is a great way to get through many rough drafts of our prototype without it being so time consuming and costly, as it would be doing hi-fi prototyping. While doing lo-fi prototyping, I think a challenge for me would be to stay focused, serious, and keep a straight face when the user has spent 10 minutes using all the wrong controls for all the wrong reasons. I have always been the kind of person to give instant feedback, in this case by maybe raising an eyebrow at the user in amazement at their errors, or by making small gestures or comments to try to help the user. I know I will feel a big urge to explain to the user, so I know I need to prepare myself for lo-fi prototyping before we do it. It may be better if I be a person in the back or on the side giving notes, that way a user won't see my discrepancies, in case there are some.
Esther Cho - 2/24/2010 12:34:31
Rettig explains lo-fi prototypes as pen (+ markers, colored tapes, and others) and paper production which is less time-consuming than hi-fi prototypes. However, I've seen lo-fi prototypes that look like hi-fi prototypes using screenshots and Photoshop, which would not be as time consuming as real hi-fi prototypes. I don't think Rettig addresses this, although he has commented on printing out screenshots of some widgets such as buttons, dialog frames, and scrollbars to "look sharp." Personally, I think lo-fi prototypes that look like hi-fi ones would still fit under hi-fi prototypes, even if it doesn't take as long to create because of the comment that "reviewers and testers tend to comment on 'fit and finish' issues." Even if you can hand-demo this kind of prototype, people are drawn to the aesthetics of the UI rather than the content, and correction made from a photoshopped prototype would be harder to do during testing sessions. I believe simple widgets should be as far as designers should go when building prototypes because they can be easily arrangeable.
Linsey Hansen - 2/24/2010 13:44:03
So, before reading this, I was somewhat critical of paper prototypes, at least against fancy coded ones- I mean, I knew that the paper ones were definitely cheaper and easier, but I felt like they were definitely not as useful. Since the whole purpose of a prototype is to test the efficiency and usability of a design (not the "prettiness-power"), it makes perfect sense to use paper for things such as testing the layout and learning curve of an interface. Plus, as Rettig mentioned, the developer is far less likely to become attached to a quick, cheap paper design than a fancy one they spent days (or weeks) on, making the critique process easier. I still believe the more realistic prototypes also have their advantages over paper (ie that bottom left pixel not being part of the start button problem in windows), but then it is totally possible to just do a coded prototype after several phases of testing with the paper ones. By the way, "prettiness-power" is my new favorite phrase.
Divya Banesh - 2/24/2010 14:20:41
I really enjoyed Retting's ideas on lo-fi prototyping and agree that making lo-fi prototypes save time, money and lead to better results. However, I feel that lo-fi prototyping can only not be the sole type of prototyping used by a designer. After several iterations with with low fidelity prototyping, the designer must create some high fidelity prototypes of the test users can actually see what the product will be like on a computer or iPhone. With the paper prototypes, users get a feel for the system and layout of the product but things like the time it takes for a window to open up or how one application might interact with others on the computer might be difficult to visualize. After an idea gets properly flushed out, the designer needs to make atleast preliminary prototypes on the computer so users can test using their mouse or keyboard instead of fingers on paper.
Peter So - 2/24/2010 14:41:54
I really enjoyed reading this article mainly because it resonates with the concepts I've learned about in other classes. I also attend the CS269 rapid prototyping class in the BID room in Hearst where we talk about ways to capture ideas on the spot. We learned some software to help build prototypes such as Powerpoint mockups or even a Lo-Fi GUI builder called Balsamiq. However, I feel pen and paper mock ups to still be more useful in getting my ideas and my groups ideas on paper and generating a basis for conversation through my experience with a club on campus called Berkeley Innovation which is what we did during a weekly meeting. I have also fallen victim to initial designs that could have been improved because I had invested time into them and didn't have the opportunity to revise all of them before the deadline. Thanks for the great and refreshing read.
Geoffrey Wing - 2/24/2010 14:53:08
This week's reading on lo-fi prototyping was an interesting read. I have seen some examples of lo-fi prototyping in my CS169 class, but it wasn't something that stuck with me as really useful. After this reading, I definitely see the advantages of lo-fi prototyping. I particularly found the quote, "You aren't your user," very fitting. While working on our Contextual Inquiry assignment, I felt like we were making significant assumptions on what our target users would want and what would be best for them. Of course, for a first mock up, you won't know until you've tested with our users. I will definitely keep this in mind as we receive feedback from testers.
One question I do have after reading this article is when do we stop using lo-fi models and when do we transition to hi-fi prototypes? The article seems to suggest that you move straight from lo-fi to actually development, but I feel it is necessary to use some hi-fi prototypes. With the paper models, users will use their fingers as a mouse, and speak what they want to type. The lo-fi prototype lacks the simulation of input, whereas in hi-fi prototyping, users can use real keyboards and mice.
Long Do - 2/24/2010 15:36:21
Low-fidelity prototyping seems to be a very good way for us to gain insight on the design of our projects. But what should we do if we do not have a video camera to record what is happening? The example in the reading also seem to suggest that when giving the demonstration to the users, that each user tries it one at a time. Is it possible to have multiple users try it at the same time? How many users should we test our prototype on because a few number of users would lead to the project being personalized for those few. Lo-fi is very good at getting the basics down which is important.
Nathaniel Baldwin - 2/24/2010 15:38:52
I didn't know it before I saw the images in today's reading, but our application definitely needs a giant dialog box that just says "WRONG!". OK, not really, but it made me laugh. Having already been exposed to the idea of lo-fi prototyping earlier in the class and readings, I was wondering what exactly this article would bring to the table. I can't say it offered a ton of advice, but probably just enough of an outline of the process and a few tips to really get us going. (I had no idea they sell "post-it glue", but that's good to know and look out for). The breakdown of roles to play in the exercise was also helpful, and I'm glad for the reminder to run through the process for practice before the real users show up. It'll be interesting to see how this assignment goes.
Kathryn Skorpil - 2/24/2010 15:44:25
Last semester I was a customer for one of the groups in 160. The lo-fi prototyping really helped their group improve the basic functionality of the application, as well as helped me understand exactly how the application was going to work. Personally I have created many lo-fi prototypes of websites before creating the final page. When they have to be reviewed, it is then very easy to go back and change something if it needs to be changed. I tend to get attached to my work, but in the lo-fi prototyping stage I am much more willing to change something than if I were working on the hi-fi prototyping so it is definitely a useful strategy.
Saba Khalilnaji - 2/24/2010 15:46:01
I love the fact that a bug in a lo-fi paper prototype of a UI can be fixed with a quick swipe of the pen and the test and continue. Hi-fi prototypes unfortunately need to completely halt and the bug needs to be fixed for a test to proceed. Before reading this article when I thought about lo-fi prototypes, I thought about sitting down with a user and showing them the design, but I never thought about testing performance by asking them to complete a certain a task and trying to reduce the time needed to do so. This type of formative evaluation substantially increases the value of the lo-fi prototyping, since they are so easy to change. Creating scenarios is quick and easy to. We can always draw a storyboard of a user successfully using our product, but that assumes the product is easy to use! By having the user actually go through the steps in the user interface needed to complete a previously drawn storyboard would yield invaluable data to the design team. I look forward to using this in the future!
Bobbylee - 2/24/2010 16:01:29
Personally I think that lo-fi is really important. However, as time goes on, I think there will be more computer lo-fi designs than paper lo-fi designs due to the fact that electronic devices are so popular. In addition, many more electronic devices support touch screen functions. So we might allow the interviewees to move around buttons. However, we have to ensure that interviewees will focus more on the functionality rather than just the interface design.
Vinson Chuong - 2/24/2010 16:02:39
Just as the Contextual Inquiry and Task Analysis assignment gave us insight into what our target users actually did--contrary to our initial hypotheses, lo-fi prototyping is an excellent way to gain insight into what expectations and experiences users bring to the table when using our application. When we draw our first sketches, we design the interface based on what we think works without taking the users into consideration. It is precisely at this point that user feedback be acquired. In figuring out the tasks that the users want to perform, we've only done half the work. We must also figure out how the users want to perform those tasks while our interface is still malleable.
However, I find the claim that lo-fi paper prototyping is faster than computerized prototyping to be a bit dubious. When the goal is to quickly produce a usable and somewhat good-looking model of the application, it stands to reason that copying and pasting pre-coded interface elements is much more reliable than attempting to neatly render ideas by pencil. For example, HTML, CSS, and JS are at the point where any designer with fluency in those languages can generate a high-fidelity and fully malleable mock-up of any interface with ease. Many of the techniques we've been introduced to through the readings are usually from very old readings. It's useful to consider how we can adapt these techniques to currently available technologies.
Hugh Oh - 2/24/2010 16:09:26
Lo-fi prototyping is intended to be a cheap way to mock up ideas quickly. The emphasis on speed can be a large barrier for users when doing lo-fi testing. The more users need clarification on an interface the less and less the test will actually measure the quality of the program (because of the lo-fi quality not the actual interface itself). Lo-fi prototyping is very effective for developers but can be extremely inaccurate for testing.
Brandon Liu - 2/24/2010 16:09:37
Lo-Fi prototyping is definately the best way to learn more about your designs before you commit to code, but it goes against certain kinds of expectations in business situations. A lot of the time the established convention among clients and designers is that the client begins building the product and giving updates on the progress, and at some point in the future it is "ready" for user testing. The article makes some mentions of how lo-fi prototyping might be awkward, so it is important to make sure that clients understand that this arrangement is in the long run better for the product as a whole. This issue is related to the tendency that reviewers and testers comment on the "fit and finish" - consultants and designers are aware that the easiest way to impress a client is with the presentation of the product, so this goes against their willingness to use lo-fi.
Long Chen - 2/24/2010 16:13:36
This week's reading definitely gives a great jump-off point for the next group assignment. I was already sold on the advantages of lo-fi from lecture, but the details in this column really listed out the reasons why it is more effective. What I found particularly helpful was the list of supplies recommended before attempting to build the prototype. The transparent sheets used for overhead presentations was something I would never have thought of using without the nudge from this column, and posting just one issue and problem per notecard is a great way to take notes and organize the issues later in a fast and effective way.
The breakup of the roles of each person is well thought of and the boundaries are well defined. This reading is one that I will print out to use as a reference when my group is preparing to run tests with users. The reading has made me excited about the upcoming assignment. This is my first class project done at Berkeley that involves advanced preparation to interact with real world users, and this sort of project is something that I have always wanted to do. I really believe our first runs of lo-fi tests will flush out a lot of our design decisions and fine-tune our application more closely to fit our users.
Raymond Lee - 2/24/2010 16:29:48
The entire technique discussed is very novel to me and I'm excited to try it out on our Boy Scout target user group. Besides that, one thing that struck me is how sensitive we have to be when demonstrating the prototype to the client-- sensitive to their thought process and confusions, as well as to their egos. Interacting with customers is a valuable skill that I'm glad to be learning as part of this course.
Joe Cadena - 2/24/2010 16:35:02
Low fidelity prototyping seems like a useful tool to help the members of a design team become intimate with their project. I've seen many times when one or two people take command of a project leaving the rest of the team members guessing the direction of the design. I especially liked the idea of rotating team members between testing. This allows each member to interact with the design as well as produce their own observations. The only detail I am curios about is the level to which confidentiality is kept. Does assuring the user of his/her anonymity require great lengths? The extent the team went through to ensure confidentiality seemed too much.
Andrew Finch - 2/24/2010 16:40:12
Using low-fidelity prototypes definietly seems like a method of UI testing that has a number of key advantages. As the article describes, the biggest advantage comes from that fact that lo-fi protoypes can be made quickly and easily out of common materials, such as paper and ink, and this allows a large number of varied prototypes to be created and tested in succession. A major problem with this method, however, is the fact that there is a human instead of a computer handling the user interaction, and this can be slow, lead to errors that the computer wouldn't make, or even fix errors that the computer would make. These types of issues cause the tester's interactive experience to be misleading. Lo-fi prototypes that are implemented with software are much better in this sense.
Sally Ahn - 2/24/2010 16:41:01
This article clearly reveals the benefits of lo-fi prototyping. It makes sense to simplify the prototypes so that we can get as many iterations of prototypes during the design phase since "each iteration means improvement." I can attest to the importance of lo-fi prototypes from my experience in 3D animation. For example, we spent months just gathering feedbacks for our story from various outsiders by showing them our animatics, and our story changed quite a bit from the original pitch during this process. 3D animation has tremendous labor and time costs, and having go back to make changes to the storyline would have made it impossible for us to finish on time.
I can see this phase as being crucial to our project because it is a fairly complicated application with multiple features that require navigating through many different views that may require a lot of time to implement by code. Rettig makes many good suggestions on exactly how we might transform this process for a lo-fi prototype, such as using white out tapes for quick text fields and creating blank templates for commonly used windows or alert boxes. I think such ideas will be very helpful when we start to make our own lo-fi prototype.
Richard Mar - 2/24/2010 16:45:52
I have had experience with building a user interface (for Spectacles). I spent about a week sketching out a mockup, got that past my advisor, and then went to work building a prototype. It ended up being a hi-fi prototype, with some of the actual back-end functionality implemented. After another week I had the prototype, but by then I really didn't want to make any major changes due to the countless hours I had spent on the back-end code. Consequently, later feature requests and bug issues were much harder to add and resolve because I couldn't simply change the interface to accommodate users and avoid problem cases.
Angela Juang - 2/24/2010 16:52:33
While lo-fidelity prototypes require less time and fewer resources to create and are generally a very good tool for getting feedback on a design, it also doesn't account for some aspects of design that are crucial to interfaces, which more "finished" prototypes can address. For example, paper prototypes don't give the user any sense of the tactile feel that a device will have, or any properties such as the degree of pressure sensitivity. Therefore a lo-fi prototype of something involving the use of a keyboard or a tablet may be useful for obtaining feedback on what's happening on the screen, but not be very informative in terms of how easily users can give the system input in the first place. However, no matter how good the interface on screen is, these physical elements can make a very big difference in the user's experience and how easily he can use the system. Therefore it's also important to determine and test interfaces in a more involved way before finalizing the design too much based only on lo-fi prototypes.
Alexis He - 2/24/2010 16:52:39
I think the advice that really hit home for me is #2: Set a deadline. I often find myself frozen with indecision and feeling as though I have to get everything right the first time. Especially when the author states "Quality comes through iterative refinement", I find this hard to justify based on my past academic experiences where every project design in school is only allowed one iteration. However, given more thought, I recognize that I'm always basing my next assignments on experiences gained from previous mistakes, further justifying the truth in the author's statement.
I am glad Marc Rettig finally put to words what I've felt for a long time now.
Chris Wood - 2/24/2010 16:57:07
Paper prototyping seems like a very useful way to test the usability of your interface. The user can explicitly deal with a tangible version of all the screens that he would scroll through while completing his task. This way, the designer can see where confusion comes in due to poor flow of interface design, rather than mystification by technology.
Richard Heng - 2/24/2010 16:59:48
I thought one thing that should be taken into account is the latency of having the "computer" move pieces in an out of the view of the user. Some user interface changes might be time sensitive. This technique would probably fare poorly on say, testing for a game interface where the game has many reflex based mechanics. Also, having the lofi prototype may also give less accurate results than a hifi prototype because the user is using direct manipulation in this case. This may alter behavior if the final product uses an interface that is not using direct manipulation. This also means, though, that this might be especially effective for interfaces that do have direct manipulation; a touchscreen interface for example.
Conor McLaughlin - 2/24/2010 17:02:54
Can't really criticize where the article is coming from other than to say I agree completely. My group has only been doing hand-drawn sketches for our group project, because we didn't want to invest significant time into simulating or photoshopping a mock-up for a design that is likely to be significantly changed over the course of the design cycle. However, and the article does speak to this, we found it extremely hard to use this lo-fidelity approach when the temptation to have a very pretty and glossy mock-up was always there. We worried not having our color scheme, style of buttons, etc, shown would result in the loss of points, but the recent return of the group proposal put our minds at ease. The author states that sometimes your audience demands a certain level of care or detail, and the idea to use photocopies or overlay pictures would actually have helped us in making our UI designs a little more presentable, while still only taking a minimal amount of time to sketch out. My group probably could have improved slightly there, and this article gives us some very simple tools to do just that.
Wilson Chau - 2/24/2010 17:13:46
An interesting quote from the reading: "To make a broad generalization, interface designers spend 95% of their time thinking about the design and anly 5% thinking about the mechanics of the tool. Software-based tools, no matter how well executed, reverse this ratio." I think this is interesting because using lo-fi prototyping is a really good way to combat this. This is something that I've noticed as well spending all my time doing the mechanics and not spending nearly enough trying to make the design better. Using lo-fi prototyping forces you to work on the design and try to get that right before even starting on working on the mechanics. I think that the design is something in software that gets overlooked and can sometimes impact the the product even more so than the mechanics, because if the design is bad it doesn't matter how good the mechanics is since the user will not be able to use it correctly
Andrey Lukatsky - 2/24/2010 17:13:56
Although I've built numerous prototypes in the past, I've never tried the lo-fi approach described in the reading. For me, I think the biggest benefit of this is that it will facilitate change. "Developers resist changes" is a quote from the article that I definitely agree with - mainly because I've been guilty of this many times. After spending days building a proof-of-concept, you become tied to the decisions you've made, even if you realize they're not the most optimal. My only concern is whether having a human simulate the computer will distract the user from judging the design.
Owen Lin - 2/24/2010 17:15:26
I think that lo-fi prototyping definitely has its place in the beginning design stages of an interface. However, I think that lo-fi prototyping is limited in what it could show about an interface, and that a decent amount of hi-fi prototyping is still necessary especially for highly-interactive or user-input dependent interfaces. For example, I think that something like Rock Band's "singing" mode, where it has a scrolling screen of lyrics and bars representing pitches, would be hard to represent in a lo-fi prototype. I can see lo-fi prototyping be very effective in figuring out the basic layout of an application (i.e. the hierarchy of views and layout of pages), but for truly interactive applications (such as games and other highly "graphical" apps) where you cannot fluidly portray user-interface interaction, lo-fi prototyping may face limitations.
Richard Lan - 2/24/2010 17:20:34
The use of low-fidelity prototypes during the design of a user interface has many merits. Lo-fi prototypes are fast to build and modify, allowing designers to make drastic changes on the fly. Because there is no coding involved when creating such a prototype, developers don't have to think about implementation details, and can focus on the interface's content. Additionally, this practice can save developers a lot of time and money through a number of ways. For one, the materials are fairly cheap compared to the materials required for a hi-fidelity prototype. Oftentimes, the prototype is made with paper or cardboard. Additionally, a lot of time and money can be saved if the designers can design a solid interface before committing to production. Additionally, lo-fi prototyping is useful for getting feedback from real world users of your system, which designers can use to make the system more suitable for their target users.
Even though low-fidelity prototyping is very useful for interface design, I feel that the practice would not find much use in other areas of software engineering. The reason that lo-fi prototyping is effective for interface design is because usability and aesthetic considerations are some of the most important factors to consider when designing an interface. In other aspects of software development, such as algorithm design, the focus is on correctness and efficiency. Lo-fi prototypes have little use in such circumstances. On the other hand, user interface design is supposed to take up 50% of the code base in modern systems, so designing a good interface is an important aspect of software design.
Spencer Fang - 2/24/2010 17:25:54
The idea of "not falling in love" with a design is something that comes up over and over again. The article makes a good point that it is easier for colleagues and teammates to make constructive criticisms on an idea if the designer is not attached to it. Lo-fi prototypes fit into this idea because the amount of work required to prototype a design is much lower than creating an interactive demonstration on a computer.
There are some disadvantages to testing lo-fi designs on users, because it requires such a high degree of human interaction. If the user must talk to a person and state how he wants to interact with the interface, then the user might try to be more concise, and think twice about every action. The way a user interacts with a human pretending to be a UI is different from the way a human interacts with a machine.
Brian Chin - 2/24/2010 17:39:57
The reading for this week seemed to be very useful. The lo-fi prototyping method described in the reading seemed like an excellent way for designers to test designs in a simple, easy way. Lo-fi prototyping takes a lot less time than actually coding something, and its relatively cheap, using materials that can be easily found at any art or crafts store. I am a bit concerned, though, about users who never get over the fact that it is a paper prototype that they are using and not an actual computer program. In industry, there's time and money to interview many people. However, for our group project, we have limited time and resources. Even if a few people get hung over about the fact that the prototype is made of paper, it could seriously hamper our ability to get good input on our design. Also, the nature of our user group (coaches), makes it difficult. We expect them to work under a high stress environment when using our application, and it may be hard to simulate this when testing with a lo-fi prototype. And it would be impossible to test a lo-fi prototype during games as their jobs may be on the line, depending on if they win or lose a game. In conclusion, lo-fi prototyping seems like a great thing to do, but I feel we may encounter some difficulties not described in the reading when doing it.
Dan Lynch - 2/24/2010 17:45:35
The beginning of the article constrasts two methods of development. The first where a design team develops a product mostly by themselves and at the end gets user input for minimal changes. The other team includes many users throughout the entire design process. Then a more specific element of their development is coined as "lo-fi".
The idea is that you can easily (with a kindergarten background) test an interface in its early stages. This can obviously be beneficial in multifarious ways. Basically "hi-fi" prototypes are time consuming to create and build. Also, people can get stuck in what has already been developed, and not focus as much on the bigger idea, such as a complete makeover. This also is a good reason why "developers resist" changes--they have put so much time into their work!
Ok, now for the good part... building a lo-fi prototype. The tools: paper, adhesives, markers, sticky notes, and scissors. Set a deadline and start drawing up models. Once you have your model you are ready to test it on users. The author says it is of importance to a task and user analysis before selecting the users. Also, preparing scenarios and practicing is also good.
I think this is great, except what about hi-fi-lo-fi prototyping? That is, consider the interface builder for example? What if there was a prototyping iPhone app that let you design fake apps? I think this would be much much better than the paper and tape methods. I do agree that it saves time and money, but it also doesn't capture the same feel as using a real computer by yourself. I think the fact that a person acts as a computer completely changes the results. The person being tested will not think of all possible cases to go though, and may not be as comfortable interacting with a person compared to interacting with a computer interface.
Darren Kwong - 2/24/2010 17:45:51
A human playing the role of a computer in a lo-fi prototype inevitably means slow response times. In some interfaces, fast response is a large part of the design and system. Would this skew the results such that they are less useful? If so, how should one work around this issue when doing a lo-fi prototype?
Weizhi Li - 2/24/2010 17:46:51
This ariticle discusses the idea of Lo-fi prototype, which I think we should apply in the design process of our group project. Because our attendance taking apps is easy to apply a paper lo fi prototype interfaces and improve the interface design. The paper interfaces would be tested by a user. However, it's woulde be much more conveniednt to have a flash animation that is very similar to the actual interface that can interact with the user , just as the BART ticket machine project did. It helps give the designer more feedback as it will give much more simulation in the user's experience.
Jordan Klink - 2/24/2010 17:48:15
Just as the author warned, I was very skeptical Lo-Fi prototyping. I should probably try the technique before I criticize it, but the idea is very interesting. With the talk of reverting back to "kindergarten" techniques I of course thought it was silly, but perhaps I would be the one who is truly silly if I choose to neglect the idea. A paper design would certainly be quicker to create and easier to manipulate, but it does have some downsides. Firstly, you have taken your program out of the context that you intend to design it on. There is no longer any computer and virtual environment, when you do Lo-Fi prototyping you're essentially abandoning your primary context. It should be noted then, that it is very important not to lose track of that when designing your idea on paper. Much effort should be made to simulate a computer environment as best as possible. One other downside, partly related to the first, is that not all programmers are particularly skilled at "arts and crafts." Although it is conceptually not the most difficult task, getting it to look aesthetically pleasing is not trivial in practice. When you force computer experts to work on paper, you probably should no longer expect expert-quality work. Low fidelity could be synonymous with "low quality" if such care is not taken to address this issue.
Yu Li - 2/24/2010 17:48:47
Low-fidelity prototyping is a very useful technique in designing an interface. It's basically building a low cost prototype on paper and testing it with real users in order to get fast feedback. The advantages of lo-fi over hi-fi is that lo-fi prototyping is much faster to build and easier to change, it lets the user concentrate on testing the actual user interface and not the color and finish issues, and ensures that a single small bug in the software will not halt the testing of all other aspects of the interface. However, with a simply lo-fi prototype, the users cannot test how fast the program will run and many aesthetic issues are not addressed. But lo-fi still remains a breakthrough for many organizations and cuts the cost of testing and designing dramatically.
Mikhail Shashkov - 2/24/2010 17:49:02
I thought the discussion about negatives to hi-fi prototyping was enlightening. Of course the "more time involved" factor is obvious, but the other things I personally had not thought about. In particular, the realization that testers will focus more aesthetics given hi-fi prototypes rather than things that really matter is rather paradoxical but definitely a good insight.
Jeffrey Doker - 2/24/2010 17:59:39
This article was a bit redundant, but I appreciated that because I agree with its central argument. I have worked on a development team where all prototyping was done on the computer, and it proceeded just as this article would have predicted. Rapid prototyping techniques are clearly used in interface development, but I wonder if these arts-and-crafts methods have been applied in other disciplines. Certainly other design-oriented fields such as architecture or city planning could utilize simple building block rough modeling, but could these models also be abstracted to jobs such as songwriting or even science? I have used rapid prototyping to design math posters and talks, but I wonder if rapid prototyping could be used to organize and manipulate symbols of mathematical theory to understand or even solve math research problems in groups.