Low-Fidelity Prototyping
From CS160 User Interfaces Fa06
Lecture on Sep 27, 2006
Readings
- Prototyping for Tiny Fingers. CACM. April 1994. 37(4): 21-27. Rettig.
Bowen Li - Sep 25, 2006 10:26:15 am
I think this article brings up a very good point when it comes to lo-fi prototyping: people's expectations. Some of the problems mentioned with hi-fi prototyping can be solved by technology: the fact that they take too long to build, or that a bug will crash the program.. those are dependent on the specific implementation. They may or may not be true in the future. However, one thing that I think won't change is what people expect from a software program vs. a couple pieces of paper. The author mentioned people getting too caught up in the details of the colors and the fonts in a "real" program, which invariably happens. That is part of what users have been trained to pay attention to just from using computers everyday. You can't really take them out of that element without resorting to the low-grade pen&paper. By purposely making it not as attractive, the developer can shift focus from the surface level details to the inner workings of the program. Another good point is the one made about progammers getting attached to their designs. I feel like this is true because actually sitting down and coding something has a psychological aspect to it that feels more permanent than drawing something out on paper. By not going to the computer, I feel like the team is also focusing on the interface rather than the specifics of how the code works.
Kang Chen - Sep 25, 2006 10:51:02 am
I feel that I can relate to some of the flaws the article mentioned about high fidelity prototypes particularly a reluctance towards changes and having fewer ideas generated. For instance, I remember a group project I worked on in 61B which involved designing the whole program from scratch. Our approach was to code, code, and code some more hoping that somewhere along the way, the modules would play well together. However, near the end of the project, we figured that the original design to use depth first search and store calculated solutions in a stack was not going anywhere. Yet, we were reluctant to change the design because we already spent an entire week coding it. After much pain and agony, the decision was to scrap more than half the code and redo it using another design that we drew up in a hurry. The problem was that we now only have 3 days to do finish everything. If only we tried to put the project through more iterations of lower fidelity prototyping, such a situation might not have occurred. Secondly, we only had a very limited number of designs to work with and although the project did work in the end, performance wise, it was not up to par with the other groups.
Patti Bao - Sep 25, 2006 11:11:12 am
Rettig makes a good case for lo-fi prototyping, noting that it helps drive home the two laws, "Know Your User" and "You Aren't Your User". The very fact that designers and users differ is justification enough for using paper prototypes and Wizard of Oz tests. Because a design is invariably going to be influenced by the designer's perspective, it will need to be changed to cater more to the user's perspective, and lo-fi prototyping is always easier (and cheaper) to change than hi-fi prototyping. From personal experience, it definitely pays off to get user feedback as soon as possible in the design process, and I've found such prototypes as Rettig described to be very effective when it comes to that. Moreover, lo-fi prototyping can actually be a fun process because, as Bowen said, you don't feel restricted by having to think about how the code works. When we were doing group brainstorms in class the other day, a lot of people really liked using the big post-its, so I can definitely see how people might be excited about starting off with lo-fi prototyping first.
Ramy Ghabrial - Sep 25, 2006 10:33:53 am
I agree with the bulk of the article. If you're going to make changes to your design, you should present it in a manner that is easy to change. This is an extremely pertinent article when it comes to functional interface design. For all big design choices that can be represented using bits of paper, lo-fi prototyping is indeed invaluable for all the reasons mentioned in the article.
Prettiness and colors do have their affordances, however. If nothing else, the user is less likely to be frustrated by a pleasant-looking interface, with attractive colors and sleek buttons and windows and other minor aesthetic design choices. I know for example that I am slightly more comfortable using computers with attractive backgrounds and desktop schemes and animations, and I also know quite a few people who bought macs because the desktop looks cool. The value of interface prettiness should not be underestimated.
David Hoffman - Sep 25, 2006 12:30:34 pm
Rettig's paper on low fi prototyping is very interesting angle of testing an interface. I like the idea of testing the logic of the program with a person running as the logic engine instead of a computer. In a low fi software protype, if the user behaves in an unexpected fashion, the software could crash, and then the whole exercise would need to be restarted. Using the paper interface, the computer logic person will be more robust than a crude software program and it will allow the team to look for unusual user reactions that need to be controlled in the software. I do think that the team of four people with a video camera rolling would be a bit much. If I was a user I think I would find the camera irritating and I would be less likeley to speak than if there were no permanent recording. I think the main message of this is to just do a quick and dirty test on the people who will use the software so that the problems appear early rather than later.
Simon Tan - Sep 25, 2006 02:11:04 pm
This article follows from what we really emphasize in this class - the interface design cycle, and many iterations of it. We need lots of feedback, and we need to adjust prototypes quickly in order to get new feedback. The article made it very clear that the more iterations of test users we have, the better. Although lo-fi prototyping is not a new concept, it does seem to fade into obscurity when we now have such comprehensive prototyping tools. People will prototype in Macromedia Flash, and I feel even that is a time-heavy commitment to a design. These tools, more likely than not, just encourage over-obsession with minute details in interfaces, which will probably be criticized by picky users anyway, as the article states.
If nothing else, lo-fi prototyping will be lots of fun, and encourage more creativity than a hi-tech prototype will.
Tabassum Khan - Sep 25, 2006 05:20:11 pm
The most attractive feature of a low-fidelity prototype is its low cost. Its a quick and early mockup of the system which enables quick feedback from the user. This in turn helps the designer to detect and correct error at practically no cost. This method also promote iterative modeling which solidifies the design before the product is released. In my opinion, this concept will not be universally accepted because of the approach that people take towards getting a work done. Many are firm believers of the theory of learning by trial and error. For example, I have encountered quite a number of students who, given a programming task, cannot wait to code. They cannot even dream of "wasting" their time thinking about or designing the solution to the problem they are attempting to solve.
Rayhan Lal - Sep 25, 2006 07:18:44 pm
Rettig provides strong support for low-fidelity prototypes. The paper illustrates the “sunken-cost effect,” that is, the more you invest in an idea the more apt you are to continue investing in it. This is certainly a far better model than what I have seen in the past. Software companies used to make the end-user sign contracts that this button would be here or this edit box there. Even if the user did not like the result they approved every design decision, so it left little room for complaint.
Robert Taylor - Sep 25, 2006 08:05:41 pm
Experience has taught me that lofi prototyping is important. In tutoring for Java, a student will give me a spec for a program they want; even if, in the end, the program could not be made exactly to the spec, the student will often have more (or will only be) about something with the fit and finish rather than the fact that a significant part of the spec couldn't be accomplished.This experience falls in line precisely with what the author mentions: "Reviewers and testers tend to comment on fit and finish issues". Of course this makes sense as it is the first thing that catches their eye and requires the least amount of thinking. But it is, arguably, the least important part of the project: it really doesn't matter how good it looks if it doesn't do what you want it to. That's why lofi prototyping is important.
I'm curious as to whether we will get to try testing lowfi prototyping with users. Given how much revision has been involved just after initial interviews, it seems probably that the interface itself will have a lot too. Prototyping with users seems like it would work well with our sized groups too-a group of four is enough for the greeter, computer, note-taker, and camera operator.
Melissa Jiang- Sep 25, 2006 11:55:53 pm
I also agree with the article in many aspect. Lo-fi prototyping does seem very important and helpful. Many do simply jump into major projects without first planning ahead and end up with disastrous results. When building an interface that users will use, it is even more important to plan ahead. Lo-fi can give the design team a general idea of what users want or whether the system is currently working or not. However, I think I can see what drives people to skip this step. They may fear not completing the set project in time. Implementing it may already take a huge chunk of time, the team may fear that if they put that much time into creating many lo-fi iterations, their time is cut even more short.
I feel like I want to try out lo-fi prototyping with our project but I also fear the limited amount of time we have as well. To be able to find users willing to participate and spend that much time in the testing may not be easy (especially since Rettig suggests staying away from family and friends).
Patrick Rodriguez - Sep 26, 2006 12:25:19 am
What I like about lo-fi prototyping is that you get freedom of design in areas where it matters. Sure, you don't get to play with the colors and fonts and the exact x & y coordinates of widgets, but you get almost complete control over the important parts of the system. For example, you might have a very unique widget that isn't implemented in your UI library. You could spend the time to code one up, or you could make one on paper and simulate how it would work. If it isn't a hit with the testers, then all you've wasted are a few sheets of paper, not hours of coding something that won't be used. Another big plus is that at the end of the design process, you have all these paper prototypes to base your hi-fi prototypes on. At this point, you can go wild with choosing colors and fonts now that the core functionality of the design has been approved.
Robert Held - Sep 26, 2006 03:13:54 pm
The basic emphasis of this article is that one should not get ahead of oneself while designing an interface. Although more time-consuming, it is easier to implement an interface once you know what it's supposed to look like than to quickly design something people will want to use. The small investment of time put into lo-fi prototyping is a straight-forward way to ensure that you have a solid plan before jumping into the implementation. The ease with which one can change the lo-fi prototype also demonstrates its greater utility than a hi-fi prototype.
Tak Wong - Sep 26, 2006 03:39:59 pm
I also think the lo-fi model is useful in initial design. There are always sudden problems in technology like not having wireless connection or the program just won't load up. There's much more reliablity in paper prototype in that sense. Also, it is possible to add things the user want on the fly on paper if the user has the patience. A simple working on-the-fly design shouldn't take more than 10 minutes to construct. Nonetheless, some people (especially the ones who are not into technology) would still think the paper interface is less attractive and may look like the company doesn't have enough money to create a real interface. There are still a lot of people out there who thinks making a minor change is as easy as erasing a pencil mark and writing something back in, and this should also hold true for computer interfaces, but of course, we all know that takes much longer than expected.
Sean Carr - Sep 26, 2006 04:01:46 pm
I really liked this article. I hadn't really heard anyone go into this level of details about how to do effective prototyping and I know I will be employing these lessons on my Software Engineering project this week! One nice thing about lo-fi prototyping is that it is very cheap, making it usable by students, start-ups, and other financially restricted group. The idea of building “models, not illustrations” seems like an obvious approach but I had never seen anyone do it and out of habit I think most people just make lo-fi prototypes as a serious of illustrations similar to storyboard sketches. As I learned from our contextual inquiry, I think one of the harder parts of lo-fi prototyping for students to accomplish is getting actual users to sit down with you and use your prototypes. Usually students don't have many incentives to offer and often the customers are busy with their own work. I really agree with the idea that rapid iteration with users involved at every step is the way to go though.
Jason Shangkuan - Sep 26, 2006 07:05:29 pm
I think this article is interesting because it illustrates a point about making trade-offs during the design phase: the balance between concerning yourself with the finished product and the overall use of the product. I think that in order to be successful many iterations are needed to help fine tune the process or program. However, this can detract from the overall goal of trying to achieve a finished product in a constrained period of time. A compromise is needed between lo-fi and hi-fi prototyping because if you start with lo-fi, the user and target is the overall abilities and usability of the system. After many iterations of this, then utilize hi-fi by employing high level programs to achieve the fit and finish desired. Combining these two concepts will allow for a successful product that has both appearance and functionality.
Andrew Tran - Sep 26, 2006 07:28:58 pm
Low fidelity prototyping i think is a good process in designing interfaces. However, this system of design a little, test a little, evaluate a little, and redesign has its draw backs. What if after redesigning the interface many times the test subjects start to find it more difficult, or the customers are just spontaneous and does not like the new interface? You can't be too sure about your test subjects. I personally think designing the final design then testing is much better. The only downside to this process is the potential of a big bug that would destroy everything once fixed. But if the programmers test for bugs repreatedly before the final product, then ideally this problem should not arise. Purposes of testing would only be to change the interface to be more human friendly.
Michael Moeng - Sep 26, 2006 11:14:19 pm
I think one of the biggest challenges of low-fi prototyping is in how accurately the prototype will reflect the final product. It is easy to have a screen with buttons that go to other screens, but more difficult is the implementation of the scroll bar described, or minimizing sub-windows, or other tasks that many modern GUIs, armed with more graphical power each year, can display. For our project this will not be as big of an issue, but it is still something we must consider.
Julius Cheng - Sep 27, 2006 12:15:32 am
I liked how the article addressed the subtleties of the actual lo-fi testing process. When I read that one shouldn't use family members because of external biases like the desire to please, I thought, "wouldn't regular users feel funny using this interface while being watched by three people and a camera?" The paper later told me that we should remind the user that the interface is being tested and not them. That's the sort of detail that I liked about this article - it didn't just talk about how designers think about the process, it talked about how user's feel about it too.
I too am guilty of working on hi-fi more than I should be. Often when making a program I like to dive right in, thinking that I can always think of things to change in the midst of implementation. Of course, this has been pretty time-costly in my computer science assignments. I think it's because I don't feel like I'm doing productive work when I'm only planning or making lo-fi prototypes. This perhaps is one of the traps that real user interface designers fall into - the pressure to have an impressive piece of work to satiate one's own desire to text productive or pressure from "higher powers". Lo-fi prototyping is an investment that pays off in time and quality, and all UI designers would be wise to use it.
Utsav Shah - Sep 27, 2006 12:19:48 am
Lo-fi prototyping is extremeley important and necessary for a good interface. I think it provides lots of flexibility as one can easily go back and change if he/she needs to. Another good thing about lo-fi prototyping is that you're working on a paper which gives you lots of room for improvement. I can relate the idea of lo-fi prototyping to other cs classes where design documents and test cases are need to be done before the actual implementation.
Hiroki Terashima - Sep 27, 2006 12:33:02 am
This article and lots of the posters above advocate lo-fi prototyping, and I don't disagree. As the article points out, lo-fi (as opposed to high-fi) allows you to be more flexible and creative. Figure 2 suggests using a camera, a note-taking person, a facilitator, and a "computer" in a testing session with the user. I've gone through one like this (as a user), but they used voice recorder instead. The important thing here is to record everything that happens in the session so that you don't feel the pressure to write everything down and end up missing important feedback. Asking users for permission to use the recording devices is also important. The article also mentions setting a deadline to facilitate your progress. I think that setting a deadline is one of the hardest things to do because we all have different schedules and lots of unexpected things come up in our lives.
Vahe Oughourlian - Sep 26, 2006 11:44:59 pm
Much like IDEO, the story this article trys to tell is that you can look silly, act silly, have fun, yet still get some work done. It's the materials of the lo-fi design that really turns off the hi-fi people that most designers and computer scientists, like ourselves, are. I was somewhat amazed at the observation that people believe they are taking some sort of "test" that they have to answer for in some way; perhaps it should be made more obvious to the test subject that they are helping the designers. An added incentive, if you will, much like the food and fun things that people give out to get testers to come to these evaluations. I was somewhat disappointed in the lack of cons that the article contained. Though it pointed out some pitfalls to avoid, like making the user feel one way or the other on a subject, it didn't quite go into the difficulty I see in preparing an interface that you expect to use and having a single person run it. I was playing with the idea in my head of doing Microsoft Word as a lo-fi prototype, or even Firefox, and the sheer complexity seems to make an effective lo-fi prototype much more difficult than this paper makes it out to be. Perhaps some kind of middle ground, where one need not enumerate all the functions, but examples of the functions. Unfortunately, that way you may miss an interaction between the user and the program that may need some more work to get working properly.
Natalie Nguyen - Sep 27, 2006 01:35:14 am
I agree that there runs a danger with a "hi-fi" prototype in that people become more concerned with aesthetic details than they do with other, more pressing issues in navigation and general ease of use. I was charged with designing a UI during the summer. I didn't have much guidance and so it wound up feeling a lot like I was "playing by ear." I would work on the interface and back-end functionality simultaneously, but the majority of the time would receive feedback on only certain details in the interface (header pixel height, font sizes) that were largely negligible compared to other things (navigation of data!).
Tony Yu Tung Lai - Sep 27, 2006 01:46:34 am
In my mind, I have always thought that lo-fi prototyping is a better method for prototype because of the fact that it consumes less time and is easy to make and change. However, I've never quite thought of it as a way to force users to think about the concept of the design instead of the details. Now that I think about it, may be the lack of criticism of my GUI (from summer) in the design level might not be a good thing, since my protoype was hi-fi (on computer). ..
Cheng-Lun Yang - Sep 27, 2006 01:55:40 am
I agree with that using lo-fi prototyping makes the engineers less focused on making the interface fancy. Even if the engineers want to make the design fancy, it is easier to do than writing codes. Also, setting a deadline is also very important. From personal experience, I always work faster when project deadlines are approaching. It is the nature of humans to work better and faster under some pressure. When the assignment was first assigned, I usually thinked too much and tried to read every chapters taught so far in lecture to see if there is anything helpful for my project. Then as the deadline approaching, I realized that i could not finish reading so i started working on the code right away without reading every document. On the other hand, using paper and pen to draw out one's idea is the most natural way to brainstorm. Every little kids learned how to draw first before they could even reason or write. Drawing is the innane ability of human beings. It is important that engineers use that ability in order to get the most creative ideas.
Edward Karuna - Sep 27, 2006 02:31:03 am
Rettig puts forth a good case as a strong proponent of lo-fi prototypes, but what I find most telling about his ideas and examples is that lo-fi prototyping implies a great sense of mutability, both to the tester and the builder. This feeling of mutability disappears as the prototype progresses, as it becomes more hi-fi, such that near the end of the production cycle, it is hard to change much. Starting out with a hi-fi prototype, as Retting points out, kills the mutability of the idea very early on, stunting growth and imagination.
David Eitan Poll - Sep 27, 2006 03:02:19 am
I think that this article points out an important goal to consider in any design process: break early. It's far less expensive to deal with changes when problems are caught at the beginning of the design phase. Less work is wasted, and there is far less rigidity in the design at that point. As the design project continues, momentum toward the goal is built. Problems with an interface may mean taking a step backward to fix them. At this point, one must overcome the inertia of the project, which becomes more and more difficult as time goes on. As much of a pain as it may seem at first glance, nitpicking early on can help maintain productivity in the future.
Maksim Lirov - Sep 27, 2006 03:22:31 am
I agree that low-fi prototyping provides invaluable feedback and allows for more iterations of the design to be made in a short amount of time. It is very unlikely that the finished product will arise from the first iteration of a design, so the more iterations can be tested on the user the better the ending desing will be. One thing to note is that the person playing the part of the computer needs to be very familiar with all the functions of the application/system or else the user could get confused or the feedback may not be as valuable. Furthermore, while a low-fi prototype is effective in perfecting a design, I believe that at some point a hi-fi prototype needs to be made. As Rettig says, It is true that many users will concentrate on commenting on the aesthetic appearances in a hi-fi prototype, but I believe once the core ideas of the design are established with the lo-fi prototype, it would be a good time to the lo-fi prototype ideas into a hi-fi prototype model.
Jonathan Yen - Sep 27, 2006 03:20:21 am
This article does a pretty good job of distinguishing between lo fi and hi fi prototyping. Lo fi prototyping, it seems, involves a substantial amount of creativity, and it appears to be rather effective. Lo fi prototyping sounds like a pretty good idea to try out (provided that there isn't a hi fi prototype already).
Qingyun Tang - Sep 27, 2006 03:50:14 am
The article follows exactly what we are emphasizing in class. The lo-fi model is the ideal model that we want to achieve. Right now, we are doing things like story boards to enable us to quickly make up a working interface. This is a good start, because more touch-ups will very much improve the final product. Working many of these semi-final products with the people who are actually going to use them is very important. They give us ideas what to put in the interface and what not to. There are always things that you assume people know intuitively but not.
Huangnankun - Sep 27, 2006 09:17:50 am
The author starts off by comparing 2 development process, one which takes advantage of paper prototyping and one which does not. Later on in the article, the author talks about the ways in which paper prototyping can be carried out.
While I agree with most of the points he raised, there are a few things which I disagree/find misleading. Firstly, the whole first part of the article revolves around the advantages of paper prototyping vs the traditional development model in which developers spends “weeks and weeks” discussing certain features. The implicit assumption is that the traditional development model will take just as much time, if not more than the paper prototyping model. However this is not always the case in a real life development environment.
The actual construction of the interface with paper material might not take a long time, but the time it takes to find users, conduct the test, collect data, analyze results, draw conclusion from the analysis and make changes to existing ideas is a long and laborious process and sometimes the cost of doing this is simply not worth it.
Paper prototyping also has many limitations. For example, paper prototyping wouldn’t work well for a lot of applications which requires manipulating a lot of data. This is because its impossible or would take a lot of effort in order to print those data out in a paper form. Even so, the user might not be able to interact with it directly. Paper prototyping also fail badly when it comes to media rich application which has video audio elements which are manipulated upon by user.
The author also does not mention intermediate level prototyping tool such as Macromedia Flash and HTML, which has much of the advantage of paper tools but can give users a much closer experience of the final finished product.
Eric Yoon - Sep 27, 2006 09:54:20 am
The concept of lo-fi vs. hi-fi prototyping is certainly a very interesting one. My initial reaction is one of slight skepticism -- for most digital interfaces, anyway, it's quite easy to build a web site that moves from page to page based on simple hyperlinks and buttons. Furthermore, although there may be some front-end effort in setting up the basic platform, once you have that done it can often be quite easy to add small revisions in response to user input -- perhaps even faster that it would be adding the same revisions to a paper mock-up. Lastly, using a computer interface -- with its attendant keyboard, mouse and display -- is a useful setting for a more authentic user testing experience, if you are in fact testing a computer program, web site or digital interface. I would think that simply pointing at pieces of paper may not be quite the same. But I think I'd have to see lo-fi in action to really judge it. And I'm sure its relative strengths increase if, for example, a hi-fi interface cannot be modeled using HTML and is difficult or expensive to create.
Leo Chen - Sep 27, 2006 10:06:19 am
The idea of just moving pieces of paper around to simulate a computer makes me slightly skeptical. When a user uses a computing system, they have certain expectations, expectations that may be hard to meet using a low-fi prototype.
While I do see the advantages of a low-fi system, there are limitations that paper drawings pose. The limitations may skew results and user reactions which would result in a flawed final product.
Heung Tai - Sep 27, 2006 10:37:01 am
Paper is such a robust, tool! It's much faster to draw an interface on paper than on computer screen. Using cheap material and get the task done fast is the main point of the lo-fi. Having this kind of prototype is a very efficient wayt o get the product out to testing quick. Most of the time, programmer can estimate the response time of certain programs, computer response. They can also implement many alogrithms without a problem. Their main difficulty is how people can react with the programs. Using paper to make prototype is a way to abstract the implementation part (which for programmer is easy, for most program), and deal with the difficult user interaction part. This is exactly the idea of divide and conquerer.
Ming Huang - Sep 27, 2006 10:28:20 am
The column on lo-fi prototyping basically says it all. We devise the interface, make it up on paper, show it to the user and tell them to use it like its real, and compile results. I do have to wonder why after all these years someone have not made it easiler to do these rapid prototyping and testing of new interfaces on the computer directly. When it comes to modifications, they can be done by directly replacing the controls and editing that control's action so it points to the same thing. Rearranging controls and dialogs should be as straight forward as drag and drop, and modify a link or two. Standard buttons, menus, and dialog templates are available for some of the higher-level IDEs. I guess the word "lo-fi" restricts the process to be about architecture and feel, so that we should not show test subjects any hint of a formal, finished product on the interface.
Yimin Yao - Sep 27, 2006 10:24:00 am
Th article does a very good job at presenting the advantages of using lo-fi prototyping. And I think lo-fi prototyping is a very essential part of interface design that prevents the designing team from wasting time on coding interface features that might not be desired by the users. From the little interface face designing process we had for group project, I can easily see how first round interface designs are bound to have many flaws that are invisible to the designers because they are so caught up in the functional features of design. Also, since they know the everything there is to the design, they usually are able to skip mentally the flaws in logics of the operational flow; while a user new to this interface and its functionalities must perform tasks step by step based on what the interface provides, thus more likely to detect any missing link or error.
I think using screen shots of windows interfaces in producing windows based prototypes is beneficial because then you will be able to see whether the conventional icons are sufficient for regular windows users navigate through the new interface efficiently.
Scott Friedheim - Sep 27, 2006 10:51:04 am
Using low-fi prototypes is very useful in many ways as outlined in the article. However, I have to say that producing a quick prototype in web interface, as some people already mentioned, is just a more professional method of presentation. Using this slightly higher fidelity prototype allows the users to be interacting with the prototype in the context it is supposed to be used bringing attention to details that might otherwise be missed if working with, say note cards. Also, by working with a computer prototype the users actions can be more accurately and quickly managed. For example, users actions in navigating through an interface can be tracked and organized into a database for later analysis of the design. Using recording devices is, of course, absolutely essential when conducting these user testing because of the fact that going back to review them proves invaluable.
Andrew Hao - Sep 27, 2006 09:47:32 am
I agree with Rettig's suggestion to make the test user's experience as clear, honest and straightforward as possible. Even in the process of contextual inquiry this week, I noticed that my user tended to be very self-conscious of being watched and observed. How much more stressful is it for the new user, who must match up with the stress of multiple observers, a camera and the expectation of successful development of a new interface! Thus I can understand why Rettig suggests ice breaking, refreshments, and lots of reassurance to the end user that his or her results are confidential.
Joe Hart - Sep 27, 2006 11:22:02 am
Lo-fi prototyping is an obvious good idea. Working with pen and paper allows designers and users to communicate in a medium that is understood by all and can be easily manipulated to arrive at a great design. However, this type of prototyping might miss some aspects such as flow, click ability, wheter an application looks good on a computer monitor, etc. When using paper tasks like clicking dialoge boxes become a drudgery and may be unfairly dismissed or worked out of the project. The designers and users have to keep the suspension of belief going in the lo-fi stage and now everything can be handled this way. A possible idea is a computer based prototypeing like flash or someother storybrarding tool that captures more of the environment the end application will be in.
Jason Lee - Sep 27, 2006 11:17:42 am
This article does a good job of explaining the advantages of lo-fi prototyping. The concept of lo-fi prototyping has a nostalgic appeal to me, as it harkens back to the days of childhood when we would make models out of simple items found around any classroom. At the same time, despite being so archaic, it is a powerful tool in testing out what users will like and dislike about your proposed interface without putting in the many manhours it would take to perfect the interface, only to find out that users hate everything about it! It is a great way to test out user's needs, while also jogging the brain's juices by allowing developers to break out their artistic skills with pen, paper, markers, scissors, glue, cardboard, colored pencils, etc. Something about this article was written in a way that seemed kinda chlidish and not as professional as some of the readings we have done so far, but it got its point across very well and that tone seemed to reflect the childishness and not-as-professional-ness of lo-fi prototyping.
Michael Udaltsov - Sep 27, 2006 11:39:04 am
The reading touches on an important concept: "Know Your User," and "You Aren't Your User." A lot of interface design problems arise because the developer makes the interface without getting feedback from real users. It appears logical and well designed to the developer, but once released to the public, it's a failure. As the article points out, it's important to step back from the initial design, and allow real users to comment on it and help improve parts that they see difficult or have misunderstandings about. Lo-fi prototypes are shown as a great tool to do this. However, at the end it's mentioned that "if you already have a working high-fidelity prototype, it probably isn't worth abandoning that course to switch to lo-fi." I would say this is true for cases where the basic structure is already solid, with only minor improvements left before the design is completed. But if testing shows that there is a large problem with the existing prototype, I think it would still be more beneficial to switch back to lo-fi in order to quickly develop a better solution instead of wasting time re-developing the hi-fi version.
Tom McClure - Sep 27, 2006 11:34:55 am
One of the coolest benefits of Lo-Fi prototyping is getting developers out of their cubes for extended periods of time both before and during a user focus session. Developers will feel better about the project not only because their design has a much higher chance of being accepted and even praised by the users but because the entire design process is more fun. You get to play with cameras and pieces of paper, which can be a lot more fun than sitting isolated at a cpu. Nice morale boost. Being a good observer takes practice, though -- in our contextual inquiry, I found it very difficult to keep quiet and let the user interact with the system.
Alex Wallisch - Sep 27, 2006 11:03:40 am
One factor that unfortunately gets in the way of lo-fi prototyping is that many designers feel that such work is "beneath" them. As mentioned in the article, many of the skills necessary for lo-fi prototyping are those that you learned in kindergarten; however, many people - especially developers - often assume that because they are older than that, they shouldn't be using those skills anymore. It seems that one of the most important skills for designers is the ability to be silly and think like a child from time to time, and it's a pity that this is so difficult for many people to do. A slick interface using flash is quite impressive, but there isn't much that it does that couldn't be accomplished in a fraction of the time with a piece of paper and a crayon.
Antonis Mannaris - Sep 27, 2006 11:15:56 am
Lo-fi prototyping seems like a very useful tool. Previous posts mention that a web interface will be more professional and effective. I disagree! First of all, the way I understand it, you are not supposed to guide the user step by step. So potentially the user may have to "find" her way around, often clicking on the wrong button. If your demo is built only to simulate the correct steps, the user will be even more confused. The alternative to draw all the possible scenarios is just too time consuming using any software. Paper interfaces on the other hand, is much faster to create. Even if you don't create everything, the user will accept more readily a claim you make. For example, if you select this an error message will pop-up. With a computer design, users tend to expect more, so if something is not working they will be confused. I also think that it is important to form the impression that you are indeed at the beginning stages of design. Just like the article says, a paper inteface forces the user to focus on control rather than looks, so the feedback will be what the design team needs at that point.
Eric Vacca - Sep 27, 2006 12:07:18 pm
Aside from the number of design iterations increases, I thought the most beneficial part of the lo-fi design technique is that as a result of the many iterations, it keeps everyone involved. Often times in a group, people do get attatched to ideas they think are good and they have put a lot of time into. Lo-fi design and the resulting design iterations make the project into a group idea, and no one person feels ownership for it. The group can then be unbiased and make decisions that will most improve the product or the user experience.
Roland Carlos - Sep 27, 2006 12:05:05 pm
Why aren't we teaching this doctrine to the lower division CS students? I've read in other comments horror stories about projects they worked back in the 61 series that could have been easily made a lot easier if they knew some of the practices that we've been talking about in class.
This is another thing that just makes so much sense. While a lot of us want to try and develop a prototype of our product before we actually release it, we think that "prototype" means a high-level/almost-completed version of your product. It's probably the age we live in, everything is digital and full of technology, there's just no room for paper and pen today.
That's far from the truth. Too much work comes from the design process. It makes perfect sense to start low-level and work your way up. It's cheaper, easy to build, and easy to explain to potential users. Plus, any problems that we find out here are easily solved (as opposed to once we have our "almost-ready" build in place).
I'm surprised that it seems to take a large group effort (i.e. many people have to play a role in the testing process with a user) to get it off the ground, but the benefit to me is obvious. If everyone specializes, then they can achieve their task to their maximum ability and help the overall testing process.
Michael Mai - Sep 27, 2006 12:14:29 pm
Aside from the fact that its cheap, lo-fi prototyping is an excellent means of introducing the whole team to the overall concept of the project. Due to the quick iterative nature of the design process when using lo-fi, each member of the team can take a different role during each cycle. When I work on most projects, I know most of the things that are going on and how most things work, but there are just some aspects that I leave to other members of my group. I feel that lo-fi prototyping allows each member of the group to smooth over the entire interface and get to know and understand all aspects of it. Although it may be slower, if each member gets to play the computer role, there is likely to be more inputs and updates because of everyone's different points of view.
Yen Pai - Sep 27, 2006 12:29:04 pm
Low fidelity prototyping with paper is great way to quickly express ideas and get feedback. However, in many of our contextual interviews, project constraints like time and the need to "look professional" in front stakeholders often proved to be a bit of an obstacle and or deterrence to this particular stage of the design cycle. Paper and hand-drawn prototypes were often used internally to bounce ideas around but a true low fidelity prototype was rarely presented to clients or target users. I do believe in the process, however, and do believe that perceived constraints like lack of time can be overcome if low fidelity prototyping is done in a focused and selective manner.
Siyan Wang - Sep 27, 2006 12:32:59 pm
This seems like one of the most fun and creative parts of the design cycle. Like Rettig wrote, hi-fidelity is often limiting, not only in the attention to detail that will invariably pop up, but also, I think, in its lack of creativity. Since hi-fi models are hard to change, people often stick with one interface and are unlikely to change it, even if a more creative and novel solution pops up. With the many iterations of lo-fi prototyping, one can add and modify many more aspects of the interface, leading to more creativity. Besides, creating such an interface and playing "computer" just seems pretty fun.
Siu Pang Chu - Sep 27, 2006 12:27:21 pm
The benifit of paper prototyping is allowing designer to " to demonstrate the behavior of an interface very early in development and test the design with real users." In one of our project interview, a designer mentions that once the project gets into the coding part, she does not want to make any changs in the interface design. Because It takes a long time to modify the code even a little change in the the interface. The lo-fi testing seems interesting. 4 people act as different roles, greeter facilitator, computer and the observers. I like this paper testing idea because drawing those prototype in papaer can be really fast. Make change and run test again can be done in just a few mintues.
Dexter Lau - Sep 27, 2006 01:03:01 pm
This article very nicely presents how lo-fi prototyping can be used to put together a concept with the use of visual aids. This is all well and good for aesthetics, but it limits the true capabilities of the program. Moreover it obscures what is in fact important and what isn't: a button here may seem useful, but when a user is actually going about their business, that button might noy be in there locus of attention. THis brings us to the important point that you should know your user well. That is what the entire program is built for in the first place. Tying it back to watching the user in their true environment, you too should take away from that and translate it into a user-friendly interface. When planning for it, the lo-fi approach is good to be modular and flexible. THis lets you change things as they come along, and they will.
Randy Hilarbo - Oct 01, 2006 06:56:23 pm
I think that the technique of lo-fi prototyping is very effective. It is cheap, quick and offers similar, if not better, testing results as hi-fi prototypes. I do have experience evaluating hi-fi prototypes and I sometimes hesitate on commenting against features which I know that designers spent a lot of time on. I usually just end up evaluating the functionality of the software instead of its interface. Just like what this article conveys, the quality of hi-fi prototypes can intimidate testers preventing them to judge an interface without bias.
Lo-fi prototyping promises a good design interface. To make this technique the most effective, really good prototypes should be created. It should be such that it almost resembles a hi-fi prototype. Testing might be a little difficult at first since the user, not just the designers, need to be comfortable with this process. Also, the number of people present during the test might intimidate the user.
Chen Chang - Oct 01, 2006 08:16:13 pm
Prototyping for Tiny Fingers: Comment 1
After reading this article, the problems with hi-fi prototypes stick out like a thorn: it takes too long to build and change, cost of equipment and software and overall funding, developers may resist changes because its hard to implement and most will feel reluctant to change something once they have already grown attached to what they wrote. Take for contrast the other side, redrawing a sketch that took a mere couple of hours is not so difficult nor costly. A software prototype can set expectations that will be hard to change, thus initially promised features may have a problem being implemented in reality later on and when stripped away from the final product, its a disastrous scene for the targeted users. Bugs in hi-fi prototypes can halt progress to a stop as the testing team would need to work overtime to try and resolve the issues before the developers can continue in their work.
Prototyping for Tiny Fingers: Comment 2
"Lo-fi prototyping works because it effectively educates developers to have a concern for usability and formative evalution, and because it maximizes the number of times you get to refine your design before you must commit to code." I couldn't have said that line any better as it provides a summary of WHY LO-FI. Lo-fi prototyping requires little more than kindergarten skills so no one on the project team should complain about it being too difficult as it essentially requires large paper and office supplies and thats all. It provides distinct advantages such as demonstrating the behavior of an interface very early in development, testing designs with real users, quick to put together and VERY cost efficient, interface sketches or storyboards - a picture is worth a thousand words - as the users will be able to get a glimpse of what the interface will look like.
After all, I think lo-fi prototyping can be summed up as a screenshot on your monitor of what you hope your intended project will look like in its final stage made out of paper and cutouts and written in pens. How often do adults and students our age hold a crayon and draw on butcher paper? At the very least it would be a very good change of scenery.
Sung Yi - Oct 02, 2006 03:42:48 pm
Comment1:
The concept of Low-fidelity is very useful in that it lets the UI designers to brainstorm rough ideas and come up with various rough drafts. Many people like to directly go into implementation stage (coding) without any prototypes. This seemingly might save some time; actually, it will be more time-consuming when some editions and corrections on the structure of the program must be done.
Comment2:
One problem the UI designers might experience with is being confused on the boundary between the low-fi and hi-fi prototypes. People usually concerns for details when thinking about general outlines. One merit I want to mention about the low-fidelity prototyping is that this helps the group members to be totally involved, just like the one done in class today.
Charles Lee - Oct 02, 2006 10:22:35 pm
Comment 1: There is much ongoing debate about the best ways to design things. From the old school "waterfall" top-down planning, to the quick-iterative "agile" design process, to many hybrids in between, it seems that two truths emerge. The first is that good design takes a lot of _properly directed_ thought, and the second is that different situations call for different design methods. There is no single silver bullet. That said, in absence of a _good_ UI designer, an agile design process is likely to cut down on design mistakes.
Comment 2: This agile process may produce near-optimal results, however, sometimes, the customer wants a solid agreement about features available (and accessibility details) before they are willing to commit to paying for the production of a product. This low-fi process one-ups the agile process by providing even easier and lower cost iterations. Hopefully, the user's opinions stay the same until the end of the project.
Yang Wang - Oct 03, 2006 06:18:50 pm
When I was reading this paper, my first reaction was "are you serious?". Doing user testing on paper seems to be a very lucrative idea. But as I read along, this idea seems to be more and more plausible, and even seems to be very effective.
One of the key point that the author addresses is the main problem with testing for a good design: "You can't evaluate an interaction design until after it is built, but after building, changes to the desing are difficult". This is one of the major dilimma in programming and become a bigger problem when we are dealing with interface design. I think one of the major benefit of having a lo-fi prototype that the author didn't mention is that it allow the developer to be more creative and more willing to trying out new things. Because they won't have to be contrainted by the thoughts that "oh no, this is going to take too long" and allow them to expand their thought and come up with some amazing ideas, even if they are not feasible. For it is much easier to start with something extrememly difficult and complex and cut it down rather then start with something simple and ty to make it better.
Another benefit that a lo-fi prototype brings is productivity. Because a lo-fi prototype does not require programming. Thus, it is perfectly feasible to have someone with no experience in programming to come out with the prototype, and the engineers just have to make sure that it is doable.Thus, the programmers can be freed up to develop some backend parts that doesn't not have a direct connection with the UI. Both can be going on at the same time and productivity can go much higher.
Yang Wang - Oct 03, 2006 06:19:18 pm
Now let's discuss some of the potential problem that a "lo-fi" prototype that may have:
1. The user may think it is strange and may be weird out by that. The fact tha we are having a paper prototype to test with the user, and having someone to be the "computer" may give the user some extra pressure that didn't normally exist. They might have the thoughts such as "are they messing with me?" or simply "this is stupid!". These thought may lead to perform certain actions that they will normally not perform and will lead to certain biases.
2. Depend on the developer's skill, the "lo-fi" prototype may just be as costly as the "hi-fi" prototype. With so many programming tools today, coding is not nearly as difficult as before. The programmers don't even have to write everything. Creating a hi-fi protoype may just involve a couple hundred lines of code and with the help of certain design toos. But a paper prototype can be difficult and we need to have one copy for each of the testers we have (for input information). Thus, if we are testing on a large scale, the "lo-fi" prototype may turn out to be more costly.
Aleksandr (Sasha) Ashpis - Oct 03, 2006 09:05:54 pm
1) Using paper first before implementation is a great idea to make sure you get all those little kinks out, before you actually start implementing. I completely agree that it is a lot easier to change something while its on paper then when it is in production. They have long shopping list of things needed to get the lo-fi of the ground, seems like a half a day of shopping, but still better than 4 months of coding.
2) My personal experience outside of this class and when working with my group is that a whiteboard works much better than paper, because manipulation is faster and easier. But once a design laid on white board is finished and agreed upon, it is transferred to paper. I believe this approach would work great for designing an interface. The approach given is very scientific and professional, because there are a lot of roles that one would not ordinarily seem necessary, such as a greeter. But a greeter would make the user feel more at ease and less nervous
Jae Chang - Oct 04, 2006 11:23:16 am
Comment1: The low-fidelity prototyping, building prototypes on paper and testing them with real users, seems to be an excellent technique that dramatically increases quality and speed in the early stage of software development. The benefit of the lo-fi prototyping is that it allows developers to demonstrate the behavior of an interface and to test designs with real users. I agree that testing with a slick software prototype tends to users not to focus on controls, terminology, or basic metaphor but to focus on look-and-feel. As the result, by using a slick software prototype, developers tends to more focus on choosing colors instead of coming up with new ideas. Even if there are some downsides of the lo-fi prototyping, I believe that the technique is very useful in the early stage of software development.
Comment2:
Using paper first before building software is a very good way to approach users’ needs. First of all, the lo-fi allows developers to understand problems and users’ needs at very early stage of the development so that developers can reduce the developing time. It also allows developer to concentrate on idea not on prettiness so that better ideas may come out. I believe that using paper and pen is much faster than using designing software even if there are many tools so that developers can create a prototype faster. However, on the user side, handwritten papers may be difficult to understand the software application because the user expects a software prototype in fancy prototype. The interaction between users and developers may be difficult and needs a lot of time to communicate each other.
Keenahn Jung - Oct 04, 2006 12:17:53 pm
While the article does a good job of extolling the virtues of lo-fi prototypes, I must say that high-fi prototypes also have their place in the development cycle. Lo-fi is excellent in the early ideation stage, when trying radical new things, but high-fi is necessary for refining the final design. It would be impossible to make minor adjustments and change small details if a user is only presented with lo-fi prototype. Just as when they are presented with a hi-fi prototype, the user assumes that it is almost done and thus holds back judgement on major design flaws, so too will they hold back judgement on small details if they are only presented with lo-fi prototypes, which they assume will be filled in later.
Furthermore, the lo-fi method they suggested (using heavy paper) resembles a computer interface, but it lacks the familiar input devices such as a mouse and keyboard. This may actually effect how the user interacts with the interface. Thus, it would be beneficial to be able to generate lo fi prototypes on the computer as well. For example, someone used to using a mouse would be accustomed to such features as right click and mouseover, whereas someone using the paper interface, without proper instructions, might not even think of performing these actions.
CharlesLeung - Oct 04, 2006 11:59:56 am
1) I think that the lo-fi prototyping model has a lot of advantages over a high-fi prototyping model. What struck me as the most important was teh fact that testers would concentrate on trivial things like style and color problems rather than important problems like the basic metaphor being used. Early on in a design stage, basic things like the suitability of the methaphor and the basic goals of the user need to be solved, otherwise it would take a lot of work to change such basic and fundamental things in the latter stages of the design process.
2) The only thing about the low-fi prototyping model is that on the surface it seems to be a rather ridiculous exercise. When I first heard about the lo-fi handwritten prototypes, I thought that it reminded me of something that I would do in elementary school. Although the handwritten prototypes does look kind of goofy at first, I think that the lo-fi prototypes are useful because they make it very easy for the designers to refine their ideas and fix any problems that may occur early on in the process. I'm glad that this class is forcing us to use lo-fi prototypes becauseotherwise my skepticism would prevent me from trying it.
Bryce Lee - Oct 04, 2006 12:52:42 pm
The ease of use of current UI building tools has tricked designers into believing a quick UI development cycle. For example, if you look at application tools such as Xcode and Visual Studio, the creation time involved in designing an interface is very minimal. Rather than emphasizing the need to thoroughly think through the process, this convenience simply shifts more time to the development of the code base. As a result, the finished project is well designed in concern to only the code.
I think the most important contribution of Lo-Fi prototyping to the design cycle is that it removes almost everything from the environment except for the user when trying to develop the UI. The short path from thought to creation allows our minds to focus on the end result, not the intermediate tasks.
Jonathan Chang - Oct 04, 2006 12:48:16 pm
One of the things I like about this class is that it's forcing me to pay more attention to the development process of applications. In past CS classes, I had the habit of just throwing down code without planning things out, but here through the process of brainstorming, design reviews, and now lo-fi prototypes, I think I've done more planning then ever before. It seems especially important when you're considering user requirements, because the final product has to be cohesive and useful, so the application itself needs to be carefully planned.
I like lo-fi prototyping because it's like sketching before you go in on the details. You still get to think about the implementation, but you're forcibly restricted/prevented from getting lost in details, retaining overall goals and tasks. It feels like you're accomplishing something, but it takes less time to get a kind of product out and see what possible things could go wrong or what the best aspects of your applications are. You don't spend costs in development time or money, and you still get something out of it you can work with.
Kimberly Lau - Nov 28, 2006 05:09:43 pm
There are many advantages to creating a lo-fi prototype. One of the primary plusses would be that anybody can build a lo-fi prototype, so long as the individual has an idea of the ultimate goal he wants to achieve with his program. A lo-fi prototype really does not require any extensive skills in programming, drawing, or machining to build since it is just rough drawings meant to communicate the overall process in using the system.
This lo-fi process and similar ones are already widely practiced in other professions. In any sort of design, the designers will always run through many iterations before settling on the final design because no matter how much thought is put into the first idea, it will never incorporate all the necessary or intended functions, and will likely contain many "bugs". With product design, many extremely divergent looks may sometimes be considered and evaluated. Although this is not the exact same as lo-fi where one specific look may get built upon or changed in certain areas only, the underlying development process is the same.
Finally, I'd like to add that while the lo-fi prototype is great for initial development of the idea, hi-fi prototypes are just as important because this is where designers begin true programming and find the real bugs that will hinder them in the final design.
Anirudh Vemprala - Dec 14, 2006 11:34:04 pm
Prototyping for Tiny Fingers: In this article, Rettig walks his reader through the process of lo-fi prototyping using paper prototypes. He explains that current "hifi" prototypes face many problems including taking too long to change, comments focusing on look & feel, giving the sense that the design has been completed as well as others. He then walks the reader through the process of building a lofi prototype which includes assembling a kit, setting a deadline for getting the prototype done and constructing the model. In the final section, he discusses how the users tests with these prototypes should be done with one designer acting as the computer and others observing and recording the users interactions.
In light of what we've learned with Scott Klemer's d.tools, the need for really lofi prototypes appears to be shrinking. I believe that users of any type, expect their prototypes to have a certain 'face value' that real lofi prototypes can't deliver. The professor did, of course, mention that there has to be some amount of user education on the part of the testers to inform the users that the paper prototype is meant to look the way it does. Yet, when there are sites that let you download "pre-made" prototype elements (see http://www.ideal-group.org/usability/Paper_Prototyping_graphics.htm ), one has to question the level to which lofi prototypes must be made hifi.
Robin Franco - Dec 15, 2006 12:48:58 pm
Comment 1: Low-fidelity prototyping on paper I think is a bit too low, especially the way in which we did it in class. The paper prototyping made it more difficult to modify the interface when it came time to apply what we learned. Also, since we were not the best artists, our prototype ended up looking nothing like the final product. It's also a little bit difficult to present a formal project to an interviewee and only have these paper models to show. I think a slightly higher level of representation would be more beneficial.
Comment 2: Even thought this might not apply so much to our project, in web development, a more “low-mid” fidelity prototype is usually created. Before an entire complex web application is created, a HTML prototype is created. This prototype is more like the external skeleton of the final product. It can easily be modified and improved as feedback is brought in. Probably best of all, one a final solution is approved, much of the HTML can then be used in the end product. So this cuts down on the entire design cycle considerably.
DavidWallace - Dec 15, 2006 04:21:42 pm
1). One of the main supposed benefits of low-fi prototyping is that the users will not focus on "fit and finish" issues, and will instead focus on functionality and usability. However, users have a body of knowledge about computer user interfaces that relies on consist ant UI features such as buttons, scroll bars, etc. Every UI handbook speaks of the virtues of consistency. By using hand-drawn buttons, scrollbars, and so on, users will be slowed down and possibly confused because the UI widgets will not match the ones they are already comfortable with.
2). We found during our low-fi testing that users seemed disoriented by the moving around of paper pieces. Having somebody's hands come in and move the windows around can make you lose your place. Windows are usually designed to "pop" into place, and therefore will often have elements spatially aligned with previous windows (for example, an OK button always in the lower-right corner). By moving windows into place instead of having them suddenly appear, the user's eye will be confused by the motion and may fail to make the proper correspondences between UI elements in the current and previous windows. This is the well-known "change blindness" phenomenon.
For these reasons I believe that Low-Fi prototyping is better done on the computer using something like Flash, which is reasonably fast for the authors to use but realistic enough for the users to behave realistically.
