Low-Fidelity Prototyping
From CS160 User Interfaces Sp09
Lecture on Feb 25, 2009
Readings
- Prototyping for Tiny Fingers. CACM. April 1994. 37(4): 21-27. Rettig.
Rohan Dhaimade - Feb 21, 2009 02:15:26 pm
The low fidelity prototyping model of evaluation seems weird to me. I mean, when you work on a computer it is very different from working on paper. The screen and how you look at things is different so I can't imagine that users will be able to respond appropriately to the interface based on paper objects. 1 point is the fact that the user will most likely be looking down on a monitor and using his hands to touch dialog boxes rather than a real simulation of a keyboard/mouse. It also doesn't help that the low-fi prototype requires a third person moving things around. One important thing they didn't mention in the article is to avoid the user seeing any other menus and other stuff when providing them a computer. I think looking at other menus and other dialog boxes will actually confuse user's thoughts. Of course these two points are very minor and probably aren't as important as the user being able to recognize and figure out how to do certain things based on menu actions and the available buttons and other things available to him. I would also like to mention that low-fi model prototyping impact on multi-touch interfaces. Low-fi prototyping might actually be better, and significantly easier, to do for them as you would be just looking at the user's hand gestures and then moving the appropriate boxes.
David Burban - Feb 22, 2009 12:53:41 am
We talked about the Low-Fidelity prototyping model briefly in class. The method for Low-Fidelity prototyping seems fairly straight forward - create paper based models of the user interface and do a "wizard of oz" in front of test subjects, who are going to try to navigate around said interface. All the options and menus have to be modeled for the Low-Fidelity prototype to work well. The method for conducting the interviews also seems straightforward, sit the person in front of your contraption and watch them struggle with the interface while a partner takes notes. What really concerns me is the huge amount of supplies that the article states are needed.
Moonway Lin - Feb 23, 2009 02:31:48 am
I agree that lo-fi prototyping is a highly useful and necessary step in the development process. Just like the architect must draw a blueprint, revise it many times, and then construct scaled models before the actual building even breaks ground, the UI designer should also start small and go through the same process of brainstorming and revising before coming up with a final product. Lo-fi prototyping is especially effective when the general direction an application interface should take isn't obvious from the beginning, and user input is required. I'm not sure using construction paper, tape, and making the lo-fi prototype as fancy as the level described in the article is necessary: as long as the user understands what each function does, how each screen connects to the others, etc., and can provide useful input, it shouldn't be necessary to build the actual program out of paper, so to speak. If too much effort is spend on the lo-fi prototype, a hi-fi prototype using a high-level programming language may even be more efficient, depending on the size and scope of the tasks involved.
Sean Hansen - Feb 23, 2009 06:16:01 pm
This was a good read. I'm kinda curious about common trip-ups in lo-fi prototyping, though. The author mentioned that the observers are often strongly compelled to interject explanations about why they made some decisions or how certain features are supposed to work, but what about the other testers? Aside from making sure they know how the interface is supposed to work and having their prototype components organize, are there any other specific problems the computer has to watch out for, like trying to make run-time corrections to the interface when it's not called for? Further, what kind of questions should the facilitator avoid?
I'd also be interested in a related reading about trying alternative interfaces in the same lo-fi prototype run-through. Does asking the user to perform the same task with different interfaces in the same session cause harm to the test results due to created expectations or any such thing?
Jeffrey Patzer - Feb 23, 2009 10:37:13 pm
I thought the practicality of this reading was amazing. I actually want to go out and get stuff to make things now (except that its raining). This article does a great job of pairing down how to establish a master/apprentice relationship model with the user and how an interview should actually be done. The use of an exact number of people with exact jobs is very useful. The idea that its useful to keep a library of widgets around that the designer can draw sounds like a great idea. The article seemed to adequately address the balance between detail and concept. In a way it was like a direct manipulation interface, instead of describing a method in extreme depth the author just presented examples of how to do things. I do wish that the author described some more of the limitations of lo-fi design since I think understanding what it can't accomplish is an extremely useful piece of information.
Saung Li - Feb 23, 2009 11:06:19 pm
The concept of lo-fi prototyping seems to be the best way to prototype. It is necessary for designers to test out a prototype early to get feedback early so that they can make changes easily. If they have a hi-fi prototype, making changes would mean changing a lot of code and perhaps the entire structure, which could be very costly. This hurts the morale of the designer as well, since they poured so much effort into it. Lo-fi paper prototypes provide the big picture to the user so that designers can get the overall idea of what users want and how they work with the interface. Being able to sketch out designs quickly also helps facilitate the designer with creative ideas since they bring out the designer's artistic side. Assembling a kit of supplies seems to be fun since that is something kids usually do, setting a deadline motivates designers to quickly put their ideas onto paper, and constructing models instead of illustrations allows the designer to focus on the main idea instead of small details such as colors. The article, like previous ones, mentions finding target users that are well-suited for the interface, make test scenarios for test users to run through, and actually practice simulating the paper prototype so that it resembles what the computer would actually do. Having four people conducting the interview seems like a lot at first but it makes sense to split the tasks into a greeter, computer, facilitator, and observers. Each is needed to focus on their own parts to get them down perfectly to get the most information out of the user in the most efficient manner. Of course, a long time is spent on evaluating the data to make appropriate changes for the next test. This article mentions a lot of benefits of lo-fi prototyping, but are there any cons to using it? Would test users think of a paper "computer" the same way as a real computer interface? Are there any benefits to using hi-fi over lo-fi prototyping methods?
William Cho - Feb 24, 2009 02:06:52 am
This is a subject we've covered briefly a few weeks ago. I remember watching in lecture the video of that one design company that designed a better shopping cart in a few days. In that video, the team used some ideas of the lo-fi concept (covering the walls with stickies, making mock-up shopping carts, etc). I can see that it's a great way to quickly prototype and be flexible in the design, which is hi-fi prototyping's major weakness. Lo-fi prototyping provides dozens of different ideas that can be discarded or improved upon. Sure, I do think that a mixture of the best parts of lo-fi and hi-fi prototyping would work nicely too. But when strapped for time, lo-fi prototyping seems like the better way to go.
Denise Ngai - Feb 24, 2009 12:28:06 pm
Lo-fi prototyping is indeed a good route to take when testing out software before actually taking the time to code it. I agree with the author about the points he brings up in "The Problems with Hi-Fi" section. I know I definitely fall in love with my coding projects, and likewise, it'd be harder for me to revert to nothing or revise my design. In addition, I understand how people will concentrate more on the look and feel rather than the functionality because as I develop, I, too, get caught up in the aesthetics of the program rather than the actual purpose of it.
What was silly of the reading, however, is the fact that later on in the article it became a "How-to" of creating paper prototypes and testing. I personally felt like it was very elementary to have to explain exactly how to go about creating lo-fi prototypes and have people pretty much "pretend" to use it like a real program. Isn't it pretty self-explanatory?
On the bright side, it's refreshing to read something relatively lo-fi that concerns computer science/UI design. It's even more freshing that the article encourages you to get crafty and make those paper prototypes. :)
Anatol Tsang - Feb 24, 2009 07:41:17 pm
Lo-fi prototyping seems very logical... and it could be fun! (Personally, I was playing the computer on myself when I was in the process of designing the photocopier interface.) It seems that a lot of programmers underestimate the part of planning their design before they actually start coding something (most of my CS friends prefer to hack away and change their designs later). I thought the use of random talents (artistic, creativity, etc.) and the use of art materials was quite interesting (I wouldn't have thought of using anything other than paper and pencil). It makes sense, though, that the process of designing a good program with a good interface involves skills and materials other than being able to program and a computer.
Chang Su - Feb 24, 2009 08:09:06 pm
Having bashed the previous reading without care or mercy, I give my two thumbs up to this one. In my humble opinion (or as they say, IMHO), this is by far the most useful and inspiring reading the class's had so far. It is oh so concisely and persuasively written. Most importantly, it actually makes me anticipate the lo-fi prototyping stage of our group project with eager.
It just makes so much sense: cardboard windows, finger cursors, human computers... Well some might say somewhat nonchalantly, "I can create a button in Flash faster than I can draw one." Well I'm not very adept with Flash, but how fast can you make a drag-and-drop object in there? Now how fast can you make a drag-and-drop object with a cardboard?
Yes that was somewhat a trick question. You don't make a drag-and-drop object with a cardboard. Any cardboard object is drag-and-drop by default! This is but one of the many many gains in efficiency that I can think of by using a lo-fi prototype.
Plus, it's fun! Admit it, would you rather make cute little windows on paper or write 200 lines of code? There... you have it.
Colin Downs-Razouk - Feb 24, 2009 08:53:30 pm
I agree with what many of the previous posters: this reading was really practical and useful. It will be quite useful for our discussion section where we are testing our interfaces. One interesting thought to ponder (or that I have been pondering) is what kind of affect lo-fi designing has on the software engineer market. I can imagine that most software engineers don't draw all that well, so a lot of these companies that use lo-fi designing have to bring in artists. At the same time, I would not leave it in the hands of an artist (who knows nothing about how a design works) to draw a lo-fi design. This leads me to wonder if there is lo-fi design software on the market. Kind of like flex, except all it does is compose and links images of the design. It has a library of common UI components, and drawing tools to make your own new components. This might be a nice compromise between lo-fi and hi-fi design. If the software is designed well, it would be fast to make like a lo-fi design, but it would also have the organization and the clarity of a hi-fi design.
Ling Chen - Feb 24, 2009 09:26:46 pm
I liked how the article was short and straight to the point, giving us useful information. Paper prototyping sounds like fun. Like the author said, it's fast, easy, and helps get the big things right. Catching bugs in a hi-fi prototype can be a big pain, and changing designs then would be even worse. I also liked how the article gave very practical pointers on how to construct a prototype (like keeping an assembled kit handy). I was quite excited about the shopping list (maybe because I am more of a hands on person). The varieties of materials on the list made prototyping sounds like a fun game we play. The article then talks about how to prepare and conduct a test in detail. I enjoyed the instructions that were given. The author even pointed out helpful hints on how we should interact with the users during testing. The stuff brought up sounds fundamental enough, maybe even too elementary for some, but sometimes it is exactly these simple stuff that we tend to over look and miss. So it was good learn and to be reminded all these stuff presented in the article. Finally, we have to remember that prototyping is "worthless unless information is gathered and the product is refined" based on our findings. After all, if we get too caught up in prototyping and never make use the of the information we collected during testing, the whole process would be pretty pointless. Overall, after reading the article, I look forward to trying out lo-fi prototyping with my team and users.
Anjana Dasu - Feb 24, 2009 10:01:46 pm
I'm a fan of lo-fi prototyping. For me, it's a really important stage because I sometimes get preoccupied with the aesthetics of design instead of focusing on the usability. This is particularly applicable when I'm working in photoshop or flash or HTML/CSS/JavaScript. When I put in so much effort into a high fidelity prototype, I sometimes get mentally blocked from assessing it objectively. This article also made me reflect on our past individual assignments and realize how useful it was to do hand drawn sketches. First off, working with a pencil and paper is faster than you think and it's nice to be able to throw something out and start over quickly. Second, doing things by hand made me think more about the functionality of the touch-screen copier/cellular mp3 player interfaces. As I worked through one design, I would get ideas for the next rapidly. Most of the things we've done have been pretty static so far, so I'm looking forward to doing more dynamic lo-fi prototypes and testing them with user in the 4-role method mentioned in the article.
Kevin Huey - Feb 24, 2009 10:22:33 pm
This seems so logical that one might take it to be common sense to conduct lo-fi prototyping. As was said in the article, it is easier to gain knowledge about the wrong things in your design BEFORE coding it. Too often many of us are victim to the act of "diving-straight-in-code" when asked to do something. Most of us that do this usually run into numerous problems that could be avoided if we went over the design. It applies to everything.
The article's steps for building a prototype seem curiously similar to that of the Deep Dive video we watched during Lecture #2. Each team started off by creating total mayhem with various ideas, pieces of paper, post-its, etc., eventually assembling some kind of prototype. They set the deadline for a week, and feigned for ideas from potential users. Then they built the real prototype and tested it, obtaining user input in the process. The steps are exactly the same, and the video is a living example of exactly how powerful the procedure is.
Timothy Yung - Feb 24, 2009 10:38:06 pm
This article was somewhat silly because the whole idea of structuring lo-fi prototyping seems silly to me. I agree with the points raised in this article about how many developers tend to create prototypes that are too elaborate and that take too much work to create (and how they fall in love with them), and I agree that more time should be spent off the computer than on it when designing. However, I also believe that hi-fi prototyping has significant value and can provide feedback that lo-fi prototyping cannot. Users are in a different mindset when they are faced with lo-fi vs. hi-fi prototypes, and using a hi-fi prototype allows the designers to get feedback that apply to the end result. Also, hi-fi prototyping forces the designer to think the designs out more thoroughly.
Szu-Chun Mao - Feb 24, 2009 10:57:52 pm
I remember that the professor discussed about the benefits of having paper mock up in class. This valuable article gives similar strategies suggested in class, however in greater detail. I used to think it’s stupid to create lo-fi prototype when you can use that time for hi-fi prototype. Now, I’m a strong believer that lo-fi prototype is the way to go. One of key advantages for lo-fi prototype as mentioned in this article is that it enables developers to focus on user usability instead of the graphical design. It also allows better user evaluation feedbacks. Lo-fi prototyping greatly reduces the time of each design cycle. This article also suggests good strategies to conduct user testing. I think the role of “computer” is particular interesting where a team member acts as the computer in the testing process. Overall, I think the idea of lo-fi prototyping is probably the most valuable tool I have learnt in class so far.
Alan Young - Feb 24, 2009 10:28:41 pm
I think that the concept of low-fidelity prototyping is a great idea and is the ideal way to go about designing a project to be best for the user. It makes a lot of sense in theory and according to the article, is a tested and effective method used by project teams. However, the article makes mention of the fact that there is a lot of initial hesitation and opposition to actually executing the low-fi prototyping ideas because people are unaccustomed to it and do not readily see the value. I'm definitely part of that group of people in that I have to be trained to practice in a different method. It's a similar effect to when I was taught test-driven development, where I would often times feel that I am wasting time and energy on "preliminary steps" before building the actual product, but would actually save time down the road. This article has convinced me that lo-fi prototyping is a worthwhile concept to invest in, despite the initial apprehensions and extra work, especially when testing with users and having team members stick to the designated 4 roles, and that is something I can see will take a lot of time and patience.
Joseph Tsay - Feb 24, 2009 11:30:21 pm
I found that low-fi prototyping was an interesting idea that could be useful for being able to try out several different ideas without committing too much to any single one. Although, of course, it can by no means replace hi-fi prototyping for completely testing whether or not a certain implementation will work, it isn't intended to do so. Low-fi prototyping allows the programmer to avoid getting locked into or attached to a single implementation that he or she has spent a particularly long time and effort on.
Carolchen - Feb 25, 2009 12:07:41 am
I never did figure out why Prototyping for Tiny Fingers is named the way it is, but the article itself was very enjoyable. The authors managed to convey the excitement and efficacy of the design process. I especially enjoyed learning about how to make lo-fi prototypes in such a way that every possible interaction is captured. This type of prototyping and resulting user testing with the lo-fi prototypes appears to be a great way to find problems with the early interaction design flow. No matter how well we as designers believe we understand the users, we cannot stand in for them, and we cannot anticipate their every action by pure hypothesis. Lo-fi prototyping is a way to design the interaction without committing to an expensive, resource-heavy implementation, like you would expect at the hi-fi end.
Adit Dalvi - Feb 25, 2009 12:44:57 am
I disagree with the lo-fi prototyping idea, because I think it requires too much investment of time and man-power to carry out. The author suggest that we build a kit of adhesives, acetate sheets, markers and other stuff and then build a model out of it (not an illustration). I seriously doubt this is feasible in today’s fast paced world. I also doubt it is feasible to get users to actively participate in testing the interface in person, especially when a lot of people use the internet for communication. Also, to address the author’s issues with a single bug bringing the hi-fi prototype test to a halt, and the hi-fi prototype being hard to change once it’s coded, I think that if a program is coded well from the beginning, then not only should it be easy to change because of the program structure itself, but also bugs can be easily found through unit testing. I also believe that regardless of whether you are using a lo-fi or hi-fi prototype, bugs will always be present; bugs can only be minimized and that depends on your coding and testing. In our current model of software, users are used to seeing beta products and full versions. I find it hard to believe that the author would suggest trying to get users to go out of the way to actually show up to watch designers move pieces of cardboard around. All-in-all, I think it’s a terrible idea to waste time making a lo-fi model for users. Just keep it internal and make sure your beta and full versions are presentable and stable.
Chunwei Lai - Feb 25, 2009 12:41:04 am
The use of a low-fidelity prototype is definitely a good way to get things started and some of the previous points brought up about how a low-fidelity prototype guides the user into focusing on functionality instead of the "looks" is definitely one of its strongest point. It is important to note that at some point high-fidelity or actual sample should be presented to the users. Overall a nice presentation of how to and why use low-fidelity prototype.
Cuong Ngo - Feb 25, 2009 01:35:43 am
Lo-fi prototyping is perhaps the cheapest and quickest way to refine our design before we implement it. All we need are some affordable tools such as pencils, markers, papers and a few hours. I think the process described in the article is pretty straight-forward too. Each member in the design team plays a contributing role. One of the advantages of lo-fi prototyping is that it helps us visually iterate over different ideas we might come up with. The best idea is almost always one of those, which is why I couldn't agree more with Fudd's first law of creativity that "to get a good idea, get lots of ideas."
Yin-Zen "Johnny" Hwang - Feb 25, 2009 01:46:51 am
This is just like what we've learned in class, and what I've learned from doing my own programming projects, that the best way to get going quickly and not get bogged down in the details of implementation is to sketch everything out, not just for the interface, but also for the flow chart of which screen advances to which screen and which data is needed when and where and how the database should be built. and for all of this, using paper for sketch is really great. from paper, it's easy to label on the drawings later how many pixels should be allocated to what part of the interface, etc.
interestingly, i never applied these ideas to building powerpoint slides, which is why other than color schemes and some animations here and there that i plan out ahead of time, it's still semi-crappy (not as good as i want it to be).
Gregory Leshner - Feb 25, 2009 01:59:21 am
I'm tempted to say ... but of course ... doesn't everyone do lo-fi prototyping? How could you not? Alas, they don't. I can tell you from experience that it is the exception and not the rule. The interaction with users and "playing the computer" is a fun way to actually see your designs in action, or more importantly, not in action. The other big point in the article is that hand drawings allow others to comment freely on your design. A finished drawing leaves no room for criticism as too much work has already taken place. I have been victim of this in the workplace where people working for me have brought me "finished designs" for review and then taken great offense at the changes I wanted to just try out. Didn't I understand how much extra work I was causing them ... and I didn't even know if something would work?! Paper designs let everyone in the process participate.
Dwij Garg - Feb 25, 2009 02:20:55 am
Low-Fidelity Prototyping seems like a very beneficial, efficient, and easy to use and create way of checking, refining, and bettering a user design before it is let loose in the real world. This article shows us how to do so in a very straight-forward way: assemble the necessities such as paper, note-cards, markers, etc; set a deadline so that no too much time and energy is spent; and finally build models not just illustrations so that the refinements actually have depth and usability. This is a great way to work through a design with a third party view and eye. It definitely helps in making the design better, and this article sets a great way of going about doing this.
Kevin Nakahara - Feb 25, 2009 02:31:18 am
First of all, this is one of my favorite readings so far; it is very well written and isn't overly verbose. I agree with most of what the reading had to argue regarding the effectiveness of lo fi prototyping. I think it's probably a waste of resources to invest much time (even if compared to the end products, its not that much) in creating an electronic prototype when a paper prototype is just as effective in gaining user feedback, is cheaper and easier to implement, and is easier manupulated by test users. The part where the reaidng suggested that hi fi prototypes simply encourage feedback regarding fit and finish especially had me thinking about how test users may overlook the prototypical nature of hi fi prototypes, and how lo fi prototypes would defuse that confusion. I also think that the use of lo fi prototypes helps ensure that final products just don't become mutated versions of hi fi prototypes.
Sean Ahrens - Feb 25, 2009 02:21:34 am
Good article. I think lo-fi prototyping is an excellent idea and should be done more. I do have a couple questions about its use in developing some modern day applications, however. My main curiousity arises to the question of how well lo-fi prototyping works for heavily variable textual and information-heavy interfaces, like a search function on a site for example. The user can type in anything to the search field, and subtle variations of searches could yield significantly different results. Furthermore, a use may use the results of an initial search to help them refine the search terms of a second. It seems to me that these points would make perfoming the task of "computer" quite difficult: you have to take in an indefinite amount of input, and produce output with subtle, yet systematic differences. The output you give for related searches should be systematically related. In light of these points, I am presenting the open question of whether or not lo-fi prototyping works well for software such as this.
Next, I wonder about the feasibility of lo-fi paper prototyping for software that will use sophisticated input mechanisms like multi-touch input and accelerometer input. It seems clear that the finger can work as a good substitute for the mouse in paper prototyping, and the voice for the keyboard -- but it is unclear how a user would communicate her input to a multi-touch or accelerometer device, especially since some exploratory movement with the device might be crucial for the user understanding the input mappings.
Lastly, I have the question of how well lo-fi prototyping would work for realitively simple interfaces, ones that don't require complex interaction design decisions. Such as a free, simple online question answering service. It's my impression that in certain cases where really no complex design decisions are required, the metrics of success of design are much more subtle -- like the time it takes users to finish a short task, or how much more friendly the experience with this software felt than a very similar competitor. I hypothesize that cases like these would be ones in which the distinction between design alternatives depends on data that is difficult to obtain via paper prototyping.
Stephanie Shih - Feb 25, 2009 02:54:09 am
Making lo-fi prototypes just seems sensible, a fact which this article backs. It seems silly that a group might go into this huge effort to make something hi-fi in the beginning stages, but that's what apparently does happen. Granted, a lo-fi model might not mimic the actual idea in the designer's mind, but it is precise enough to be useful, at least to start with.
Regarding the article itself, it was well-written and concise. It got its point across clearly without being overwhelming, and thus was easy to understand. It's definitely one of my favorite of the readings we've had so far.
Derek Liu - Feb 25, 2009 02:57:42 am
We talked briefly about lo-fi prototyping in class and the first parts of this article were a more in depth explanation of the advantages of lo-fi prototyping. Indeed lo-fi prototyping is the smart way to go about testing an in the works project for the various reasons listed in the article. There have been a few times that I have spent many days creating a coded software prototype only to have to spend more painful hours revising it to meet other peoples' critiques, having to deal with debugging and computer crashes/blackouts all the while. Had I thought to create a lo-fi prototype the process would have gone much smoother and I would probably not have to worry about going bald at an earlier age. The article was straightforward in its explanation of how to create a lo-fi prototype and how to go about running a session. I personally feel as though the facilitator is not needed in the prototyping process however. In my experience, good interfaces have been self explanatory ones that I could learn on my own by a few simple button presses. If anything, the user should be given an explanation of what the program does at the beginning and then use the prototype while describing his experience to the camera for later study.
Salman Rahman - Feb 25, 2009 03:39:04 am
This is actually the first reading we have done in a long time that I have actually enjoyed reading. I especially liked the style in which it was written. It was more of a narrative as opposed to a pretentious paper attempting to define common sense terms, etc. If I had never known about lo-fi prototyping and I was put on a design team tomorrow, the approach I would take to prototyping would be to develop a fully functional design. I feel like that is a common misstep that a lot of people make. The article points out many reasons why this is not the optimal way to go about developing prototypes. First off, it is way more expensive. Secondly, it's hard to change things around in response to user feedback. Thirdly, users assume this is the final project and focus on minor issues like background color instead of how the interface actually works. Fourthly, designers would be resistant to changes since it does require a lot of work. Lastly, and most importantly, a small bug in the hi-fi prototype could stall the entire feedback process.
It makes a lot of sense to use lo-fi prototyping because it's a very cheap and malleable process. It is easily redesigned and you can get feedback from users on the big picture things. Also, it sounds like a lot of fun to work with glue, crayons, and construction paper!
Phiroath Chan - Feb 25, 2009 03:48:17 am
I totally agree with all the disadvantages of using hi-fi prototypes rite away. It seems to me that the only advantage to using a hi-fi prototype would be for presentation purposes. If the design team lacks art skills they might feel inclined to use a hi-fi prototype, but then again testers will tend to comment on the presentation of the game(color, font) more so than the actual gameplay or interface. So is using hi-fi prototypes for the reason of presentation really a good idea?
I also agree with the problem of the programmer too prideful of his code to change it. It really leaves no room or flexibility in changing the gameplay or interface when the coder likes programming his way. A solution would be to have another programmer add the changes to the prototype, but that takes additional time for the new coder to read and understand the old programmer's code. All in all hi-fi prototypes are not bad, i just think that one should not start the first design phase with a hi-fi prototype.
Victor Lum - Feb 25, 2009 03:56:04 am
Low-fidelity prototyping seems like a really good idea, allowing you to quickly create stuff to try out on target users, and some other benefits that I never really thought of like setting expectations too high with high-fidelity prototypes. I liked the part where the says that as interface designer, we need to know our users, and that we aren't our users. The more I think about this, the more it seems to be true. This is why it's important to quickly throw out a lot of ideas with low-fidelity prototypes to see what works for people.
Raymond Young - Feb 25, 2009 04:01:51 am
After reading about lo-fi prototyping, I'm quite eager to give it a try. It seems very simple and a great way to get solid and honest feedback on design ideas. It's great to take the time and figure out what you want your end product to accomplish "inside the user's mind" and how to execute the actions to get to that goal state. Metaphor: If you want to sink a ball in pool, and you aim and say "that looks good" and shoot without actually taking the time to focus on the best way to execute your shot, then you are not going to make your shots very often or with very much consistency. This would be the equivalent of building your design, and then going for it without any feedback other than you telling yourself "sure, that looks good". Upon implementing your design, you take your shot, have a high chance of missing something important that could have been obvious had you taken the time to focus on your possible actions and their outcome. It takes much longer and yields less success to make many bad interfaces than to spend some time getting user feedback with lo-fi prototyping and getting a solid result on the first try.
Alexei Baboulevitch - Feb 25, 2009 03:44:13 am
Lo-fi prototyping is clearly a good idea, but most of the advantages presented in the article rely on the fact that people perceive non-software interfaces in a more design-oriented way. This seems like a "hack" to me, since it forces designers to use a potentially inefficient method in order to trick users into providing correct feedback. Perhaps there are better ways to solve this problem? (On the other hand, the prospect of working "just like kindergartners" sounds like a lot of fun!)
Low-fi prototyping has some issues of its own. For one, the timing will be completely off. In most cases, this probably won't make much of a difference, but users will undoubtedly interpret a slow interface differently from a quick one. Also, some modes might not work in the intended way. As we know a recent article, quasimodes are acceptable because users associate the mode with holding down a button, and this would be very hard to represent in a low-fi prototype. As far as I can tell, there is no way to test real-time interactions such as those found in videogames.
Nalditya Kusuma - Feb 25, 2009 04:25:19 am
The reading is just the paper-version of what we have learned in class and other readings about low-fidelity prototyping. Basically just do a low-tech design rather than hi-tech because if you do hi-tech people will judge not by the functionality but instead of designs, colors, alignments, and others. Other than that, building hi-tech prototype might take a long time, and the programmers might be hesitant to make major modifications to it coz they have already spent too much time on it. The reading also suggests to do the iterations as fast as possible to get the major problems solved in the beginning so that no major bug need to be resolved in the future.
Chao Michael Zhang - Feb 25, 2009 04:42:47 am
This reading describes a very interesting approach towards developing user interfaces. Though I have been developing interfaces for quite some time for web applications, the approach I've taken is completely different, since the design of web interfaces can be modified extremely quickly, and with more recent technologies even completely first hi-fi prototypes can be developed in a very short period of time. I'm very interested to know how well this lo-fi approach will work.
Another interesting point in the reading was that lo-fi prototypes don't have to LOOK half baked. Instead, they can be very polished designs created with drawing software and printed using a printer, rather than a messy, hand-drawn pencil sketch that I previously invisioned when I heard "lo-fi" prototype.
Aaron Hong - Feb 25, 2009 04:44:48 am
I'm a huge proponent of lo-fi prototyping. I think, similar to the storyboard for an animation studio (also applies to user interface designs), it lets you try so much stuff in so little time. From a computer programming stand point, I remember in a interview one time the testing lead told me that their philosophy is to catch things "up stream", i.e. as close to the source as possible (or as close to the beginning as possible). So that means, catching bugs as early as the design phase, otherwise they start losing money the farther a bug gets down the "stream." I think in a similar sense, the lo-fi prototyping helps catch these bug as soon as possible. It is definitely one of the most economic forms of prototyping.
I think another interesting thing is the concept of "construct models, not illustrations," that you can create separate components and move them around like a puppet show. I agree, there is so much conveyed in the simple motion of some paper versus a static image (it embodies the idea of showing over telling). The only problem, and they briefly mentioned it, is hesitation and slowness on the interface part. I think it should have be noted to avoid a interface that is overly complex, because I can easily image a person bumbling over trying to do a "drop down" effect through the paper, but only sticking the drop down menu in crooked and frantically trying to adjust it.
David Jiang - Feb 25, 2009 04:26:13 am
I think lo-fi prototyping is very useful. As with any project it is always best to design the project and makes sure everything is completely planned out and tested before actual coding. This will save both time and energy and will lead to less bugs in the future. In design, going back to different customers is always a good thing because the designers get a sense of a number of different people's opinions on how the GUI should be designed. At the end, once everyone is happy, then the coding and implementation happens, and finally, minor tweaks are added to the interface to make it just right.
Matthew Can - Feb 25, 2009 05:15:16 am
This reading was a nice introduction to lo-fi prototyping. One of the big ideas to take away is that formative evaluation is a useful and powerful approach to interface design. In the early stages of design, quantity of prototype (number of iterations) is more important than quality of prototype (how polished the product is) since the goal is to settle on a design that works from a usability perspective.
I most enjoyed the section on how to build a lo-fi prototype. Rettig suggests being creative in the use of materials and design of models. This is a good way to avoid the trap of endless design discussions by getting physical with a prototype instead. Our group began to fall into such a discussion at our last meeting when we realized that the discussion was pointless. We were debating about what kind of interface would be the right kind, but the fact is, we don't yet know what our users want in our interface or how they will choose to use our product. The solution is to start off by building something and running it through formative evaluation.
Bernardo de Seabra - Feb 25, 2009 06:13:39 am
In the article "Prototyping for Tiny Fingers" the author discusses the paper prototyping technique, also known as "lo-fi" and the advantages inherent to it. The author points out that the "lo-fi" prototypes allows the team to examine the general behavior of the interface as well as testing it with real users. An important advantage of this process is the cost reduction for the company since changes at an early stage are a lot less costly than the ones done later in the process. It also allows the team to iterate a lot more times since there is very little overhead in trying out new concepts. Since a reasonable number of different approaches will be considered and experimented the team is more likely to develop a good interface. While there are a few advantages to "hi-fi" interfaces these can also represent big problems. Besides taking a lot more time to be built, a "hi-fi" prototype is less likely to get changed by the team that put a lot of effort into due to their attachment to the prototype. In addition, if a problem is found during testing with real users it can't be fixed right away leading to a halt on the testing which could be costly, both financially and time-wise. The author then explores details on the process of building a "lo-fi" prototype, conducting the testing with real users and the post-testing analysis. Overall, this seems to be a good reading to understand "lo-fi" prototypes and all the advantages associated with them. I was never very supportive of "lo-fi" prototypes but this article opened up a venue for reconsideration.
Shendy Kurnia - Feb 25, 2009 07:48:14 am
I was not so comfortable about making lo-fi, and after do the reading, I still am not. I think coding right away would still be easier than try to make a lo-fi prototype. The reading argues that lo-fi prototype is easy and fast to create, so that revisions will not take so much time. If the design process was done with a good amount of considerations of different aspects, the interface will not be very bad. Therefore, revisions will not be very different from initial design. Hi-fi prototype, then, will still do-able, and maybe it will be easier and more feasible. I can draw windows, buttons, etc in Flash and keep them as my object. If I want to draw 10 buttons, I just drag and drop. However, I have to draw 10 buttons in making lo-fi prototype; not to mention, if I want to change the position of those buttons, I have to erase and re-draw.
Meiying Li - Feb 25, 2009 06:14:37 am
I strongly agree to this description about disvantages using hi-fi: "Spend enough time crafting and you are likely to fall in love with it."
I like the idea of using lo-fi instead of hi-fi. In fact, I am using lo-fi's myself when I am designing personal projects, and hi-fi's when designing projects that require submission of the designs. The thing is, if I spend too much time on how well the designs look, I might miss some important inspirations. I am a person who easily fall into the trap of refining small details. To avoid this, I need to force myself focusing on the big picture instead of minding every detail. From the reading I also learn that giving too much detail to the testers also distract them from focusing on the big picture that the designers care most about.
I have a question though: if we don't have enough people for dividing up the test roles, which ones can be dropped and which ones should remain?
Siddharth Shah - Feb 25, 2009 09:18:56 am
I loved this reading. It is easily my favorite reading so far this semester. It was short, talked about an interesting topic, and was written in an enjoyable style.
Now on to the actual content: Paper prototyping seems awesome. It's a quick, cheap way to get user feedback on issues that REALLY matter (not font size or color... those are trivial to change later). It keeps developers from getting too attached to their preconceived designs and makes them (us) more willing to adapt to users' feedback. It also helps the developers get MORE of that feedback, as users mess with updated designs in multiple cycles (rather than just critiquing the initial design once). All in all, it will create a much more user-friendly design in the same or less time as traditional prototyping. The advice he gave after introducing the idea (like the shopping list and how to actually go about doing the lo-fi prototyping) was really useful.
I recognized Fudd's first law of creativity: "To get a good idea, get lots of ideas." This is the same sort of thing that IDEO recommended and that we did in our group brainstorm. I also liked the two laws of interaction design: "Know your user" and "You aren't your user."
Overall this was a really enjoyable reading.
Sum Sum Wong - Feb 25, 2009 09:51:29 am
I found this week's reading very interesting and I like the idea of lo-fi prototyping a lot (and I think we've been doing this throughout the class). The reading starts with introducing the disadvantages of hi-fi prototyping, like, need a long time to build, user tends not to comment on hi-fi, developer resist to change, easy to be ruined by a single bug, etc, which was discussed in the class earlier this semester (and applied while doing the assignments of the class). Next, the reading presents the way to build a lo-fi prototype by using paper and note cards, etc which is quite useful in my opinion and I especially like the idea of "construct models, not illustration. And from my view, the figure 1. in the reading is an excellent paper prototype. And then in the "preparing for a test" section, the thing that really interested me was the role of an "observer", which I think is a good idea when performing a test since observers can be the most objective person of all.
Alexander Cho - Feb 25, 2009 10:41:54 am
At first it seems funny to move around pieces of paper in front of a test-user, but the article presented very practical reasons for this lo-fi approach. While taking cs169 we also talked about how users won't comment on the appearance/aesthetics of the UI because they see it as merely a prototype with sketches, so that they can focus on the usability and functions (this relates to the locus of attention, so that we have test-users focus on what we want to focus on). As programmers we are tempted to just program the prototype and many of us haven't cut and pasted paper in a while (though it is really fun). I would like to see this lo-fi prototyping in practice. I guess my only concern is the miscommunication and lack of direct mapping from paper to program that could arise from changing from the digital world to the paper world.
Eric Hernandez - Feb 25, 2009 10:36:35 am
This was an interesting reading that I largely agree with. There are clearly many advantages to the lo-fi method. Many different interfaces can be iterated through since little time is spent "specifying" each one. One point that I disagree with slightly is that "Hi-fi prototypes take too long to build and change." This was surely true at some point in the past and perhaps even true at the time this reading was written, but not so much anymore. From Java Swing GUI builders to Flex Builder, designing GUIs probably takes only a fraction of the time on average as it would actually drawing them. If the same process described in this paper for lo-fi was applied to these tools, then it would likely further improve the lo-fi method overall. This is because there is a greater potential to see problems with an interface when actually interacting with one on a computer rather than pretending to with a person acting as a computer, shifting cards and drawings around. The paper may then argue that the developers would "resist change," but this problem could be alleviated by forcing the team to come up with a minimum of a number of "mid-fi" (?)prototypes. Lastly, I don't fully agree with the statement "A prototype in software can set expectations that will be hard to change." If management and testers understand that these mid-fi app shells are created using prototyping software, no one will blame the development team for a sudden "lack of progress" when transitioning to a chosen interface.
Chris Thompson - Feb 25, 2009 10:33:04 am
This was a well-written read. The main point it's trying to make is that it is very worthwhile to make the initial prototypes of a user interface on paper. The point of the interface design is to go through as many iterations as possible, since each version will be made in response to some suggestion for improvement. If one were to use a high level language or prototyping software, there is still a very large time investment in each version of a prototype, meaning that even if the only suggestions you get are "Change the colors!" and "Move buttons around!" you'll still get fewer iterations for improvement than you will on paper. Not only that, but people are more likely to implicitly recognize that a paper prototype is just a mock up of the final design for testing purposes, and are less likely to comment on small, nagging technical issues such as "That font doesn't look right," which is a comment you will want to get, but not on every iteration of your prototyping process. Not only that, but the person who makes a hi-fi prototype has a tendency to unknowingly become attached to it -- because of the amount of effort and energy that it took to create, the developer develops an urge to defend the design decisions that might be called into critique. Then the article goes into tips about how to actually develop lo-fi prototypes. Have large, unlined paper at hand, as well as a variety of kindergarten style construction tools (scissors and colored construction paper and glue). It offers good ideas, such as creating modular designs by drawing a generic window border on one piece of paper and then the contents of any given window on individual pages, which can be swapped into the middle of the generic window as needed (ironically, that's about how it works on computers, as well). It also explains how to select valuable users for the test and record the experience -- preferably with a camera recording the whole event, one person acting as the computer, a separate person taking notes at the site, and a third person guiding the user and asking them questions. All in all, there's a relatively large amount of sound yet simple advice in this relatively small article.
Sean Kim - Feb 25, 2009 11:17:32 am
Hi-fi prototypes takes too long to build and change. So we need to consider the cost of delvelopment when we make an interface. Reviewers and testers tend to comment on "fit and finish" issues. The interface that we gonna develop is anticipated with the status of done when it is got on the user Developers resist changes. the interface is reluctant to be changed. so when we develop interfaces, we have to try a minimum of requirement to be changed A prototype in software can set expectations that will be hard to change. the requirement of being changed is more anticipated when it is the prototype in software A single bug in hi-fi prototype can bring a test to a complete halt. Since a single bug can be the siginificant point of implementation, we must be careful to develop a hi-fi prototype
Shoeb Omar - Feb 25, 2009 01:10:14 pm
I think the reading brought any good points to life about a subject that generally seems like common sense. Lofi prototyping makes complete sense because of all the problems that come bundles with making a hifi prototype. lofi prototypes are easy to change, alter, manipulate, even completely revamp. They have been the essential building block of every discipline that involves design for centuries, and that will not change in the years to come.
Prahalika Reddy - Feb 25, 2009 02:19:04 pm
I really liked this article, it was well-written and clear. The subject matter was also enjoyable. I agree with all the reasons that hi-fi prototyping is not a good initial step. I especially agree with the statement that when you have built a hi-fi prototype, the reviewers tend to comment on minor details. It's not something I would have considered before, but now I completely understand why that would be so. I also like the steps they've outlined for building lo-fi prototyping. I, personally, am always more inclined to draw something if I have lots of paper and colors in front of me, so I understand how assembling a kit is one of the first steps to lo-fi prototyping.
