Lo-Fidelity Prototyping
From CS 160 Fall 2010
pdf slides
Readings
Prototyping for Tiny Fingers. CACM. April 1994. 37(4): 21-27. Rettig.
Your Response
Login by using your user name and password, edit the page and at the end of it put a whole line == ~~~~ == (literally) at the beginning of your submitted critique, so the wiki system will index, sign and date your submission automatically.
Don Arboleda 15:49, 5 October 2010 (PDT)
The look into lo-fi prototyping was interesting. I could see the merit of using hand-made paper widgets and buttons; they facilitate rapid prototyping by being both quicker and easier to produce. However, I can't help but wonder how much work the "computer" has to do to make things go smoothly. As interfaces become more complicated (perhaps to support larger numbers of functions) the number of pieces the "computer" has to deal with grows. Although a good interface will probably never reach it, I wonder what the limit of size is before lo-fi prototyping begins taking longer than hi-fi prototyping.
Sean Tai 16:05, 5 October 2010 (PDT)
Paper prototyping makes sense for applications that must create a newly-designed, intuitive UI: it is an effective, cost- and time-efficient way to test a design before investing time into developing it. For applications that will mostly use pre-existing designs that are familiar to users, however, the preparation and analysis required for lo-fi protyping may outweigh its usefulness. It certainly is not a technique to be applied universally to all software engineering projects.
Chris Song 17:35, 5 October 2010 (PDT)
Reading on lo-fi prototyping was very interesting because, to be completely honest, I'm still not so sure about the merits of lo-fi prototyping vs high-level tools. I was very interested to learn that people actually use screen captures to design lo-fi protype. With familiar buttons and layouts mimicking the actual ones from the computer program, programmers can benefit from the fact that they can actually implement the results of lo-fi prototyping with ease. One of my concerns about lo-fi prototyping is that though it may give the user overall impression of functionality but cannot convey the excellent design choices, especially in the hardware. Imagine you were prototyping the original iPhone. And let's imagine there was a competitor with similar design. From lo-fi prototype how can the user know that iPhone response to touch inputs 100 times more smoothly than any other design out there? Most of the smartphones have excellent touch screen now, but when original iPhone came out that was not the case. In fact, before I phone I was one of the people who shy away from touch devices in general. Of course, it still makes a lot of sense for rapid testing and iterative design. But I think one must be very careful about understanding the limits of lo-fi prototyping before user testings in order to collect relevant data from the test.
Andy Lin 17:49, 5 October 2010 (PDT)
Based on the experience of designing user interface from the Contextual Inquiry assignment, I really feel that low-fidelity prototyping is really a useful and effective tool. It is easy to sketch and modify the ideas and functions on paper. As the article points out, it maximizes the number of times that designers get to refine design before designers must commit to code. It is also helpful for figuring out the relation between each function and interface by sketch. However, one thing that we should keep in mind is that we are not the user that uses our design. As a result, we should try to find our target users to try our design on paper before get into implementation process.
Jonathan Look 17:54, 5 October 2010 (PDT)
Lo-fi prototyping definitely has its advantages, such as being able to quickly incorporate feedback from testers and reviewers in a short time period. However, as mentioned earlier, there may be this issue concerning lo-fi prototyping and its effectiveness for large scale interfaces that pack more power and more complexity. I think the main downside to lo-fi prototyping when compared to hi-fi prototyping is the complexity involved with the role of the 'computer' when testing out the design. With many new WYSIWYG editors on the market, I wonder if a blend of both lo-fi with hi-fi components would be possible and better under some conditions.
Chao liu 20:06, 5 October 2010 (PDT)
Lo-fi prototyping give the designers most of the time think about how to have a good design instead of build the model. The point of lo-fi prototyping is that gives the “right” design and don’t waste too much time on building but thinking. For my opinion, it’s a good technique for beginner designer like us to learn and to use. It’s low cost and fast to get response. It’s much better to have the correct UI code than to correct the code for many times. However, it’s not perfect for lo-fi prototyping, we can not show videos or any animation to the users with only paper, and it’s hard to illustrate some details such as how to connect to the internet or use touch screen. After all, for the beginning of a design, it’s a useful tool and save a lot of time for designers to focus on the project.
Bernard_Wong 20:39, 5 October 2010 (PDT)
Early stages or design stages often are critical to a product's success or failure. The aesthetics of an application is becoming more and more demanding as drawing tools become more advance and more and more people know how to use them. The techniques in front-end development is more demanding in the production environment. A lo-fi prototyping help product designer create without being confined by the limits of the device, which is pretty oxymoronic, since this would mean that lo-fi prototype gives a higher degree of freedom than a low fidelity prototype. Creating within a group within coding is much easier, it also allows non-programmer to feel more welcome in giving feedbacks and inputs into the design phase. Like how Facebook took over Myspace, the design at an early stage can be very important. Designers should get as much input and feedbacks at this stage, as it would determine the general direction of the product and what it can leads to be.
Robert Connick 21:35, 5 October 2010 (PDT)
I couldn’t find anything to disagree with while reading the column, but the question of if/when hi-fi prototypes actually become easier to produce than lo-fi ones sounds intriguing. If there is such a point on the scale of interface complexity, it could be worth it to develop a prototyping framework that does literally what the “computer” does in lo-fi prototyping. Then that point could be shifted towards lower interface complexity and we’ll have something even more cost-effective than lo-fi.
James Butkovic 22:51, 5 October 2010 (PDT)
Due to the exponential cost of change curve, it's wise to develop the interface first, given that this needs to iteratively change based on feedback. Even though this is generally understood, Lo-fi prototyping is underused. High-fi prototypes in addition to taking a while to make, aren't as easy to criticize due to fear of hurting the feelings of its creator. Testing your prototype on user subjects won't be productive unless you prepare: select users, prepare test scenarios, and practice.
Kyle Gorlick 23:44, 5 October 2010 (PDT)
This article provides enough reasoning for me to think it silly not to do lo-fi prototyping. The only advantage I see of hi-fi prototyping is for testing the look-and-feel of the interface, but that will inevitably happen later. Also, the article brings up a good point in that it can lead to focusing too much on the appearance of the interface and ignoring the content/functionality. Another good point was how developers may resist changes after they have become attached to something they worked on for a while; something I have definitely done in the past
Tiago Bandeira 00:09, 6 October 2010 (PDT)
After reading this article the value of low-fi prototyping is apparent. Low-fi allows for much quicker revisions to the design than high-fi plus it makes test users focus on the interface rather than the specifics like the font or background color. I am very curious to see it in action since I am sure I will be impressed by its ability as most testers are after they use it. Furthermore, It sounds fun creating these prototypes with all the various craft supplies. Reading that section made me feel like I was in kindergarten again and it was craft time.
Alex Aberle 00:24, 6 October 2010 (PDT)
One trap of high fidelity design that isn't touched on in the article is that high quality prototypes can be very convincing to non-technical people. Showing a high-fidelity mock-up of an application to a room of managers is a mistake: they see that you already have an interface using real widgets, and they'll figure you'll have the app ready to ship in two weeks. In reality, almost nothing is finished, but good luck explaining that to them. "What do you mean six more months? All the text boxes already work..."
I also find it kind of funny that it takes a four-person team to successfully conduct a user study that consists of moving pieces of paper around. I admit that it probably would take some real concentration to be the "human computer," though.
I hope I get to work in an office with the kind of craft supplies they had in the article.
Geobio Boo 01:05, 6 October 2010 (PDT)
Loved it, and look forward to actually implementing low fi prototyping. In my previous experience in art (drawing competitions) getting an idea on paper was the hardest. It's hard to make ideas when I'm resisting or judging myself even before the pen touches the paper, but with a time constrant and minimal concern for looking pretty and shiny, prototyping is fast and draws out ideas from members. In Java/Android, making a clickable button takes a few mintues, but on paper, I'm hoping a complete project can be done in about an hour. Some of the things I liked most is suggestions on getting ample supplies beforehand with things like colored tape, clear sheets, etc. Also, like the flow/interaction style between test user and paper computer. Protyping should be fun, but the work will be to find the right users, and not only that, but to get the users in the right mindset--not to make them feel uncomfortable, feel like they're doing it wrong, and to have them take it seriously.
Yue Chang Hu 01:26, 6 October 2010 (PDT)
This week’s reading, “Prototyping for Tiny Fingers” is interesting. Although not too surprising that lo-fi prototyping can be a great help when designing user interface because 1 we mention about it in class before and 2 as mentioned in the article that it educate developers, help make quick refinement and testing. I too agree that lo-fi prototyping are benefiting, however, I think it would be even better if we can hide the demonstrator behind something, “may be a glass that lets a demonstrator see the user but not the other way around”, or anything that conceal the demonstrator’s face and expression because I think the demonstrator’s expression can and will have an influence on some users.
Theron Ji 01:51, 6 October 2010 (PDT)
Lo-fi prototyping definitely sounds like a good idea, and is argued for well in the paper. However, it also makes sense that this isn't that widely used in practice and lacks popularity. For one thing, software engineers are not known for drawing skills, and people usually shy away from what they're not good at. Also, a lot of people would rather spend the time and energy used to do this to build something more substantive, just because they feel a greater sense of accomplishment doing that. There are good ideas in this paper, and to a certain extent lo-fi prototyping definitely can be useful, mainly for quick purposes, but I think there are also definite limits on how useful it can be, and its importance should not be taken out of context.
Derrick Tao 01:57, 6 October 2010 (PDT)
Lo-fi prototyping is very important when developing an application. It allows a way to quickly get ideas onto paper and then evaluating those ideas with the client. This also allows the development team time to sort out ideas before actually coding them. Another good reason to use lo-fi is that it can be quickly presented to the users and see how they would interact with it and what would their expectations be. Hi-fi prototyping is still a good idea but its a lot more time consuming and sometimes those ideas might be later rejected thus wasting a lot of time.
Raymond Williams 02:18, 6 October 2010 (PDT)
There was once a game that had a 'feature' that made the game totally unplayable. There were tons of complaints about this on almost every board and forum on the internet. What happened when they released the sequel? It had the same game-breaking element. I always find it strange is when companies don't listen to their users. And they wonder why the game made almost no sales and the company went out of business...
I've even seen a marketing agency that hired someone to delete posts that criticize or point out the flaws in their product. Now that's just stupid! Not only are they ignoring their problems instead of fixing them, but now they're lying to the customer! Not a good idea...
Have you ever pressed the okay button when you get an error and that Microsoft message pops-up asking you if you want to send the information to them? No? Neither have I - but how is Microsoft supposed to know what they need to fix if people don't tell them. All they hear is "I don't like it" but there's no why. You see, it goes both ways. Companies need feedback, and users need to give it.
When I read the very first page of this document, I wasn't surprised. Many companies still put out the software that they want instead of what the people want. I think Lo-Fi prototypes are a great way to get massive feedback. It's sad that I haven't seen it much in the real world. Perhaps it will catch on when more people take CS160...
Melissa Lim 02:46, 6 October 2010 (PDT)
Lo-fi prototyping is a great way to get ideas out quickly so they can be tested before the coding process. Although it does require imagination on both the user and the creator's parts, is much easier to implement changes to lo-fi prototypes than hi-fi ones. I've heard that styrafoam and hot glue guns are great tools to work with when at this stage. This process of prototyping should be done early and often, as many designers say, in order to have time for many iterations and improvements. I can see why some people may view paper prototyping as trivial, but what they do not realize is how helpful this thinking process really is. If you go straight into development, there is not much as much room for flexibility in the overall idea; it is very likely that additional improvements or problem areas will be encountered along the way and changing code is more time-consuming than prototyping methods.
Brian Maissy 02:53, 6 October 2010 (PDT)
I'm excited to try it. I'm starting to think much more paper interface components are going to be necessary than I first imagined to produce something that responds similarly to a real interface. Some of the pitfalls I could see myself falling into are designing the interface the way I would like to use it and wanting to guide the user during tests. I'm worried that the user will feel awkward and confused when dealing with a paper interface, especially if it isn't visually appealing.
Daniel Yoo 03:49, 6 October 2010 (PDT)
Paper prototyping was a pretty nice for designers to start and make an intuitive UI. “Lo-fi prototyping works because it effectively educates developers to have a concern for usability and formative evaluation, and because it maximizes the number of times you get to refine your design before you must commit to code (from the reading).” Based on my experience, I do start the design in separate sheet of paper, quite often, then think through what to add and delete. Even in coding, I do not start right away with coding, but I allow myself to have a basic script to follow through my ideas. I think lo-fi is a lot like what I have done in previous work, but some are new and interesting.
Soroosh Izadian 04:21, 6 October 2010 (PDT)
What I like most about Lo-fi prototyping is the organization of tasks between team members during the tests. The greeter-facilitator-computer-observers model introduced in the text makes efficient use of time and resources by assigning only one responsibility to each team member. At the same time because all team members are involved in the test and have a chance to see potential users' interaction with their design first hand. What's more, the process of the test (preparing-conducting-evaluating results) allows the design team members to get more familiar with the design and also generate more ideas by recognizing the current flaws.
Bichen Wang 04:21, 6 October 2010 (PDT)
Although the benefits of lo-fi prototyping are clearly explained in the article, the article does not state what a good time to start doing this is or when to transition to higher-fidelity prototypes. Should the programmer start off with lo-fi immediately without consulting what the limits of the language are? What happens when we realize we don’t have enough time to implement all the ideas from the lo-fi prototype? In other words, when should a programmer start to create the real thing? According to the article, this is more of a general good thing to try given a lot of time to iterate. How beneficial is lo-fi when we can only meet with a few potential customers? Lo-fi seems to be an effective tool in making improvements in products, but the article does not make clear any timeframes or prototyping schedules.
Mark Wei 07:08, 6 October 2010 (PDT)
The article certainly sells me on the idea of lo-fi prototyping. I think much of why developers don't even think about doing lo-fi prototypes is that it is too basic. Every developer wants to create something pretty, and lo-fi is decidedly not pretty. Because of this stigma that lo-fi prototyping is for those who have less skills, many developers might be reserved about trying it. Also, we tend to overestimate our ability to quickly generate hi-fi user interfaces. Especially with high level tools, it is very difficult to get the layout exact how you like it. But because we fail to realize the speed benefits of lo-fi prototyping, we keep sticking with hi-fi prototypes.
Christine Lu 09:33, 6 October 2010 (PDT)
Although the article presents some good arguments towards using lo-fi prototyping, namely the ease with which the developer can change prototypes, the low-cost, and the speed of refining future iterations, there are also some drawbacks that the article doesn't touch upon. Namely, I'd like to bring up the fact that for most people, we're not used to this type of prototyping. When we are asked to give feedback on an app, we expect to be able to actually use the app on a mobile device, but being presented with cardboard immediately makes the user uncomfortable and unfamiliar with the process, and thus skews the designer's results. Asking the user to simulate using a mobile device while not actually using the mobile device will bring up a lot more confusion for the user which might get translated into how they are using the lo-fi prototype, which may further be noticed by the interviewers and mistakenly identified as a design flaw, rather than just a confusion because the design is not in it's normal state.
Courtney Wang 09:41, 6 October 2010 (PDT)
Lo-Fi prototyping will be particularly useful to most of us because it will force us to step away from the computer and code and just get our interface ideas out on paper; in the process of creating the interface, we have to focus all of our attention on it. The use of paper widgets and flexible interfaces is also really important in the iterative design process because of how much time it saves. Moving a paper widget around a screen is much easier than having to use DroidDraw or layout commands to get a button exactly where you want it. I think the issue of not being able to communicate all the features that a hi-fi prototype might (such as the awesome responsiveness of buttons or screens) is a feature of lo-fi prototyping, not a disadvantage. Once you have the lo-fi done, you know your interface will only go up in terms of usability. The focus is purely on functionality, and if users can stand the waiting times of the human computer and some of the more primitive aspects to still have a good time using your application, it means the transition to actual hardware will be tremendous.
Alexander Wong 10:04, 6 October 2010 (PDT)
Lo-fi prototyping certainly has a wealth of benefits and it is something that I hope to try in the future. The article mentions that many users walk away skeptical of the idea after hearing it for the first time. I was certainly in the same boat, but the article made enough good points to convert me. My main issue with lo-fi prototyping before, and now this no longer bothers me as the benefits seem to outweigh this possible negative, is the question of how a lo-fi prototype can yield hi-fi results. The article addresses this by mentioning that the point of lo-fi prototyping is to learn about high level issues with your interface, such as work flow. Eventually it seems that you will have to transition to a more detailing prototype to yield more detailed results. Perhaps, iterating on paper and the use of Photoshop will be enough to naturally product higher resolution feedback.
My other concern was whether or not mimicking a computer with a human is good enough. It's certainly a different experience sitting in front of a simulated computer than your natural work station.
Lastly, how detailed should the lo-fi prototype be? If we can introduce tools like printers and computer graphics, where do we draw the line? I suppose at any level of detail we are still avoiding the need of programming the UI.
Benjamin Carpenter 10:40, 6 October 2010 (PDT)
Low fidelity prototyping is good for quickly generating lots of designs for applications. It is definitely much faster than using a GUI API to code up the actual UI for the program. Besides the speed of rapid prototyping, I think one of the main improvements of the low-fidelity prototype over the high-fidelity one is perhaps that the Low-Fi prototype doesn't distract the user from the purpose of the program nearly as much as a hi-fi prototype would. It is easier to focus on the essentials of the interface without all the glitzy effects that occur in the real UI toolkit.
Edmundo 10:46, 6 October 2010 (PDT)
After reading this, it seems like low-fi prototyping is the ONLY way to go about developing an interface. What I find that sounds the most useful is that it gets users' feedback on "the big things" and ignores all the "fit and finish" issues. A low -fi prototype helps keep user concentrated on the tasks at hand and on the mechanics of the interface, ignoring presentation. This kind of reminds me of web pages and how HTML is coupled with CSS so that HTML simply puts forth the structure of a webpage and CSS handles the looks. This ends up working quite well since having the structure separate makes it easier to go back and make any amount of changes to the presentation of a web page. I think that the same goes for high-fi prototyping, where the developters have invested so much time into their design that they become reluctant to reconstruct it or make drastic changes to the interface.
Alexander Bolotov 10:59, 6 October 2010 (PDT)
This article describes a process that, after reading it, seems rather obvious, and yet, as I know from experience is not so. The technique described allows for many iterations of design, each with a test that fleshes the design out and improves it. This procedure came naturally to me back when I tried my hand at mechanical engineering in a high school robotics club, when a crude mockup of the design as a proof of concept was the natural thing to do. And yet it has never occured to me before taking this class that the same procedure can be used in the design of computer programs, and is in fact of great importance for designing a interface that not just claims to be user-friendly, but is in fact so.
Vincent Rodriguez 11:12, 6 October 2010 (PDT)
Lo-fi prototyping seems to me to be a must in every project that involves UI design. At the very start of the project, the designers/programmers can't be too hung up on how to actually code out the UI since this will invariably take a long time and won't actually tell them anything that the lo-fi prototype wouldn't already tell them (at least, if it was a big picture idea kind of thing.). Of course, just because if it seems that the team has solved everything during the lo-fi tests doesn't mean that they can forego more testing after they've built out their actual program since there can still be bugs or previously undiscovered problems with the design that the lo-fi prototype failed to catch.
James Yu 11:14, 6 October 2010 (PDT)
I thought the reading was a pretty good look at lo-fi prototyping. I understood the main point of lo-fi prototyping, which is to maximize the amount of design iterations in a given time. Also it lessens the attachment to a design that can happen from investing a lot of time into a hi-fi prototype. Also it gives good detail on how to conduct a test (the steps, as well as roles for group members), enough my group can probably use it to do our project. I liked the tips it gave on what supplies to get for lo-fi prototyping, since I was not aware acetate can play such a big role. It also convinced me that hi-fi testing is not always appropriate, although, as a web developer, I tend to use "hi-fi" prototyping since an iteration for a web page design can be very quickly done even when writing actual html.
Samantha Paras 11:19, 6 October 2010 (PDT)
This article was very good at convincing me that lo-fi prototyping is necessary when trying to improve UI. It sounds like a good way to solve problems before any coding is done. However, I don't believe Hi-Fi prototyping should be ruled out either. A computer or mobile device is very different from paper, and one might see problems there that they didn't see with lo-fi prototyping. I think this is especially true because a lot of people use computers and smart phones daily and may be used to certain behaviors. I also think it's very helpful that they defined all the different tasks group members have to take on. This should help when we have to do our own Lo-Fi testing for our apps.
Richard Nguyen 11:27, 6 October 2010 (PDT)
I thought that this article was a great way to sell lo-fi prototyping. I really liked how they compared the iterative design process as a natural selection process where the most usable ideas make it through. It really emphasizes how quantity of ideas is essential in obtaining quality ideas. I also feel like setting deadlines is also very important to the prototyping process. In our projects now, I've begun to notice that progress is always very slow in the beginning, even after the over arching ideas have been formed because our members are too hung up on working out every detail before starting. Sometimes it's better to get a broad plan, and work out the details on the go.
Sui Kun Guan 11:30, 6 October 2010 (PDT)
Lo-Fidelity Prototyping is a very good technique for designing an interface. In contrast, high-fidelity prototyping has some obvious disadvantages. One of the big disadvantages is that the designers actually design the interface and transfer it into code before the interface being evaluated by the users. If designers find out they have to change the interface, it requires lots of works to recode it. However, for lo-fidelity Prototyping, designers write down the interface on paper, and test it with some typical users, and change the interface after getting feedback, and repeat this procedure many times before actually transfer the interface to the code. This can significantly reduce the changes after coding the interface because it already tested by some other users. This big advantage in Lo-Fidelity Prototyping makes me like the Lo-Fidelity Prototyping than the High-Fidelity Prototyping.
Adam Vogt 11:31, 6 October 2010 (PDT)
I think this paper makes some very good points about the need to develop prototypes quickly. It makes a lot of sense to avoid worrying about the internal mechanics of your application when you are focused on the user interface. However, I wonder had this article been written today and not 16 years ago if they would still be as focused on a lo-fi paper model. Today there are several rapid prototyping tools that really don’t take any more time than paper prototyping. These tools have many different benefits over a pen and paper and for someone like myself who is really clumsy with a pen and paper a rapid prototyping tool would likely produce better results much more quickly.
Albert Tseng 11:44, 6 October 2010 (PDT)
The reading on low-fidelity prototyping introduces the many benefits of this prototyping technique. The maximizing of design iterations is without a doubt the most appealing aspect of this technique. Being able to improve a design rapidly and frequently before committing to code is a crucial factor in producing successful designs. It would take work to switch to using this technique instead of hi-fi prototyping, as well as to train the development team and to make proper preparations for using this technique (such as assembling the kit). However, the benefits make lo-fi prototyping worthwhile.
Karthik Jagadeesh 11:47, 6 October 2010 (PDT)
Lo-fi prototyping seems to have many advantages, especially the fact that you can change the design of the product many times, and also you can change it very easily. I think the article brings up a good point that people get attached to ideas that they spend too much time on, and since lo-fi prototyping is just a paper prototype it should be very easy to design multiple iterations of the product and not get attached. The one thing that I am slightly concerned about is how realistic the demo would be when we test it on the user. Since its a paper prototype you would have to have a human watching the user's every move, and changing the papers as they interact with the papers. This seems like it would be very slow and prevent the user from the true experience. Also the article mentioned that it is really easy to incorporate "bugs" into the program and this will mess up the experience. It might make sense to create a bare bones version of the product, and every two weeks iterate on this version of the product after getting feedback from users. This way by the end of the 4 months you would have gone through many iterations and you wouldnt feel that attached to any of the initial versions of the product.
Aaron Loessberg-Zahl 11:51, 6 October 2010 (PDT)
I really like this reading--not because it explains something new and unknown to me (we've talked about lo-fi prototyping before)--but because it explains in detail how to execute it. The preparation, finding of participants, and the testing itself is all explained clearly, and in a way that is easily replicable. I foresee our group using this guide a great deal as we develop our app.
Frank Chew 12:05, 6 October 2010 (PDT)
I was surprised to see lo-fi prototyping of acting like a computer beat the Visual Studio solution of RAD prototyping. I suppose the the lo-fidelity prototype works better than the VS RAD prototype because team members don't have a way of suggesting changes unless they know VS, whereas anyone can draw on paper, thus allowing anyone to contribute to the design. Plus even if they can't draw, it is easier to direct the designer to draw than to use Visual Studio. As a result of this article, I learned that Lo-fidelity prototyping is surprisingly simple yet effective.
Calvin Wang 12:08, 6 October 2010 (PDT)
This short column is amazingly illuminating. I can't believe how many times it made me smile - lo-fi testing is such an efficient method and it's fun, too! I am now looking forward to doing this for my group project. I haven't touched my art supplies since high school art class!
Robin Liu 12:18, 6 October 2010 (PDT)
One theme of low-fi prototyping is that interface design can be treated as a separate field from software engineering. The concerns in interface design and evaluation can (and should) be treated independently from the implementation, because the issues addressed with user interface are largely not technical. The low-fidelity approach not only improves the design process in its simplicity and ease of use, but it also allows the designer to ignore implementation issues and focus exclusively on usability. This abstracts the interface design process to a separate activity from coding, allowing the designer to make optimal design decisions. Low-fidelity prototyping also allows the designer to test multiple designs with little overhead.
Steven Kisely 12:50, 6 October 2010 (PDT)
The lo-fi form of prototyping is so simple and elegant I believe many do not appreciate how useful it is. It allows all the forms of prototype testing a real prototype would without having to spend a day or 2 implementing it. By the end of the design cycle a week may have been lost implementing different prototypes. These prototypes could have been planned and set up in an hour or less for each prototype using low fidelity.
Arthur Huang 12:53, 6 October 2010 (PDT)
I found lo-fidelity prototyping to be very relevant to our programming design assignment. It is very important to get the ideas and designs out on paper first, because it is inexpensive and efficient, and then to test it with potential users and see their feedback. It really does hit all the requirements of prototype testing, without having to code the real product. Changing a design aspect is also very easy with lo-fidelity prototyping, because no real work has been done yet, so any changes can be easily incorporated, as nothing is set in stone yet. I find this as a very important aspect of any design process.
Asa Zernik 12:55, 6 October 2010 (PDT)
The lack of debugging is probably the number one advantage (IMHO) to having a lo-fi prototype where a human developer acts as the "computer" - a computer that can literally understand pseudocode and verbal descriptions, saving the slog of hard implementation.
Another note: the use of cutouts to represent blank widgets, rather than drawing illustrations, fits in very well with the metaphor of the human controller as the computer, where the paper cutouts stand in for the objects and classes of a graphics system.
Avery Gee 13:08, 6 October 2010 (PDT)
I think the argument for lo-fi prototyping is a good one. I really don't see many advantages to the high fidelity way in the grand scheme of things. It seems very unlikely that you would get it right the first time, thus it would be best to mess up when the cost of redoing something is simply printing out a new paper widget. The article mentions some useful strategies, namely the different kinds of materials to use and the different roles for the group members to take. I also think that the point about not hand drawing everything is interesting because it shows that there is a border between lo-fi and really lo-fi. I think it would pay off to make your prototypes look as sharp as possible while still remaining lo-fi.
Richard Laroue 13:13, 6 October 2010 (PDT)
Low fidelity prototyping provides a very useful means for getting raw ideas down into something concrete. They enable designers to express their ideas. Also, they are a great way to get feed back from users that will then guide improvement and the eventual final design. These prototypes don't have to be 'final', they just have enough to give test users an idea of what to expect so that they can give their feedback.
Alan.choi 13:16, 6 October 2010 (PDT)
Lo-Fi prototyping seems to be very useful and seems to be quite a good idea because of how you can see and analyze the interactions between the user and your expected abilities and experience from the application that you envisioned. Fruthermore, a lo-fi prototype would be all about the functionality, and never really about the aethetic, which would be more relavant during the hi-fi prototypes.
Jeremy Sasson 13:18, 6 October 2010 (PDT)
Lo-fi prototyping is a valuable tool because it is less costly in terms of time. It is important to get a vision of what you are working on and to get a feel for how the user interface works with a physical feel before you invest the incredible amount of time it would take to render the interface on a computer.
Terrance Ng 13:20, 6 October 2010 (PDT)
Lo-fi prototyping is definitely important because it costs much less time than high fidelity prototyping. It allows the designer to quickly design the interface, rather than spend time writing code. It allows the user to see how the interface would function, rather than get caught up in not offending the developer.
Sung Ma 13:21, 6 October 2010 (PDT)
I think that low-fidelity prototyping is one of the most effective tool. It is outstanding that it can maximizes the number of times that designers get to refine design before any kind of code is committed. Also, it is easy to use since it has low cost, very fast response. Although low-fidelity prototyping is one of the most effective and useful tool, there are downside to it and we should always becareful when and where to use this tool.
Karl He 13:23, 6 October 2010 (PDT)
Lo-Fidelity prototypes are a great idea. User interfaces are not easy to program. Even a mockup in something relatively easy to work with like HTML can still take a great deal of time. A Lo-Fi prototype is easy to make, and although it lacks the details that would be present in the real interface, it allows you to gather user feedback much more easily with much less commitment on the side of the programmer.
Anthony Puccinelli 14:00, 6 October 2010 (PDT)
It would be easy to scoff at lo-fi prototypes because of their kindergarten appearance, but the concept of using them is, in fact, quite genius! It lets you refine many of your ideas before you've put too much effort into implementing them and thus saves you much of the costliness of the alternative. It also allows for multiple rapid prototypes that take feedback from potential users into account instead of just one or two prototypes, since the prototypes you're making are so incredibly low-cost both in terms of time and money. Flexibility is key to success in a marketplace as volatile and packed as, for example, the iPhone app store, and in the light of this, the attractiveness of rapid paper prototyping becomes undeniable. (Note: I neglected to post before class this time because Monday's readings stated "There will be no responses this week." and I did not understand that did not refer to this work-week in its entirety).
Frank Chew 20:35, 10 October 2010 (CEST)
Sorry about the late turn in date: Monday's readings still reads "No comments are needed for the readings this week. "
I was surprised to see lo-fi prototyping of acting like a computer recommended over the Visual Studio solution of RAD prototyping. I suppose the the lo-fidelity prototype works better than the VS RAD prototype because team members don't have a way of suggesting changes unless they know VS, whereas anyone can draw on paper, thus allowing anyone to contribute to the design. Plus even if they can't draw, it is easier to direct the designer to draw than to use Visual Studio. As a result of this article, I learned that Lo-fidelity prototyping is surprisingly simple yet effective way to prototype.
Simran Chaudhry
I thought this was an awesome article, and really did persuade me about the values of lo-fi prototyping. The one benefit of lo-fi prototyping that I never considered before was, with a hi-fi prototype, people will more often make comments about the look and feel, rather than the flow of the UI. Also thought these were awesome quotes: "To get a good idea, get lots of ideas" & "Know your user...You arent your user"
