Low-Fidelity Prototyping
From CS 160 Fall 2008
Lecture on 9/29/2008
Readings
- Prototyping for Tiny Fingers. CACM. April 1994. 37(4): 21-27. Rettig.
Discussion Questions
Discussions
Please post your critiques/commments on the required readings below. To do that, first login by using your user name and password, then click the "edit" tab on the top part of this page (between the "discussion" page and the "history" page), New to wikis? Read the Wiki editing guide. . Hint - Please put a whole line == ~~~~ == (literally) at the beginning of your submitted critique, so the wiki system will index, sign and date your submission automatically.
Vedran Pogacnik 02:07, 24 September 2008 (UTC)
I just don’t see lo-fi prototyping working as a one great method that will save the world. It might produce some guidelines or maybe even some results, and the team evaluations (where one guy plays the computer) might work in some cases, but even though they’re costly, I think there always needs to be more than just a touch of the user element in the usability study.
Secondly, saying that hi-fi prototypes take a long time to build, and are hard to change- point taken, but why should that be the primary guideline in making the product? For example, what if the purpose of the hi-fi prototype was two-fold: for your team of designers, engineers and so on, and the one to lure investors? Wouldn’t it be worth making a nice picture than something that looks like a three-year-old drew it? I think we shouldn’t throw away our hi-fi prototypes just yet. Lo-fi’s might just be too hand-wavy, and the investor might want some more concrete assurances.
Thirdly, developers do not resist changes- they make them happen! I doubt that a few lines of virtual text is somebody’s “baby”. Also, does Retting imply that the managers are the only ones who push for change? Believe it or not, so do the developers. Frankly, Retting’s arguments are a chain of carefully tailored premises, which all converge upon the conclusion that lo-fi is absolutely amazing. On the contrary, I find the example in figure 1 quite confusing. Eventually, all I can focus on is the card in the middle that ironically says “WRONG”!
Preparing for the test of a lo-fi model doesn’t seem to be any different from a regular hi-fi usability study. Conceptually, they are exactly the same, except that the user might get confused because great interfaces (that are already out there) might have spoiled the user too much. Making “the sharp look and feel” seems to be coming back to a hi-fi prototype.
Perry Lee 03:36, 24 September 2008 (UTC)
Like Vedran, I'm not convinced that lo-fi prototyping is as amazing as the author makes it out to be. Although I understand that you can develop these prototypes more quickly than a hi-fi prototype, and thereby receive earlier feedback, I still believe hi-fi prototyping is more useful. I can only see lo-fi prototyping as a means to catch the large, "obvious" problems.
I am unconvinced by the problems the author brings against hi-fi prototyping. While the "fit and finish" issues may be less important in the beginning, they are still issues that need to be addressed somewhere along in the development process. The more questionable problem that the author brings forth is the idea that developers will be more resistant to change if they spend more time creating a hi-fi prototype than a lo-fi prototype -- this does not seem like a valid reason to push lo-fi prototyping over hi-fi prototyping.
He also writes that a prototype may set expectations that are hard to change -- developers should be clear from the beginning that these are prototypes, not finished pieces of work. I do not think that "it may confuse testers or management into thinking this is a final version" is an appropriate excuse; it seems more of an excuse to do shoddy work and take the easy way out. Of the problems he levies against hi-fi prototyping, I can only agree that sometimes hi-fi prototypes may take too long to build, and that a single bug can bring a test to a halt.
Jimmy Nguyen 19:09, 25 September 2008 (UTC)
I admit, initially I was not a fan of this low fidelity prototype technique, especially depending on the product you are making. However, thinking about this class in general, everything is based on the foundation that the best thoughts come from "outside the box". This being said, low fidelity prototyping seems like it'd be a good idea because you will be able to see how the papers would best be arranged, ordered, and what other aspects would be needed. The general idea is to be able to be flexible in terms of initial design, as opposed to going hifidelity and just start coding and designing right away. An applicable and similar concept I can think of is designing websites. When you first design a website from scratch, instead of diving straight into the html/css, it'd be best to start with a (photoshop) mock up image of what you envision your site to look like. This way, you can experiment easily with layouts, menus, images, colors, etc. Testing would also be more efficient because if you have already coded your routes on your website and need to change them later according to user preferences, it would take a bit of refactoring. One thing I might find extraneous is the camera. With 4+ people there, hopefully everyone should remember most of the details.
Mikeboulos 23:45, 25 September 2008 (UTC)
I agree with retting about Lo-Fi's greatness. I tried designing on my own before this class and what I ended up with was nothing. I wasted so much time in creating something fancy (in terms of buttons and colors), rather than concentrating on the design and how will the program behave in response to the user. I also agree that Lo-Fi will be more helpful in terms of discovering the current bugs and becoming more innovative because lo-fi will stimulate all our senses. with Lo-fi we can also rapidly develop our prototypes and iterate easily and saving more time. but the thing that struck me was not using your friends or family members to be testers, I never thought that this might affect the testing phase. but he has a valid argument. on the other hand, I don't understand why wouldn't he test the design with the real users. They are the perfect candidates, and they won't hesitate to tell you I don't like it, or don't get the purpose of this button or this link. on the positive side, I think it was a great idea to include the camera, it makes the setting more formal and they can go back to the videos and watch how the user/tester reacted for some events. one thing I learned from this article is that the tester will be very tempted with all the setting around them, I inferred this when retting said that the users tested sometimes ask if s/he is doing the correct task, or using the program correctly. I think this should be addressed by the greeter at the beginning of the interview. I also think that hi-fi should be used when the designers are close to a finalizing the prototype. Since this will be the ultimate test to the design.
Stuart Bottom 05:55, 26 September 2008 (UTC)
I think Vedran and Perry have brought up some excellent points - in particular, I wholeheartedly agree with Vedran's comment about the dialog box in the center of the lo-fi prototype examples. I hope no user ever has to see "WRONG" in an actual piece of software... maybe it was intended as a joke, but it is confusing nonetheless. Are our prototypes really to be that "lo-fi," with little concern for the wording of dialog boxes and more for the flow of program interaction? In defense of the concept, I believe Rettig raises some excellent points. In particular, the turn-around time for paper prototype development is still probably far shorter than anything that can be created on the computer. However, I believe we should also note the age of the article: in 1994, there weren't many options people had for hi-fi or computer-based prototyping except basing it off actual production code. I'm not sure, but I don't think Flash even existed back then - and I think rapid prototyping software has come a long way since then, making the lo-fi approach a less compelling option than at the time this article was written. Another issue raised by the age of the article is the question of how well lo-fi prototyping can really simulate operating systems and applications of today. In 1994 when Windows 3.1 was the latest and greatest, lo-fi prototyping could simulate an application fairly well. When we are now talking about simulating a Vista or OS X application complete with animations, video, sound, and complicated real-time user interactions (recall the earlier reading about direct manipulation, and consider how much more advanced it has become), lo-fi prototyping seems pretty inadequate. Perhaps that is not the point of rapid prototyping - it is only meant to represent simple interactions, such as those with help systems and dialog boxes and a short list of typical user tasks (?) - but my point is that it is not capable of simulating an entire "modern" application. Try simulating even simple tasks within an RPG with a lo-fi prototype. That is the main concern I have - for a game, how can you apply lo-fi prototyping? It seems like a woefully inadequate tool when it comes to testing users' actual gameplay in many types of games - anything that requires changing graphics, fast reaction time, or audio feedback. Perhaps these are challenges we can overcome - but in the "real world" of game design, does anyone actually use lo-fi prototyping?
Mike Kendall 06:28, 26 September 2008 (UTC)
Why is this article called prototyping for tiny fingers? I still haven't figured that one out.
This article has served as a formalization of the process that is paper prototyping. Almost everything was intuitive and matched my ideas of paper prototyping, but there were a few intricacies that I hadn't thought about. The largest of which is writing out your tasks on paper to give to your test users. First, this seems like a good idea because then you don't have to worry about any influence that your description of the problem might have on the subject. One problem I see in this is that we now have to consider interference from the user's lack of understanding of the problem. What if they don't understand the task as you've described it? Although this can be your fault for describing it wrong, it doesn't seem too out of the ordinary for different people to need different styles of explanation.
Another interesting intricacy was the idea of making loads of widgets that the "computer" will move around the table rather than making loads of pages... For some reason this idea never really occurred to me.
One more thing that seemed new and important was the section called "construct models, not illustrations." There is a huge distinction between models and pictures, in a way very related to the widgets vs. pages thought process. A paper prototype is meant emulate a computer running your software, it's not meant to be a slideshow of screenshots of your software. This section also included a couple of the more clever tips/tricks for paper prototyping (running machine paper through a box/viewing window? brilliant) which was pretty cool.
Alan McCreary 19:28, 28 September 2008 (UTC)
While low-fidelity paper prototyping does provide a very time-efficient means of testing an interface, I can imagine that there would be some awkwardness due to the fact that a human is serving as the "computer," and the user is accustomed to having an instantaneous response upon each mouse click. Another potential problem comes from the number of people present during testing: there is a facilitator, a "computer", and one or more observers (not to mention a camera in the background). The number of people focusing on the tester's actions may make the tester uncomfortable, and this may have some effect on his responses.
Wenda Zhao 22:22, 28 September 2008 (UTC)
Auther is saying that designers should do paper prototyping during the evaluation of usr interfaces. The good thing is that it can be done with limit of supplies. And it also allows designers and users to focus on the "big picture" of the application instead of some small details. I think "lo-fi" is both good and bad. The good things is that designers can keep modifying the design while users can testing the current prototype. So it reduces the development time. It is bad because not all applications will be suitable for lo-fi prototyping.
Kumar Garapaty 00:04, 29 September 2008 (UTC)
I find that lo-fi prototyping is probably much more important than hi-fi prototyping. The problems you assume and the solution that your design is based on could be completely wrong and if you continue straight to hi-fi prototyping, then it will be a large waste of money and resources. In hi-fi prototyping, you can only tell if the design is wrong, but the content itself could be wrong. With early testing, the content and design could both be vastly improved.
At the same time, paper prototyping may lead to incorrect assumptions by the tester about the program because the prototype is so far removed from the actual program. This could lead the designers to incorrect assumptions when they end up creating the hi-fi prototyping. More than the process itself, the way you design the lo-fi prototype could define whether the test helped, hurt or did nothing towards the design of your product.
Jordan Berk 01:12, 29 September 2008 (UTC)
I see lo-fi prototyping as both good and bad, but overall a positive step in designing a UI. For one, the simple fact that making a paper prototype (probably) takes significantly less time than even the simplest of computer-based prototypes is beneficial, especially in the very possible scenario that the design needs to be scrapped or heavily redone. Alternatively, an evaluator of the lo-fi prototype may have trouble using it as if it was on a screen, which could hinder the development process. As Rettig said: ""people consistently enter the first lo-fi exercise with skepticism." Overall though, I think it's a very useful tool, possibly dependent on the intricacies of the interface being designed.
Shyam Vijayakumar 02:23, 29 September 2008 (UTC)
This article showed me the error of my ways. For my internship over the summer, I was charged with developing a prototype. Of course, being the inexperienced pre-CS160 student, I immediately started with a high-fidelity prototype after spending some time thinking to myself about the design. After several demonstrations of the prototype to my manager and other employees, I found that there were many unintuitive aspects to my user interface that they had trouble with. Going back to change them was cumbersome and could have been avoided if I had started out with some low-fidelity prototypes as this article suggests. In fact, in certain demonstrations of the prototype I did in the future, bugs popped up as a result of the changed structure of the code. Instead of just thinking to myself about the design, I could have put it on paper and done a demonstration of that to other people. However, I do not know how I could have managed that since I wasn't working on a team and this article suggests that any low-fidelity prototype testing must be done with four people, each having a different role in the testing process. Still, it seems like a very useful tool if the required resources are available.
Saliem Than 03:20, 29 September 2008 (UTC)
Lo-fi prototyping is a great idea I think. Combined with contextual inquiry, it's an even better idea. It's unfortunate however that I still think for some odd reason, and that I still feel more comfortable with developing hi-fi prototypes. My failures associated with developing {attempting to develop} such prototypes were accurately outlined in this reading.
I was curious when he starting talking about putting together a kit of sorts, for paper prototyping. He noted that some teams had ready made "computer parts" for use. Sometimes, they were made in a computer, and printed out using a laser printer. He noted that the quality and professionalism of the prototypes could possible make or break the interview, especially when it came to working with real potential users.
Noting this, I wondered if there were any ready made prototype pieces for a potential iphone application. Sure enough, there were plenty of things online, photoshop ready including:
PS. Coincidentally, the founder of Twitter recently posted some paper prototypes that are currently down, but supposedly will be back up
JoshuaKwan 03:21, 29 September 2008 (UTC)
Interesting read - I believe that lo-fi prototyping has its time and place, but like some other people said, it is not the end-all prototyping language. Alan Cooper, the fellow who wrote About Face, is one of the primary guys involved with creating Visual Basic. Its ability to let a developer throw together a real GUI with real answers very quickly made it a very attractive prototyping language that I believe easily rivals lo-fi prototyping. You simply grab widgets from a palette and drop them on a window. You can easily create menus, alert dialog boxes, file choosers, scroll bars, lists, trees, etc. These widgets can all respond to user input, but even if you don't set up all those event responses you can just lay out the various windows that you're prototyping and just have the test supervisor switch between them.
I also feel that a lot of user testing using lo-fi prototypes can be inaccurate because there is a logical detach from manipulating paper buttons and windows vs. actually using the computer. Some ideas that may come up when actually using it on a computer may not come up on a lo-fi prototype.
Bing Wang 05:22, 29 September 2008 (UTC)
Before reading the article. I was pretty biased towards lo-fi because if I were the subject, I would not be very impressed by the lo-fi prototyping that the observer set up for me. I would think that they are not taking prototyping seriously. It would give the subject a bad impression. However, after reading the article, it changed my perspective a little bit. There are many advantages of using lo-fi prototype as the designer can quickly change the prototype if they hope. It also lets you go through many many more iterative process of prototyping if you had a hi-fi prototype. Lastly, I agree that if the designer made a hi-fi prototype, the designer would not be willing to change the design because they believe that they have spent so much time on doing the prototyping that it should become the final product. That often blind the designer with a better design.
However, I believe the article is a little biased towards lo-fi prototype. It's a great way to generate a prototype that works, but are your subjects really going to fully participate in the prototyping as the might think it is very unrealistic to move papers and post-its around. I just do not think that lo-fi prototyping is very appealing. If you try to do a market research to see if anyone is going to use your product. This is definitely not a good way as you will get very skewed answer and people will be very skeptical whether the product will work or not. It will be much more impressive if there is a hi-fi prototype.
As I was interning this summer, our team did not get much feedback from other teams that were wishing to use our products until we came up with a hi-fi prototype that can show them exactly what it looked like. They committed resources only after they liked the hi-fi prototype, they would not even talk to us about committing resources before they can see the hi-fi prototype. I believe in that case, hi-fi prototype is much more effective.
Jeffrey Rosen 05:38, 29 September 2008 (UTC)
Lo Fi prototyping is obsolete for several reasons:
- Rapid application development tools have far, far surpassed notecards. In the time it would take to draw all of the UI elements on a piece of cardboard like the one in the reading, I could have made a fully functional prototype using web standards or a tool like Interface Builder or Visual Basic. Not only are there advantages in these tools for speed reasons (typing is faster than writing) but these tools have features such as snapping controls to the correct places according to the operating system's standards. The guy who drew the dialog with the OK button in the center should be fired. It also pains me that they take the time to underline the alt character of the pushbuttons, but totally ignore other cues like having the double outline for a default button. Why go through the headache of making all of this stuff from scratch, getting it wrong, and not being complete, when you could prototype it correctly in a shorter amount of time and have it appear like it really would on the computer?
- UI has evolved way past what can be presented effectively in note cards. Simulating a popup menu is about the limits of special effects in a cardboard prototype and even that is extremely clunky. However, a popup menu is no longer the most complicated element. In Mac OS X and Vista even a simple push button, for example, throbs transparently to indicate that it is the default button. These prototypes don't even have color, let alone subtle animations to indicate meaning. When something happens in the application, things slide onto the Window, the icons bounce geometrically, things are highlighted yellow and fade out. Furthermore, there are now common UI elements like the spinning barrel selection menu on the iPhone which are impossibly complex to replicate using paper. How would Apple's exceedingly simple timer app have been prototyped using a lo-fi method?
- A related note; animation and other visual cues are becoming common place, if not required, in a UI. In Mac OS X, Apple actually has added animation to its UI guidelines. I would like to see somebody prototype an application like Time Machine using note cards. Meanwhile with the advent of [CSS animation] and libraries like CoreAnimation, you can get graphics accelerated animation in literally one or two lines of code.
I could definitely see how lofi prototyping could be useful for some applications, but given the current state of computers, it is hard to go back to moving a piece of cardboard around on a table with the argument that it saves you time. The development tools exist to make prototyping a UI a breeze on a computer, and UIs have gotten to the point where animation, transparency, and other styles that are inherently impossible to produce via lofi methods but are trivial on a computer are becoming more common.
Buda Chiou 05:46, 29 September 2008 (UTC)
I can understand why people may think lo-fi prototyping is really gooding prototyping process. The cost of the test is very low for both time and money, but we can still get some useful feedback from the target users. However, for my opinion, looking at a computer and looking at a paper are totally different things. Even though the interface drawn on the paper looks exactly the same as it would appear on the compter, the user's feeling about them won't be same. Just like what is said in the book, users may focus on things like font or color, but isn't that unimportant? In fact, font and color are so important that can affect the usability of an interface. I know building a functional prototype may wasting time, but why don't we just draw the interface used for lo-fi prototyping on the computer and make some pop-up screen that can tell user that what the program will react to their operation. If making pop-up screen is too difficult, we still can let someone do the reaction after the computer. It shouldn't cost that much but can get more accurate result.
Jacekmw 05:55, 29 September 2008 (UTC)
While I agree that the lo-fi prototype is a good way to save money by exposing your software to user critique far before it is actually necessarily in a near-final coded form, I also believe that there are better ways than the very lo-fi paper form described by Rettig. On the one hand, it is quick and does not take much time to make, yet its professionalism is somewhat sacrificed in its not actually being on a computer and its slow reaction times. In this way, I believe the user will be distracted by all these things so much that their ability to review the software may be hindered. For a paper prototype to hold anywhere near the professionalism held by an actual working prototype, it would have to be designed either in photoshop or visual studio or something else that will allow it to actually look like a legitimate program. At this point we must ask ourselves, if we are already doing this on the computer, can we not make a better, more convincing prototype? Indeed we can - using Flash, CSS and html, or even just Powerpoint, one can easily make clickable zones and have events occur accordingly. Thus, I advocate skipping low-fi for the simple fact that the paper-ness is too distracting and too unreal (and not nearly as reusable and easy-to-change) as something done already on a computer, a sort of low-to-mid-fi prototype if you will, that will allow the user to experience the program much more like they might expect to experience a program in real life.
Karen Tran 06:00, 29 September 2008 (UTC)
I have always been the paper-and-pencil type of person, so I wholeheartedly agree with this article. I find the comparison of hi-fi and low-fi prototypes to be very interesting and accurate. I could recognize and identify with a lot of the problems with Hi-Fi prototyping that were listed. I’ve done a lot of programming and I completely agree that you do spend a lot of times just coding the prototype and that alone derailed you from the ultimate goal that you are trying to achieve. And once you are done with the coding of the prototype, you are too attached to your “product” that you’d feel reluctant to change it. Moreover, the process of modifying a hi-fi prototype could be torturously slow because more often than not, you find yourself completely abandon the code for the old prototype and waste time coming up with the prototype for the new code. The coding of a hi-fi prototype is in and of itself a new project. And the author is right in commenting that the testing of the prototype is greatly delayed by the fact that if there are bugs with the code, the whole testing process comes to a halt. Whereas with lo-fi prototype, if a bug is found, you can easily edit it. Moreover, hi-fi prototype is very systematic, the design is very restricted with the constraints of the language used to build the prototype.
On the other hand, the tools of low-fidelity prototyping are all those things you used in kindergarten; paper, pencil, markers, crayons, scissors, glue sticks, etc. This encourages creativity greatly. The key to low-fidelity prototyping is drawing out enough detail to allow the customer to figure out what is going on, but no more. One of the benefits that low-fi prototyping brings you is the ability to talk to a customer in concrete terms very early on in the project. When they are giving you requirements, customers usually have very nebulous ideas about what they are actually looking for or what they are going to get. It is very powerful to be able to return to the customer shortly after the initial meeting with a physical object that they can review, manipulate (by turning pages), etc. This initial prototype may be completely wrong, but it gives you a common platform from which you can continue your discussions about the application. And for me, getting feedback from the customers is arguably the most important thing you’d want for a product. Ultimately, the products are designed for them to use. The more feedback from them, the better. And lo-fi prototype allows you to do exactly that.
Billy Grissom 06:11, 29 September 2008 (UTC)
I agree with a lot of the points made in this article, but I don't think that lo-fi profiling is as "superb" as the author makes it out to be. The author makes a lot of good points about the disadvantages of hi-fi profiling. It's easy to see that it is easy for a developer to become attached to their prototype or get stuck in the aesthetics of their interface rather than the actual problem at hand. That being said, I don't see why these problems are specific to hi-fi profiling. I mean there's no reason why someone who would get caught up in those things wouldn't get caught up in those same things when doing lo-fi profiling. In fact, a lo-fi profile that has been well fleshed out is probably just as hard, if not harder, to criticize than a hi-fi profile. I mean it's a pretty weak argument in favor of a system if the only argument you can find against its opponent is that it's just "too" good.
Furthermore, it seems like with all the time and effort that goes into learning the lo-fi system and creating the cards, it may be easier to just go ahead and work with hi-fi profiling. I could imagine lo-fi being effective if a team already knows how to use it effectively, but if you have to train a team on how to use it why bother? i mean half of the steps listed in the article were surrounded around the idea of practicing and learning the system. Seems to me like you could use a team's time in a more valuable way.
I think what might be needed here isn't a lo-fi or hi-fi profiling system, but rather a mid-fi profile system. Maybe have something that has the efficiency of a hi-fi system yet remains simple and lacks a lot of the details that you can have (like in lo-fi).
Geoffrey Lee 06:35, 29 September 2008 (UTC)
I think lo-fi prototyping works really well for testing UI designs in software applications. As someone who has worked on a particular piece of software through 4 iterations by now, I can definitely appreciate early feedback that prevents me from doing unnecessary coding and last-minute changes.
But, I'm somewhat worried that the slow response-time of "the computer" in lo-fi prototyping makes it very difficult to test applications that have a real-time component, such as tasks requiring timing or observation of changing data. Examples that fit this category would include stock market data feeds, chat rooms, and video games. Still, there are plenty of functions in those examples that don't depend on real-time interaction.
It's also interesting to note that prototyping in general has become somewhat less important in the realm of web applications. While it's difficult to modify traditional desktop applications that ship to the user, bad interface design in web applications can still be corrected after the product is live.
Gary Wu 06:39, 29 September 2008 (UTC)
I tried paper prototyping for my first time and absolutely loved it. This article really highlights all the benefits of lo-fo prototyping. One problem I found with playing the computer is that I subconsciously try to help the user out. This is definitely a hard thing to do and will definitely affect the end results. A problem I can see from lo-fi prototypes are the lack of actual ui elements. A lot of times, text and words replace the actual button or widget. This can definitely make a huge difference. The selection process of users seems to be one of the more difficult tasks of lo-fi prototyping. While it is good to get a broad range of people, getting users most familiar with the product would probably be the ideal situation. However, this could also skew the results. I think the biggest point of this article is the efficiency of the lo-fi waterfall model. Being able to test and refine the interface without having to commit anything to code is such an efficient way of working.
Mohammed Ali 07:07, 29 September 2008 (UTC)
Lo-fi prototyping seems like an awesome idea to get user feedback quickly and an easy way to go through many iterations as possible without too much expense. However, I cannot give an opinion about its usefulness because of the simple fact that I haven't tried it out myself. The flow seems smooth however I don't know if the reactions would be different as it would in a hi-fi prototype.
Things that I find positive about lo-fi prototyping is the ability to receive feedback on the overall design of the system, the system flow and conversation, the system layout, and basically all the other "big" things. Designers don't have to worry about the small things in creating their prototype and users can focus and concentrate on the big picture instead of getting stuck on the small details when giving their feedback.
I would take advantage of trying to make the design look and feel as much as actual game play as possible for the lo-fi user tests to be as productive as possible. With a little imagination on the users part and some thought out prototyping and tests by the design team, we could have gain early and important design feedback through this method.
Frank Yang 07:31, 29 September 2008 (UTC)
Before I read the article, I thought it was standard to simply draw up what an interface will look like on paper, but I had no idea that working on paper would go as far as lo-fi prototyping does. However, it seems like an awful lot of work to go through the trouble of presenting it to another person. Having a person act as "the computer" and move around bits and pieces of papers and notecards seem really cumbersome, and even then, it probably does not feel like a real experience for the interviewee. I would still try and go about this route, because, as the text stated, it is a great way to get some instant feedback and make changes without having to commit to code. I know very well that when you deal with code, you have to deal with the bugs that come with it, and it takes to see results from a change would be much longer than a movement of a notecard. While lo-fi tests are clearly not enough for some technical feedback, I think it is a great way to receive some early design and structural feedback.
Haosi Chen 07:34, 29 September 2008 (UTC)
I am unconvinced by the problems the author brings against hi-fi prototyping. While the "fit and finish" issues may be less important in the beginning, they are still issues that need to be addressed somewhere along in the development process. The more questionable problem that the author brings forth is the idea that developers will be more resistant to change if they spend more time creating a hi-fi prototype than a lo-fi prototype -- this does not seem like a valid reason to push lo-fi prototyping over hi-fi prototyping.
Kai Lin Huang 07:38, 29 September 2008 (UTC)
Low-fidelity prototype requires a lot of human interaction skills instead of technical skills, and thus in some situation easily causes biased analysis for the user interface design. Also, think about in real working situation, a team that builds a new feature on an existing software application usually consists of at most two user interface designers because of cost-benefit consideration. Other members in the team, such as software engineers, product manager and quality-assurance, usually have more than one project in their hands to be productive during one project’s UI design stage. UI designers do not have much help in testing out the low-fidelity because there are only so few of them in a team. Theoretically there should be a greeter, a facilitator, a computer runner, an observer and a note taker, but in reality there will not be as many professionals running this single task. In addition, UI designers need to show their progress of designing with professional looking prototypes; however, it is hard for them to present their prototype (or work progress) on pieces of paper. Actually, I am glad that I can have an opportunity to try out low-fidelity prototype because I have four other people in the group anyways.
Witton Chou 07:46, 29 September 2008 (UTC)
My first reaction to lo-fi prototyping when it was described in one of the first lectures was "WHY OH WHY -- who would even bother playing with something so ugly?" However, as weeks have gone by in this class and actually going through the brainstorming process and actually having to develop a well thought interface, I see how lo-fi prototyping comes in handy. Although it is not the most visually appealing, it is a way to encourage efficient design with a focus on the usability and not eye candy.
I definitely see how designers can sometimes get carried away with making the interface appealing -- I fall into the same traps a lot. It is one of those things where we get instant gratification. If something looks cool, people are instantly amazed and the positive feedback is marvelous. However, if, once they try to use the product (often websites in my personal experience) and can't find something or are having problems using whatever the page is intended to do, they get really frustrated, which completely takes away from any visual pluses from the site. Lo-fi prototyping really makes it easier to pay attention to the usability which is the most important part of the user interface.
Many people also get trapped by falling in love with something they spent hours working on. As a computer science major, there have been countless times when I am reluctant to restart a significant portion of a program because I realized there is a better way to do it. The amount of time dedicated to a development cycle tends to create a bond between the developer and the product. I really agree that the less time spent on something, the less I am reluctant abandon it. Lo-fi profiling really helps in this respect as it takes less time to prototype and ultimately yield more design cycles and make radical improvements. The article does a great job detailing these benefits of lo-fi prototyping and I expect to fully employ lo-fi prototyping in our projects.
Volodymyr Kalish 08:29, 29 September 2008 (UTC)
"lo hi" prototyping is the cheapest and quickest way to get an immediate feedback on the product that is not yet developed. However, it requires a good deal of team work on the designers side. In order to perform one test run everyone in the team has to cooperate and not interfear. So, the down side of such a testing is that many more designers are required to run one simulation with a single user (since someone has to take notes, walk user through, play computer, help in playing computer, etc). And since the duration of simulation can take more than an hour, it hard to test the interface prototype on a big number of test users. So, since there aren't that many users, something that works for one can contradict to preferneces of another test user, making it unclear whether it is a personal issue or an actual interface problem. People who actually get to talk to test users must have excellent people skills and become psychologists for the duration of test. It is so hard to watch someone struggle and not helping them, especially if you know how to help.
Paul Im 08:47, 29 September 2008 (UTC)
I agree with a lot of the concepts that Marc Rettig presents in this article regarding low fidelity prototyping. It is definitely cheaper and less time consuming than high fidelity prototyping. Creating a high fidelity prototype takes a much longer time, and making changes to the prototype takes even longer. A low fidelity prototype, on the other hand, can be fixed simply by taking off and gluing another piece of cardstock onto your presentation. Also, the man hours and resources spent on a low fidelity prototype is definitely less than a high fidelity prototype.
One thing, however, is that setting up your first session to do a low fidelity prototype may be quite time consuming, as you have to buy all the resources and print out the different templates for use. I can see how efficient companies can be very skeptical regarding this method, simply because they would want their employees to get working on the product right away, meaning a high fidelity prototype: something professional-looking and highly functional. They wouldn’t consider ‘craft time’ to be an appropriate use of their budget. Once companies can get past this skepticism, however, low fidelity prototyping can definitely have a future in corporate America.
Trinhvo 08:50, 29 September 2008 (UTC)
It's beneficial to know more about lo-fi prototype before we can start working on ours. This article covers a lot in detail about lo-fi prototype. I just wished that this was a video clip, so I could see the whole process much clearer, such as the process designers create and sort their paper prototype, or how they start their design, etc. Probably, it's just hard for me trying to visualize and read at the same time. Although, I have no doubt about this technique, I just think who would volunteer to do the tests on paper. Every body seems to be busy, and they will have peer pressure during the tests due to many observers around e.g. greeter, computer, facilitator, and observers.
Xuexin Zhang 08:54, 29 September 2008 (UTC)
I couldn’t agree with Mr. Pogacnik and Mr. Lee’s idea about lo-fi prototyping. Personally, I think lo-fi, as a method of prototyping, could not only save time and efforts of the designer, but also enable the design creativity. Lo-fi prototyping is a much easier prototype for the UI designer to come up with and users could find design flaws in lo-fi designs as simple as from hi-fi designs. Also, as mentioned in class, when users or designers see a lo-fi prototype, they tend to think that the design is not finished/completed. It could enable them to think more changes to bring usability to their design.
Anthony Kilman 09:01, 29 September 2008 (UTC)
To be honest, I was skeptical at first of the applicability of this article, because I made the assumption that current prototyping tools rendered paper prototypes useless. And also because the reading was relatively old as well. But Rettig make a very solid case for LoFi prototyping, and convinced me of the utility of the process. There was one very good point which caught my attention. This was regarding the "prettiness-power" in HiFi prototypes. I actually found myself succumbing to such a temptation in creating a screenshot for the contextual inquiry assignment.
Another very important point that I've personally come across is developer's resistance to changes. In the reading this is more of an argument to not use HiFi prototyping for UI design, but my experience was a suggested modification for a hash based index at a recent internship. Developers almost always become attached to a particular design or idea, and are always reluctant to make significant changes to such a design. This is simply a consequence of putting significant amounts of time into a project.
Hao Luo 09:43, 29 September 2008 (UTC)
I don't understand many people's objections to lo-fi prototyping. It seems like something that naturally makes sense but for some reason or another many designers neglect. We have went over many times the idea of iterative design, but doesn't it make much more sense to test early on so we can fit in many more iterative cycles? I agree with most of the points brought up in the article, with regards to the advantages of lo-fi prototyping. It seems like products that are obviously unpolished often suffers from hi-fi prototyping. The user can clearly tell that the design flaws in the product are probably ones left over after some testing that was probably done last-minute. There was no extensive testing to catch all (or most) of the design flaws. This happens due to hi-fi prototyping. A product that was tested way too late into production and flaws are hard to correct. In some cases, the product itself is simply not usable, yet the designers, having put too much resources into its development, and unable to let go of sunk costs, continues with the product anyway which leads to failure. This is something that can be caught with lo-fi prototyping.
Another point I wanted to make is that lo-fi prototyping and hi-fi prototyping are not mutually exclusive. Some people are bringing up the advantages of hi-fi prototyping and putting down lo-fi prototyping because of it. This is a wrong way of looking at things. Instead, we should praise lo-fi prototyping as a complement to hi-fi prototyping.
Cynthia T. Hsu 11:17, 29 September 2008 (UTC)
I think I'm glad that Retting spent so much time elaborating gon the procedure of low-fidelity prototyping instead of simply tauting its advantages, which seem a bit obvious. One of the things I found in my first attempt at low-fidelity prototyping (during the brainstorming session) is that I was so caught up with drafting low-fidelity ideas quickly that a lot was left open to the (mis) interpretation in my group. The mention of testing it a few times within your group was a useful task that I somehow overloked.
I also found it interesting that he had such a huge list of art supplies that were part of a low-fidelity prototyping kit. While some of them, like post-its, I agree with, I was a bit intimidated by his description of how "different people excel at different aspects of lo-fi construction: design, inventing ingenious paper implementations of widgest, producing large amounts of data, or rendering artistic and attractive designs." In particular was the section, "Need to represent a long scrolling list? How about cutting slots in the dialog box and running adding machine paper through it?" While I agree with the philosophy behind low-fidelity prototyping, this description seems like "low-fidelity" prototyping requires just as much time investment and results in just as much emotional attachment as "high fidelity" prototyping, if not more. It might be easy to get carried away with cutting and performing arts and crafts and tweaking things to look just right; I was a perfectionist in art projects in middle school and high school and partly chose computer science over more hands on engineering because it was actually much faster for me to do something on the computer than to actually build a model. I suppose this is why he proposes drawing blank buttons and widgets to ease the transition.
I liked the example Joshua Kwan mentioned of Visual Basic being a useful intermediate between low-fi prototyping; I think it reflects my thoughts exactly.
Antony Setiawan 15:22, 29 September 2008 (UTC)
Some interesting poins and facts are brought in this reading. I agree that hi-fi prototype is indeed consumes lots of time to build and developer would resist making changes to something that they've worked on for so long. However, I kind of disagree with Marc about tester commends about the preetiness of the program/application. I believe consumer would comment on the product's functionality rather than just color matching. Aside from his way of doing lo-fi prototyping, one important note that I got from Marc's low fidelity prototyping is that prototyping is worthless unless information is gathered and the product is refined based on our findings.
James Yeh 15:46, 29 September 2008 (UTC)
I agree that low-fi prototyping is a more convenient and efficient way of going through testing iterations than its hi-fi counterpart. It makes sense for product creators to solidify design concepts before they actually start building an application, and creating prototypes on paper and cardstock is much faster than directly coding a design. But while I can see the benefits of lo-fi prototyping, I am still a little skeptical on the practicality of implementing such a strategy. The setup of having the users test the prototypes may get easier with practice and experience, but it certainly seems awkward and unusual at the moment; the fact that a “computer” has to move a paper cursor around makes it seem like the user would be more distracted by what the people are doing around him (since the testers are supposed to watch his every move) than actually focusing on the task at hand. Thus, while the idea of lo-fi prototyping makes sense in theory, I would need to witness the testing phase to believe that it works in practice.
Kevin Lam 15:49, 29 September 2008 (UTC)
Low-fi prototyping reminds me of a similar technique that strategy and operations (S&O) consultants use to create Power Point decks. Although Power Point is fairly easy to use and decks can be put together in a short amount of time, consultants have a tendency to draft their decks on paper before having them digitized. This process varies by consulting firm, but in general it involves drawing a sketch of each slide on paper (w/ one slide/page) and running through the presentation with the drawings. The justification behind using paper instead of Power Point is that paper is much easier to edit, as is the case with low-fi prototyping. Also, consultants usually have a time constraint and it's not uncommon for a consulting group to make two or more presentations in one day. The biggest parallel though between the deck creation process and low-fit prototyping is that just as developers are unwilling to change their code after it has been written (rightly so, because they have devoted their time and effort into writing the code), consultants don't want to waste time editing slides in Power Point (moving objects and changing text in Power Point is much more time consuming than erasing and drawing shapes on paper).
We cannot, however, view making Power Point decks and writing programs as equals. Power Point decks are used for presentations and so they typically don't have an element of user interaction, whereas user interaction is a key part of any program. The fact that you don't have to click and drag objects in a presentation makes representing decks on paper a natural exercise. Nonetheless, the idea of simulating a user experience on paper before creating a final or close to final version of the product is still relevant. Even though it's difficult to simulate a lot of modern features (i.e. drop down menus and mouse overs) on paper, developers can still save a lot of coding time by drawing their interface on paper and walking through the application or system with the client or user.
Yuta Morimoto 16:29, 29 September 2008 (UTC)
After the reading, I think of how to evaluate our prototype. I partly agree to make a low-fidelity prototyping before underlying problems annoy us. Lo-fi prototyping works remind me of implementation of software during a internship in a small software engineering company. Fot time and financial constraints, the company had limited resources to make the product and could not build lo-fi prototyping. We had directly made hi-fi prototyping which was almost like final product. But in the testing, we found many underlying problem including UI flaw So, we needed to change the hi-fi prototyping spending a lot of time. However, I have no idea which cost is higher lo-fi or hi-fi. Because, after we built lo-fi prototyping first and finished testing it, we might need to commit to newly code hi-fi prototyping which would be totally different from lo-fi. On the other hand, after we build hi-fi prototyping first, we might need to commit to change it by newly coding.
Juanpadilla 16:30, 29 September 2008 (UTC)
low-fi prototyping is a cheap and easy way to make sure that you and your customer are on the same page. It has saved me a huge amount of time in the past from having to come up with alternative designs after creating a working prototype, which has happened to me on a several occasions. Bottom line, with the economy down and people looking to save money, why not use this simple and efficient method to save it?
KevinFriedheim 16:45, 29 September 2008 (UTC)
I really feel like (as did many of my fellow classmates) Marc Rettig, in his work on "Prototyping for Tiny Fingers," really went against High-Fidelity (Hi-Fi) designing. He admits that the process of designing in Hi-Fi takes several weeks -- but so does Lo-Fi. I can agree entirely with Rettig that its important to be able to make changes early, but that doesn't mean that Hi-Fi gets thrown out altogether. Perhaps both Lo-Fi and Hi-Fi can be combined given a time constraint. Maybe make a Lo-Fi presentation, then make large changes, and then a Hi-Fi presentation, and make changes like color or appearance, which, in some cases are just as important as the application itself. I feel that this topic of Lo-Fi versus Hi-Fi can be argued both ways -- that is, Rettig didn't have to "bash" Hi-Fi to prove his point on the usefulness of Lo-Fi.
Jonathan Fong 17:05, 29 September 2008 (UTC)
I've seen a software project get carried by momentum, despite less-than-ideal UI design. The first prototype was developed on paper, but it wasn't a real prototype, nor put in front of anyone to evaluate; this lo-fi was more like a rough draft done for the sake of writing down the list of all the features. A few hours later, the second prototype was being developed in Microsoft Visio (because it could be used like Flash in some ways, with simple buttons and interfaces). This actually took up an engineer's time for one or two work-days (and one all-nighter) so the project could be presented to management. By then, the team was pretty "juiced" and had a set idea on what the interface should look like (as Rettig mentioned, this was probably helped by the fact nobody wanted to "waste" the time spent already).
Would a true lo-fi prototype helped all this? I think so. I can see how a paper prototype put in front of users could have allowed the interface to be iterated before momentum carried it to the programmers. Would it have saved time, though? Not during the prototyping phase compared to the Visio prototype. The paper prototype would have taken more time, especially doing it the way Rettig described. Probably a worthwhile investment, perhaps.
Greg Nagel 17:18, 29 September 2008 (UTC)
Two sayings from the reading help me sum up the main idea of this course so far: "Know Your User" and "You Aren't Your User." These quotes eloquently sum up the idea of using others' experience. It is so easy in design to believe that you already know everything. We must realize how easily usability problems hide and continually test every idea with the real users.
