Low-Fidelity Prototyping

From Cs160-sp08

Jump to: navigation, search

Lecture on Feb 21

Slides

Lecture Video: Windows Media Stream Downloadable .zip

Contents

Readings

Hsiu-Fan Wang - Feb 19, 2008 12:57:54 pm

I was already sold on the power of lo-fi prototypes before this reading, so it was a bit like preaching to the choir so to speak. I am always kind of impressed by how the higher fidelity your design, is the more people will nitpick inconsequential details, I first encountered this when doing web design, where people would nitpick copy text that was usually unimportant (ironically, using lorem ipsum text often would simply derail conversations as people would ask what it was, where it was from, etc).

In my opinion though, with the relatively high expressiveness of HTML its often easier to run through mockups presented in web page format, if only to save users from terrible handwriting. (There are also some libraries of browser UI widgets that are helpful for generating mockups relatively quickly in any drawing program), and I wonder if perhaps lo-fi prototypes might actually work better when done on a computer and not on paper.

(EDIT: before everyone else jumps on my comment (which was admittedly poorly expressed...) what I'm saying is that with the availability of things like HTML and Photoshop/Illustrator I'd say the lo-fi end is getting eaten into by "mid-fi" becoming easier. That is, the difficulty of creating things that are a step above paper in quality and interactivity is decreasing. An observation, not an evaluation of the merits of anything in particular. That being said, the meetings work better when you make the HTML/PSD and then print them, so that people don't argue about color.)

Michelle Au - Feb 19, 2008 01:25:31 pm

The comparison between formative and summary evaluation reveals an important weakness with hi-fi prototyping. Rettig points out that hi-fi prototyping still involves programming, which means that there will be bugs in the prototype. There will also be bugs in a lo-fi prototype. However, the key difference is that when these bugs are discovered during testing, changes can easily be made to a lo-fi prototype while changes to a hi-fi prototype will normally have to be made after the testing session. I agree with Rettig that the sooner changes are made, the better. By fixing the bug in a lo-fi prototype as soon as it's discovered, the tester can still continue to test and also potentially discover more bugs that were masked by the first bug. With a bug in a hi-fi prototype, the tester will have to continue the test with the bug unfixed, perhaps reducing the scope of the test. Then more bugs will not be discovered until the next testing session. Project deadlines will mean that there will be less iterations with the hi-fi prototype and less opportunities to work towards the perfect design.

Eric Cheung - Feb 19, 2008 05:32:59 pm

Low-Fidelity programming seems like it would vastly reduce the turnaround time between revisions of a given interface. Granted, there are some things you probably can't simulate exactly through paper, but it at least gives the designers a chance to iron out the general look and feel of their interface. It would also seem to be important to make sure that the users participating have a general idea of the limitations of the prototype. This would mainly ensure that their comments are directed more at the interface itself than at the means by which they're using it.

I tended to agree mostly with the arguments against hi-fi prototyping, namely the resistance against change. It can often be tempting to just modify small things from the prototype into the finished product, since you already have some of the code there. Additionally, if it took a long time to learn the framework to implement the prototype, you'd be even less likely to change it. Alternately, you may not even know enough about how to change it and be forced to do more research.

Nir Ackner - Feb 19, 2008 05:59:26 pm

One thing that I find particularly interesting about lo-fi prototyping is how it forces the user and designer to slow down and do many adjustments manually. The slowing of the interaction might be part of the reason the designer is more apt to be sensitive to interfaces that try to do too much in lo-fi programming. For instance, the flaws of a design that requires drilling down several layers of unnecessary menus would quickly become apparent in this setting.

Another interesting point is that much of the techniques that Rettig describes for making things fast when doing lo-fi prototyping are applicable when transitioning to medium fidelity prototypes. For instance, screen-shot based prototypes mirror the idea of Xeroxed UI components in Rettig's article.

Gerard Sunga - Feb 19, 2008 07:58:27 pm

The entire article seems to be a clear guideline for lo-fi prototyping. Rettig's arguments are convincing, given the considerable drawbacks of high-fidelity prototyping, such as the time and cost during development. I often find myself, especially after going so far along a project using a certain implementation, victim to these problems and become unwilling to change things I have done due to the great amount of time invested in the current product. However, it seems using this advocacy of lo-fi prototyping is a bit outdated, as we don't really need such primitive mock-ups to display ideas. Nowadays, with the advent of graphical tools such as Adobe Illustrator and the like we can put out a much clearer display of what a group's ideas really are.

Benjamin Lau - Feb 19, 2008 08:36:07 pm

I don't really agree that the paper prototypes in the article are outdated and somehow superceded by the coming of Adobe Illustrator etc. Those vector art programs are orthogonal to the issue being discussed. There's nothing to keep us from using paper prototypes that were created from art programs (and I think many do). It is my understanding that the 'low fidelity' in the article does not refer to the quality or cleanliness of the prototyped interface but the method of simulating computer interaction on paper (although other materials could also be good substitutes) before pursuing either a solution or a higher level prototype in which computer action is real and not simulated. I don't know about the HCI industry but for tabletop gaming and many other forms of geeky entertainment paper prototyping is standard practice. I thought Rettgig made some very good arguments against starting out with hi-fi prototypes. In particular his comments about buggy hi-fi prototypes struck a pragmatic chord within me. It already takes us long enough to debug final programs, we shouldn't have to debug a hi-fi prototype as well. All the serious bugs-- whether in the form of design issues or potential implementation traps-- should be dragged out in lo-fi prototyping early on, where it is inexpensive and not time consuming.

Johnny Tran - Feb 19, 2008 09:50:24 pm

Rapid prototyping is a very useful technique for interface design. The points that the author brings up about the effort involved in creating a hi-fi prototype and the relative inflexibility that results after one is constructed are very true. And lo-fi prototypes certainly have their place. I for one would like to see more arts and crafts introduced in the software engineering world.

I think it would be even more useful to have a "mid-fi" stage between a final interface design and a paper mock-up. Some sort of system where interface elements could be quickly thrown onto a window, with minimal code interactions and feedback would be immensely useful in fleshing out how programs work. Of course, it should be easily changeable, but there should also be a way to translate a mid-fi interface into a hi-fi one. I am reminded of Ruby on Rails where the programmer creates basic models and the framework generates basic scaffolding that later gives way to real code. An equivalent rapid-prototyping tool for user interfaces that implements this same principle would be immensely useful, as there is no sense that time was "wasted" creating the prototype. Visual Basic's interface builder comes to mind, although it effectively limits the programmer to a single language which will not work for all projects. But rapid prototyping is a valuable technique, and is something that I would like to see more in interface design.

Jonathan Chow - Feb 20, 2008 12:31:28 am

This article really reminded me of the benefits of outlining when writing a paper. Its one of those things that everyone says they should do, but very few actually do it (or at least do it well). Before I read the article or saw some of the things that we have gone over in class, like the IDEO video, I probably would have thought that lo-fi prototyping was stupid. I think that most of us just like to get into the meat of the work and start coding. But the suggestions made in the article have alerted me to many of the benefits of lo-fi prototyping. I really thought that the statement that "reviewers and testers tend to comment on 'fit and finish' issues" was a good point. If the prototype is lo-fi, then there really is only one thing to comment on, and that's the functionality. Plus, Rettig makes the process much more formal and planned out. I really wouldn't have thought that it would take four people to test a prototype. But I believe that he suggested strategy will lead to a much more professional testing and, in doing so, make the us feel less silly about using this method of testing.

Katy Tsai - Feb 20, 2008 01:33:24 am

Rettig definitely further iterates how important it is to thoroughly develop and design an interface before actually implementing it. This reminded me of a presentation I attended about design and implementation in a business setting. It's a big deal for companies to allocate their time and money efficiently and low-fidelity prototyping is key in achieving this. I think it's interesting because in most CS classes we just implement with the intention of finishing the assignment, but when the focus is on design and usability, we must completely change our approach. Oftentimes, companies require different iterations of prototypes just so developers have something to show from a business standpoint.

While the article is seemingly straightforward, Rettig brings up a very practical methodology that most of us aren't used to. While the design process seems to extend much longer with lo-fi prototyping, we save a significant amount of time and effort by reducing the number of iterations that we'd typically go through with hi-fi prototyping.

Brian Taylor - Feb 20, 2008 09:42:26 am

Well, I don't really understand how this article has anything to do with "tiny fingers", but it does give a very useful guideline for lo-fi prototyping. The beginning of the Rettig's article did not seem that useful, since we had learned enough about lo-fi prototyping in class that I was already a fan of using paper. The portion of his article on how to actually build, construct, and test lo-fi prototypes, however, is definitely valuable. I feel that after the reading about contextual interviews, I was still a bit unprepared to actually go and conduct an interview with a target user. It was not until after meeting with my group and clarifying certain aspects of the process that I felt comfortable doing so. Rettig, on the other hand, clearly outlines what you have to do. (1) go buy lots of art supplies (and potentially prepare a useful toolkit of prebuilt buttons, etc.). (2) construct a prototype with a CLEAR deadline, so that people focus on the whole application and not on the little things like color (that'll be dealt with in iterations) (3) test it. Rettig also gives a rather clear outline on his optimal testing strategy using four members of the design team and a user. He also shares man dos and don'ts of the process ('construct models not illustrations'). Glue sticks, cardboard stock, tape, and colored pencils, oh my! I am excited for lo-fi prototyping.

Glen Wong - Feb 20, 2008 12:05:58 pm

This article was interesting, although I've already had experience with the lo-fi prototyping paradigm. I can't honestly say I got anything new from this article for that reason. However, in my experience lo-fi prototyping is very effective. I also completely agree with the warning to not be tempted to mock-up a nicer prototype instead of a lo-fi one because when I was working on a project in which we were using the lo-fi prototyping model, I decided to make a nicer HTML/CSS one and people really did start nitpicking me on the color choices.

An earlier poster suggested that perhaps prototyping on a computer would be more effective, but my experience shows this to not be the case. I think no matter how simply we design our prototypes on a computer, the user subconsciously map this prototype to how the final product will look and react. I also completely agree with the article in that prototyping on a computer gets the developer caught up in the details instead of focusing on functionality.

Diane Ko - Feb 20, 2008 03:23:45 pm

This article brings up a lot of basic concepts that work on many levels, not just for user interface. The basic idea of planning out what will happen and getting a quick design worked out is generally like writing up pseudocode before rushing into code. Rather than have to worry about the little bugs like typos, you can focus on the bigger things such as data structures and function call ordering.

The same can be applied to designing interfaces. Before you worry about the specifics of how people are going to see your product, you want to make sure they have an idea of how they're going to interact with the product. There's less of a chance that someone is going to make a comment on how attractive a button looks if it clearly is just a replacement button that was quickly sketched for the purposes of testing. This allows users/testers to step back from the aesthetics of the design per se and focus on the functionality and overall feel of the interface. This is especially important since colors and fonts and other design aspects of that nature are relatively easy to change. However, specific interactions that the user encounters (such as how the menus work and how the mouse is going to focus, etc) are the ones that generally require much more technical work on the part of the designer and also are harder to change later on. These are the aspects that really need the criticism/comments since they're the ones that matter the most.

That's not to say, however, that people should never use hi-fi prototypes. Once all the kinks are taken out of the lo-fi version, I think a hi-fi version would be somewhat useful so that the users/testers can get a more realistic feel of how things are going to actually be like. The only problem, though, is that the more the designer gets into the hi-fi version, the more the designer might as well go from the lo-fi version to the actual version and then just get real feedback from their actual system.

Chris Myers - Feb 20, 2008 03:44:28 pm

I guess this is one of those things that you really learn by doing. It's tempting to make a quick mock-up using all the fun UI drawing tools that are around today like VB, Qt, and Dreamweaver. As fun (and easy) as those tools are to use, they quickly limit your options by providing you with general widgets. Additionally, you can waste a lot of time adjusting the size and switching look and feel - And of course if you are playing with CSS, color and position. I think mid-fi prototypes are also poor for design is that they look like a finished product - even when they are 10 min mockups. There is a tendency to treat it as such, since it looks like it's finished. I suppose a tool that combines the cleanliness of a UI builder with the flexibility of paper will greatly improve design.

I like the paper prototyping idea since it generates more ideas (and doesn't tie you to a specific windowing system or browser) and facilitates interaction between people. Unfortunately, it requires a lot coordination among team members and eats up trees like crazy.

Roseanne Wincek - Feb 20, 2008 05:34:55 pm

I really enjoyed how concise, to the point, and interesting this reading was. I thought that the author brought up a lot of great points. I love the idea of the paper prototype. The author feels that it is vital to have multiple iterations of your idea tested by actual users before you even get to the pretty, working prototype. The lo-fi paper model accomplishes this by being easy to construct, being easy to change, and focusing on the important workings of the interface instead of the less important (at this point in development) design choices of font or color. Good looking software prototypes fall short here, because they can divert the test users attention from the interface underpinnings to the aesthetics. That being said, it is still important for paper prototypes to look professional and similar to what the user would actually interact with. It can be hard for the user to think critically about how they are interacting with the interface if it is sloppy or necessary information is mission. Software prototypes take time away from the interface design and can instead focus the developer's attention on the mechanics of the program, which isn't necessary at this stage. Also, software prototypes can involve a large time commitment from the developer, who may then be reluctant to radically change something on which they spent so much time.

What I think is most useful about the paper prototypes is the ability to lay the entire interface design out physically. The author describes interviewing users with the paper prototypes while another developer takes notes on 5X8 cards. After the interview, the paper prototype is spread out, and the 5x8 cards are placed on relevant areas on top of them. I, personally, like to work with things by spreading them out and looking at the big picture. Pages or areas with a big pile of cards are obvious weak points in the design which must be improved upon at the next iteration.

Adam Singer - Feb 20, 2008 06:57:47 pm

As a much shorter reading than the last few, I'd be lying if I said I wasn't at least a little bit relieved. That being said, a lot of information came across in such a short article. I have always been a strong proponent of the benefits of showing user groups "lo-fi" prototypes, but I've never taken it as far as making a 'working' paper prototype of an application. After a very concise description of what needs to be bought and done during one of these testing sessions, I feel like I have the tools needed to conduct an effective test. I'm not exactly sure where my strengths and weaknesses will be in lo-fi prototyping, but the prospect of being a "computer" sounds interesting.

I also found it very affirming that Rettig specifically mentioned to not test directly with family members or friends. I've definitely made this mistake in the past, and usually got fairly useless data, since most of my friends and family just want to do what they think I want them to do. Testing with an impartial group of users will definitely be harder, especially with the target user group we have in our project this semester, but I suppose it will simply result in a better product in the end.

Khoa Phung - Feb 20, 2008 08:58:54 pm

I was very surprised to read about this as I thought that programmers were shifting towards rapid prototyping by using ruby on rails or other quick software generators/software packages. However, reading about this also makes me aware that I have another quick tool to use when having to prototype something really quick. I have been aware of this technique, but wasn't aware that it is actually professionally used. This reading helped to get a deeper understanding and example of how to perform such a process. I also have to agree that whenever I made a prototype on the computer, the user gets easily distracted by the look and feel and you have to keep reminding people that this is not the focus. By using paper examples, I can definitely see that the user actually focuses on just the functionality because he is aware that it is just paper.

Bo Niu - Feb 20, 2008 10:04:31 pm

In Prototyping for Tiny Fingers, Rettig's idea of having the paper/human pretend to be computer prototype was something we have seen in lecture, and it certainly is one of the best ways to start a prototype at early stage. However i found that the tips that he provided in the reading wasn't that useful. Most of them are just minor detailed and the useful ones are just intuitive ways to present the program interface on paper.

We have thought about this on paper prototyping in class too, and we have discussed that a problem with this design is that it's hard to train human behave strictly as computer, but there wasn't any answers regarding this problem in the reading.

Gordon Mei - Feb 20, 2008 11:07:01 pm

The Rettig article outlines one of the common traps I see with those who are prototyping. By resorting too quickly on high-tech prototyping, more valuable resources are shifted to the mechanics, rather than the design concepts. This rubs against the 95% design/5% mechanics ratio generally spent by designers, as the reading established. Or as some of the variations in sayings go, design is 95% inspiration, 5% perspiration. While people may be tempted to produce a working coded prototype instead of a simple mockup image, they'll end up resistant to changes further along the way so as to not toss away days or weeks of debugging and labor. Probably one of the less common prototyping methods I've seen is the technique of taking the low-fi drawn prototype one more level by having movable cut-outs with which the user can interact. And upon closer inspection, this seems to be an even more powerful method than a high-tech coded demo, as the users can assume part of the role of the developer, and rearrange and redraw any aspect of the UI elements, and Retigg's role-based user tests (computer, observer, facilitator, greeter) illustrate this advantage. Ultimately, to me, this offers the highest level of feedback from the users, which may counter current perceptions of the benefits of low-fi prototyping.

Michael So - Feb 20, 2008 11:22:58 pm

Lo-fi prototyping sounds like a good technique to use in refining a design. Because lo-fi prototyping is so quick and easy to do, you can get feedback from your users easily and be able to iterate and refine your design more times than hi-fi prototyping in the same amount of time. Like the article points out, Lo-fi prototyping works because it "maximize the number of times you get to refine your design before you must commit to code." Maximizing the number of refinements to your user interface sounds obviously as a good thing. You want to make sure your final product does well.

The cons of hi-fi prototyping make sense too. It's a time consuming process and people would spend time on unnecessary aesthetics. And I agree if one spends weeks on the prototype, they would tend to not want to make significant changes to the design despite the testing done. But I think a good thing about hi-fi prototyping is that you can see how it the product would actually look and feel and it would be proof that your product can be implemented.

JessicaFitzgerald - Feb 20, 2008 11:25:06 pm

I liked how this reading was very straightforward and to the point about describing the techniques of creating low fidelity interfaces. It makes a lot of sense that this technique should be an integral part of the design process, because it makes designing the general idea of the product take four hours instead of a week or so. This gives the designers more time to carryout the execution of the interface. I found it important that the idea of low fidelity allows the interface to be redesigned several times without loosing a significant amount of time. I could imagine this would help build a more usable and efficient interface. I could also see how it might be hard to visualize paper mock-ups as an actual interface, and that could hinder the development process, but all in all it seems like a useful tool in development and planning.

Benjamin Sussman - Feb 21, 2008 12:58:33 am

I can't help but relate to the statement made near the end of Rettig's (extremely well written and engaging) article: "people consistently enter the first lo-fi exercise with skepticism". I am very skeptical of my ability to maintain a serious demeanor and keep up the "computer" charade for an extended period of time without breaking down into giggles or rolling my eyes with boredom at how un-helpful the session has become. Despite this skepticism, reading Rettig's article completely sold me on at least thoroughly attempting a lo-fi prototyping session and the respective user inquiry with that prototype. Another point that hit me personally as being true was: "it also helps to have someone who can enthusiastically champion the idea". I cannot stress how important this idea of enthusiastic effort to allow something as silly seeming as cardboard cutouts and wizard of oz antics be passed off as real work, however if it honestly helps designers iterate more often while providing them with valid and informative feedback then there simply is no substitute. I hope that my lo-fi prototypes don't suck, and that I am perceptive and patient enough to learn as much as Rettig does in his tests.

David Jacobs - Feb 21, 2008 12:31:00 am

I must admit that I've fallen victim to nearly all of the traps that high fidelity prototypes lay for developers. The "fit and finish" and "developers resist changes" comments strike particularly close to home for me. For each of last few assignments, I've spent upwards of a couple hours polishing the look and feel of our proposed interface more or less just because I've got the Illustrator skills to so. I'd like to pretend that I fall in the category of prototypes described on page 25 (still lo-fi, but with a slightly more polished style), but I know that deep down I'm trying to perfect the details, and not so much the broad strokes. But as they say in most 12-step programs, the first step is admitting you have a problem. I actually really enjoyed this article, and kind of look forward to trying out the paper model technique. I like arts and crafts. :).

Andry Jong - Feb 21, 2008 01:45:26 am

I really agree when Rettig said that "reviewers and testers tend to comment on 'fit and finish' issues" or appearance matters rather than content issues when they are reviewing or testing a finished software interface. This is one of the things that really made me agree in lo-fi prototyping, since lo-fi prototyping really make the tester focus more on the content of the software knowing that the aesthetic part of the design hasn't been thought of anyways.

It is also interesting how setting a deadline would help developers to get their thought down to design. It's always true - at least for me - that the hardest thing to do in designing or building software is to even start on it. But when we're faced with deadline, I guess we don't have other choice rather than to start working on it fast; since it doesn't matter if it works perfectly during the first iteration of designing.

Randy Pang - Feb 21, 2008 01:57:14 am

Overall I found the reading to be a refreshingly concise guide to lo-fi prototypes. While I do agree with Rettig overall, I do wish that he would have spent a little more time addressing the issue of "when/why do we go from lo-fi to hi-fi" instead of pouring on the "lo-fi is great! it's cheap, it's fast, and everybody loves it! long live lo-fi!" I think that most of us already understood that developing a very expensive thing to do, and that spending a little time getting your design down correctly will end up saving you far more time in the long run. As it has been pointed out before, increasingly agile ways to prototype even 'hi-fi' systems are becoming available, like Ruby on Rails (there is actually a deritive of Rails called Hobo that streamlines the process even further), Drupal, etc. Although quick sketches and other lo-fi systems (what is photoshop considered? still lo-fi?) will always be quicker, they will eventually lose their efficiency and effectiveness and at some point you do need to go actually get hacking on some code, so I think the important questions that need answering are simply, when and why? (Of course, in CS162 the answer is always 'after the design doc review')

Brandon Lewis - Feb 21, 2008 02:22:22 am

I can't wait to try this, though it looks like a lot of work. I'm thinking i should go to the store and pick up some supplies tomorrow, so our group can get a jump-start on this. Then, perhaps, I'll start making paper mock-ups of some other projects I have been working as a sort of practice run. Or, maybe not. Either way I'm interested to see what we get out of this exercise. I have done a lot of UI programming, but very little UI designing. I've definitely produced (or at least, abetted) some crappy designs. I've also let implementation concerns get in the way of my designs goals. But i've never really designed applications for people other than myself, and a few close friends.

Edward Chen - Feb 21, 2008 02:54:40 am

At the end of the reading, the author puts a note of how that most people enter into doing lo-fi prototyping with a bit of skepticism. I find that highly true in my case as I consider how I am going to the lo-fi prototype and how exactly am I going to construct. Having to manually parts and construct buttons on a giant piece of paper seems rather tedious, which partially contributes to the skepticism. However, at the same time, I'm intrigued because unlike hi-fi prototype, you can rapidly change the low-fi prototype, moving around the locations of buttons and other layouts easily without much effort. At the same time, I wonder how the tester will react to the low-fi prototype, since they've most likely has never tested a user interface just on pieces of paper and having a person assigned as the "computer" to move them around accordingly. I hope to find lo-fi prototyping to be an interesting experience.

Ilya Landa - Feb 21, 2008 04:46:22 am

A useful reading, in itself; however, I didn’t find anything new for me. The theory of low fidelity prototyping has been already discussed in this and other CS classes (complete with a person pretending to be a computer). Naturally, low fidelity prototyping is a great tool in defining the design of the project. Stephen King, in his most blood chilling book On Writing wrote: “Kill Your Darlings” – do not hesitate to throw away what you made, and create something new. And this is much less painful to do with paper drawings rather than with working prototypes. Eventually, however, the development has to go outside the paper drawings and into an actual computer program. Hand sketches are handy while trying to decide what the project should look like, but actual abilities of languages, tools, and programmers have to be kept in perspective so that the design won’t get unfeasible. Plus, programmers and clients need to see their project on an actual computer monition before they can finalize the design. One minus though (of the paper prototype, not the reading) - David Jacobs (look above) was excited about it because “[he] like[s] arts and crafts”. I envy him – my hand drawings are way worse than something I can sketch on a computer.

Scott Crawford - Feb 21, 2008 06:03:14 am

I particularly liked the suggestion of setting a deadline. With the frequent talk about thinking outside of the box, it's easy to let yourself be overburdened with too many thoughts, because once you open your mind to it, there really is infinite material out there. However, nothing would ever get done without deadlines, so setting them is a great way to remind the team that thinking wild doesn't mean thinking indefinitely. Moreover, by forcing something to get done (even if it's not ideal), you create something which can be improved upon. Obsessively thinking about various things without making anything will under normal circumstances be less efficient since after creating and evaluating something lo-fi, it's easier to focus on single things to improve upon instead of trying to tackle it all at once.

Harendra Guturu - Feb 21, 2008 08:18:41 am

I agree that lo-fi prototypes can be a great asset during interface design. The examples suggested in the paper regarding the lack of flexibility or too much irrelevant detail being criticized with a hi-fi prototype results in a good user inquiry. Furthermore, due to the time invested coding as well as the attachment associated with developing and testing the prototype will cause commitment to the prototype and result in critical suggestions from the user to be ignored.

Another way why I think hi-fi prototyping can hurt is not on the interface end but the actual back end. The code developed for the hi-fi prototype may have taken enough time that the developers are resistant to throwing it away once the prototyping is complete and they are ready to create the actual production quality software. This results in badly engineered software both on the front-end due to improper user inquiry and badly coded software in the back end due to the lack of a good design process and the hodgepodge of the prototype code with the final production code.

Alex Choy - Feb 21, 2008 11:01:07 am

This article talks about the process of lo-fi prototyping. It gives a good and brief introduction to a new design technique and goes through each step. At the "conducting a test" stage, testers may influence the user and not be aware of an innate bias. The presence of a testing environment will affect how the user thinks and feels. In addition, the fact that a paper simulation is being done will not be as realistic as a computer simulation. Of course, this is why it is a lo-fi prototype. That being said, I agreed with the points that Rettig brought up regarding the problems with hi-fi prototypes. I believe that a designer should have a good idea of what the customer wants and build off of that instead of building off what the team thinks that users will want (or what they want from limited testing). This way, the designer does not begin writing code until he/she has a good idea of what the final product will look like.

Ravi Dharawat - Feb 21, 2008 10:36:53 am

This article was informative. I do agree that lofi prototypes are fast, eliminate many of the problems found with hifi prototypes, and, let's face it, are just fun to do. However, I wonder if lofi prototypes may give the developers too much leeway. There are times when coding up prototypes reveals impracticalities in features and the such, at least in my own experience, but perhaps that is just my own lack of skill or experience talking. The article also got me thinking about rapid-prototyping software. Maybe a sort of WYSWYG type of deal, something to take away the awkwardness of moving around pieces of paper and simulating a machine.

Brian Trong Tran - Feb 21, 2008 11:35:22 am

My research group actually uses lo-fi prototyping! We pulled out the paper and drew brief sketches. We later moved onto printing it using Paint. It was really great for showing people what we were trying to do and how we expected things to function. We almost tried making our initial prototypes in HTML, but doing it on paper saved so much time and effort. This stuff actually works. It was great for not only conceptualizing, but also for making changes throughout the design process without being worried about starting over.

Cole Lodge - Feb 21, 2008 11:45:51 am

Up until very recently the company where I work used lo-fidelity prototyping; It was not uncommon to have several people coming to meetings with full interface mock-ups drawn up. Whenever a new product was going to be released or new feature implemented the first thing we were always told to do was, "Draw it up." It was very quick and dirty, leading to several problems. Difficulty reading each others handwriting and the ability to slightly change an interface often got in the way. Since then, we are heavily discouraged from drawing up an interface and know rely mainly on viso to prototype, Since viso was already being used to write up uml documents, this posed no extra cost. Now, the interface design process has become faster and offers far more iterations; the majority of the company are much faster drawing an interface in viso than on paper. Although in the past lo-fi prototyping was by far the best way to go, the increased availability of prototyping tools allows for a far more seamless interface creation.

Daniel Gallagher - Feb 21, 2008 12:00:46 pm

Rettig's article was definitely not the first time I've heard of lo-fi paper prototyping, but this time I did not dismiss it out of hand. I think it's easier to accept that really useful data could be obtained at an early stage in a project with lo-fi after we've already experienced interviewing people in a more limited sense. Before cs160 I would have pointed to "pretty" prototype options, like dhtml, as being perfect for prototyping because it would LOOK most like the final result. In my own work I've seen how easy it is to be bogged down with the details of color + positioning and with a larger project and group I believe Rettig that things could only get more inefficient at that stage. I'm very curious to see the dynamics of a user actually suspending disbelief well enough (or not) to give concrete user data on a paper prototype. It seems like the factors that would play most heavily into getting good data are the skill of the guy playing computer and the quality of the lo-fi prototype itself. The 'computer' job seems the hardest because you not only have to worry about doing a poor job finding pieces and making the user impatient, you also have to avoid giving any additional information or perhaps even existing properly to the user for the duration of the test.

William tseng - Feb 21, 2008 12:19:31 pm

The key things I took from this description of Low-Fi prototyping is that it requires the whole team to be there throughout the process, and the importance of preparing "scenarios" or "tasks" for the user beforehand. The group aspect is necessary because you simply can't pretend to be the CPU, ask questions, and jot down notes all at the same time. It is also important that everybody views the subjects response and forms their own idea of what worked and didn't work with the user. This is more useful than just one person doing an interview and presenting its results. The scenarios are important because it gives the user a goal to try to achieve with your interface. I am hesitant however because if you have too many scenarios it might prevent the user from just exploring and suggesting new ideas for your application or interface.

Andrew Wan - Feb 21, 2008 12:00:52 pm

The reading provided concise, useful guidelines for conducting interviews with a lo-fi prototype. It's clear how useful simple paper mockups can be, especially considering the costs of developing fully-functional software. Given the typical programmer's education and attitude, it may seem easier to just begin implementing some thought-out design (as is the case in most software projects). Unless said software is extremely well put together, making incremental changes on the hi-fi prototype inevitably takes more time and effort than with paper models. That said, I'm not entirely sure that the lo-fi approach is ideal in every case. Depending on the complexity of the proposed interface, the size of the development team, the organizational goals, and the availability of interviewees, a good amount of time may be wasted in the brainstorm/interview stage. A company may find more utility in developing modules for a project in parallel, with a few designers working on a simple prototype frontend and the rest on necessary "backend" software.

Lita Cho - Feb 21, 2008 12:27:00 pm

I thoroughly enjoyed this reading and really want to apply the lo-fi techniques to our interface. The best thing about lo-fi is the that the design can quickly be tested on the user. The biggest problem while designing our interface was agreeing on what would be easy to use for the user. We wanted our design to be intuitive and a lot of members have conflicting ideas. With lo-fi, we could just implement all the member's ideas and test it with various users to get feedback. I think with user input being a part in the early development stages, good designs can go to production consistently.

The testing also seems like the developers are putting on a show or an interactive movie for the user. The facilitator being the narrator, and the "computer" being the main character. The team also needs to go through dry runs (or dress rehearsals) in order to perform properly. If the user doesn't like the show, you have the power to change it to make it a blockbuster hit. I know that is random, but I thought it was a good analogy. =P

I always thought that you had to have a design programmed and ready for the user to use. I relate with the the fact that "Developers resist change" when creating hi-fi prototype. After working on a project for weeks, I would personally find it very hard to make a drastic change. I think that is why a lot of bad design is out in the world today.

Henry Su - Feb 21, 2008 12:49:25 pm

I think Rettig makes a good point that low fidelity prototyping makes it much easier to revise designs over and over. Just as important is that, because of its relatively quick nature, the designers would be much more willing to make design revisions. After all, you don't have to worry about breaking code and re-debugging. However, I have some personal doubts about the speed of low-fidelity prototyping. In particular, although I agree it's easier to make changes and "debug", I don't think it will be that much faster to create the first draft, especially with all the supplies required; my limited experience with 3D arts tends to suggest that these "low-fidelity" projects still take much longer than you'd think. Then there is the problem of the startup cost; one must spend some time and money to get all the materials needed. Of course, this cost is relatively manageable when compared to the money paid to programmers per hour in a typical company. I also find it interesting that the interviewing technique explained in this article is quite similar to the techniques used in contextual interviews. In particular, we shouldn't "teach" the users what is right and what is wrong; it's the interface's, not the user's, test. All in all, low-fidelity prototyping seems like something which is tough to begin with (but then again so is a high-fidelity prototype), but relatively easy to modify as the design goes on.

Kai Man Jim - Feb 21, 2008 12:45:09 pm

This is another good article after the note board sketches. The note board sketch is like the movie sketch and this one is more like the design of the interface. It has to be detail in every single part. Moreover, I agree with the way it says we should do all the lo-fi work first instead of the hi-fi. If we do hi-fi first, then we will have a hard time to re-program all the code if there is a change that is necessary. Lo-fi will help us to smooth things out and do the coding part at the end. And taking notes with observation is pretty much what we have been talking about in the class so far. So, I think this could be our next homework assignment since it is a fun activity.

Reid Hironaga - Feb 21, 2008 12:53:10 pm

Rettig has a strong enthusiasm for the use of low fidelity prototypes that he tries to instill in the reader. However, I feel that he intentionally skips certain details that would reduce the glory of low-fi prototypes. He claims that "You can't evaluate an interaction design until after it is built, but after building, changes to the design are difficult." I think he is assuming a poorly built design that is overly complicated with acute details and produced in a static fashion. Playing computer is definitely a good way to interact with customers and foresee the reactions they will have to certain design choices. However, I imagine that it would take a lot of energy and money to obtain sufficient testers to obtain useful information that would not be available without the imagination of the designer. The readings also suggest having a specialized greeter to introduce potential users to the experience. However, in the real world environment they may be stressed by workload or their surroundings when using the system. Having a greeter to put them at ease and try to calm them would improve their ability to see and solve problems, unlike the normal stressed setting of many users.

Mike Ross - Feb 21, 2008 12:52:16 pm

Lo Fi prototypes sounds like a great idea, basically the same idea as making an outline for an essay or drawing thumbnail sketches. I completely agree with the point that designers often get caught up on the aesthetic details when building prototypes, and that starting with quick tools you're literally going to toss out (or file away) should help prevent that.

My favorite point is that you need to set a deadline to finish and get feedback ASAP. Way too many times I've worked on things where my team or I get caught up on tiny corner cases that never see the light of day, while we could have been hammering away on the more important pieces.

Hannah Hu - Feb 21, 2008 01:09:01 pm

I noticed comments about the suggested use of "mid-fi" prototyping, involving the use of graphical programs such as Illustrator to draw up the interface. That seems to defeat the purpose of quick prototyping; it takes time to draw up an image, print it out, and get it ready for user sessions. Moreover, one would automatically assume the mindset of "perfecting" the appearance of the interface as soon as the graphical program loads. The tools at hand tempts the designer to add a litle color here, draw a perfect square there, until those little things turn into a trial of artistry, which would result in inflexible design. Thus, "mid-fi" prototyping is actually more like "mid-high-fi".

On that note, a "mid-low-fi" prototype would probably work better than "lo-fi" if you factor in sloppy handwriting and the inability to draw a rectangle. How to define that level, however, I cannot say yet.

Yunfei Zong - Feb 21, 2008 01:25:46 pm

Why is it that text quality and the length of the article are always proportional? Whoever picks the readings must wish to do harm to the reader in some form! Besides that minor detail, this was possibly the most useful article I've read so far. In both my 160 and 169 groups, there is the paradox of having no visual model because the features haven't been hammered out [because there is no visual model on which to build them on]. This paper prototyping scheme seems to solve all problems; we have been doing sketches to give a rough visual model, but we had to constantly redraw stuff that we felt like needed to be changed, and redrawing the entire model when we moved a button around. With the paper model, all we have to do is shuffle things around. Also, one of the members of my group has no sense of scale, so all our diagrams looked different [and by different, I mean TERRIBLE]. We can easily solve this by building a cardboard frame which is to scale with the Android screen. Also, since he has no ability to draw squares, we can use post-it notes to represent buttons; since they can be removed and attached easily, they are the perfect choice because our buttons will do different things depending on the context.

Max Preston - Feb 21, 2008 01:21:34 pm

I thought this was a good article. It seems to me that lo-fi prototyping would be the most effective way to figure out how you want your interface to function when you're at a very early stage in the development process.

However, I think this type of prototyping would only be useful for certain types of projects. Sometimes, it's more important to make a design that people are already familiar with, such as when making a sequel or upgrade to an existing product. In this case, you wouldn't want to deviate too much from the previous design. Also, since you would already have a working example of the previous interface, you could have users test the previously implemented interface instead of putting it together with art supplies.

Maxwell Pretzlav - Feb 21, 2008 01:34:16 pm

I really like the suggestions in this article, but it definitely poses some significant challenges as far as implementing a prototype. One of the points the article made was having a model ready for nearly any action a user makes. This will be challenging for my group which is working on integrating google maps into a specific context -- it's impossible to have drawings of anywhere a user could scroll a map. I guess our lo-fi prototype will just have to have borders on the world and we'll have to tell the user they can only drag the map so far (as far as the sheet of paper goes . . .).

Jeffrey Wang - Feb 21, 2008 02:07:46 pm

The article begins by explaining the proponents of using Low-Fidelity Prototyping over Hi-Fidelity Prototyping. It lists mainly the cons of Hi-Fi and then goes on to give the guidelines on how to do Lo-Fi. The article mainly argues that it's useful from a user point of view. While I mainly agree, I also would like to add that it's very beneficial to the designer himself. Drawing out detailed designs allows them to be creative and without being restricted the limitations of the computer yet. In addition, it builds a good foundation that can be readily programmed later. I have found that programs with paper designs beforehand usually turn out to have better. Moreover, the time fixing bugs are greatly reduced.

Jeff Bowman - Feb 21, 2008 02:14:21 pm

I can definitely say I've experienced the sentiment that the prototype is "too hi-fi". Just a week ago, I did a mockup of a website design in Photoshop, and half the concerns in the design review were addressed with "I haven't focused on that yet" or "that's an artifact of the prototype." With interface designs, it gets only worse: If the prototype bears any resemblance to the real thing, users are going to expect the real thing to look just like it.

In short, he makes a compelling argument for paper prototyping, even to the point of reluctant agreement. I do admit to having felt annoyed when a feature from a brilliantly-executed hi-fi prototype gets dropped, or how I have to explain with resignation "it's not implemented properly yet, I jury rigged it."

It is with this good argument that I look forward to the prototyping exercise we'll be doing in the coming couple of weeks.

Zhihui Zhang - Feb 21, 2008 02:32:20 pm

I do quite a bit of UI design at work and I've only recently started prototyping my designs on paper rather than going straight to code. My though process before was that too much time was wasted by drawing things on paper first or other types of lo-fi protyping However, I can speak from experience now that although it might seem lo-fi prototyping takes more time, in actuality it trims a considerable amount of time from the development process in terms of work that you have to redo.

Jonathan Wu Liu - Feb 21, 2008 02:39:13 pm

Hmm, good point Jeffrey Wang. I've often found that starting out with a lo-fi solution typically has yielded a more comprehensive and bug-free solution as well. I'd like to add further that sometimes to have a more accurate view of the program, it may be more helpful to work with programs like Photoshop at the outset, because some programs require more exact dimensions to work, and to prototype interfaces in Photoshop may give a more accurate sketch of what we want. Also, for those of us who find it hard to draw or are not that colorful but know how to make it look good in Photoshop, using a computer program to do some lo-fi prototyping may be the best way to go.

Jeremy Syn - Feb 21, 2008 02:54:25 pm

I was wondering why, even though low-fidelity prototyping has been around for a long time, many organizations do not make use of it. From the way Rettig talks about lo-fi prototyping, it is an essential part to the design of a user interface. Not only is it cheap and easy to make, it is fast and susceptible to quick drastic changes to the system. It is a good thing that lately more organzinations are utilizing lo-fi prototyping but it puzzles me why it hasn't before, even though it's not a new idea. Clearly though, this step to designing is an essential one before the actual implementation should be done and I think we will also be making use of this type of prototyping in this class as well.

Timothy Edgar - Feb 21, 2008 02:29:36 pm

The article reminded me a lot of the summer, except perhaps with a bit more wisdom. In the summer, I designed a new app for a project for my internship at Microsoft. I spent a few hours in the morning sketching something after brainstorming during lunch. It took a very short time to sketch it, which I got feedback really fast from it. However, the comment about sketches not being always acceptable is true in the sense, more presentable screenshots were desired. As we kept increasing the effort in making it convey more, it became harder to change. We started with sketches, then went to screenshots and then html mockups so provide minor interaction. The strange thing though is when we tested, we used a simple web prototype to test it to allow users to interact, rather than sitting through with a lo-fi test. Considering we still had a lot of questions after the test, perhaps a lo-fi earlier on would have gave us more insight before we moved onto a code prototype. The strange thing was the believe that code speaks more than anything else and the push for code. I think the lo-fi methods of sketching and playing computer might allow people to be more willing to offer criticism. I found when it was in code, people would say that's it's working and it's fine. This resonates how coding early is a bit counterproductive in design.

Zhou Li - Feb 21, 2008 02:42:32 pm

After the reading, I really want to put the effectness of lo-fi prototyping to test for our Android application. For the software project we built last semester, we bascially used Visio to draw out our initial interface design with realistic looking scroll bars, button and drop down lists. But just like described by Retting, we felt reluctant to change any major structure of the design and ended up with a finished product that was very similar to our original prototype in terms of interface design. Also the more hi-fi prototype tended to draw people's attention and advice on interface details instead of more important content of it.

I think with enough practice and the right testing user group, lo-fi protoyping is a great way to iterate more times through the intial interface designing process. Therefore, allowing designers to have a more ploished and tested prototype before the actual implementation of the software. Since the prototype would already be tested for serveral times by the target user group, desginers won't need to worry about any major changes in later development stages.

Jiahan Jiang - Feb 21, 2008 02:56:34 pm

I enjoyed this reading a lot(especially since it's short and not very involved). I have heard of lo-fi before, but this article definitely convinced me on its values. I really appreciated the discussion on why it is important to not make it "sophisticated" so that users don't focus too much on the appearance of things and get distracted from the important design issues. I think that never occurred to me; I was always focused on making the interface "look" perfect but didn't focus as much on its concrete functionalities; it's definitely something that's good to know/notice.

Pavel Borokhov - Feb 21, 2008 02:36:23 pm

I thought the reading presented a good overview of why low-fi prototyping is worthwhile and how to carry it out. However, I feel like a lot of the work described in the reading, such as making scrollable areas by cutting slots in the heavy paper and having a longer sheet of paper under it that can be pulled to simulate scrolling, almost enters the realm of a "hi-fi" lo-fi prototype. Creating such things is not trivial, and trying to think of all the potential actions a user could take, and then implementing them in a lo-fi fashion, does not seem like a very insignificant task, especially in terms of time. In the scrolling case, for example, it would seem much easier to simply have three "screens" for scrolling positions - initial, scroll up, and scroll down - to simply give the user a taste of what the scrolling will entail (the "computer" can then simply change the screen when the user attempts to scroll in either direction). Similarly, I have some concerns about the speed with which some of the materials can be produced. While doing the sketches for the interface design section of the last assignment, I ran into issues with being able to fit enough text into my drawings to fully represent the interface, which had a significant textual component. When drawing quickly by hand, I would end up drawing a screen that was too small to fit all the text and consequently ended up either having to redraw the screen entirely to redraw the text, or try to cram the remainder of the text into whatever space was still left. Doing an activity of this sort in a layout program is much easier, since you can quickly resize the dimensions of the screen and change the font size and have everything automatically reflow. At the same time, creating quick icons on the computer can be difficult because they might not be available as a glyph and drawing them with a mouse is too hard. Consequently, I feel like from the reading and personal experience, a hybrid system of basic general sketches followed by more detailed computer-generated drawings, potentially supplemented with the use of a drawing tablet attached to the computer, would result in the most efficient use of prototyping time in the development of a usable and intuitive user interface.

Robert Glickman - Feb 21, 2008 03:11:49 pm

This reading was particularly interesting to me. Beginning with the issues with hi-fi prototypes, I began to realize how advantageous it is to draw up such a simple lo-fi prototype. All the time, effort, and illusory aspects of hi-fi prototypes makes them often too cumbersome (although such "flashiness" may be important when seeking potential customers). Also, as I was reading, I found myself asking questions that were answered immediately by the text. "But how do you design such a lo-fi prototype?" Answered immediately. "Ok, so how do you set up the test?" and "How do you pick the users?" These were also answered immediately. Overall a very short read which left me more comfortable with this design phase. In particular, there was one tidbit about trying to solve all your problems at once, and ending up just staring at a blank page with all kinds of issues racing through your head. I find I run into this type of work-halting cycle all too often and it often leads frustratingly to procrastination.

Joe Cancilla - Feb 21, 2008 03:16:05 pm

Low fidelity programming seems like the way to go. I agreed with many critiques of high fidelity programming. One thing I am skeptical on is the speed at which a low fidelity program could be created. All of this cutting out of paper seems like it would take quite a while.

I think that this will be a fun project to implement on our ideas and I look forward to finding out what people think about our project.

Siyu Song - Feb 21, 2008 03:18:52 pm

There were a couple of really interesting things in this article. The first thing that stood out to me was the tips for designing lo-fi demos that they authors gave: "Know your user" and "You aren't the user". It stood out to me because I think a lot of the time when designing applications we are tempted to create it around how we would use it but I think that the way they put it was very direct and clear that designing as if you are the user does not benefit the actual users. The article also made making lo-fi prototypes seem like a lot of fun. The other interesting bit was that you don't necessarily have to test your prototypes on the end user. That was different from what I thought was obvious so it was good information that I would not have thought of on my own.

Raymond Planthold - Feb 21, 2008 03:05:53 pm

I feel like Rettig makes a very good case for lo-fi prototyping. The description of testing the prototype with users is quite thorough considering its length. I wish it had spent more time on designing the prototype, however, as it seems the trickiest part to get right. I'm the type of person who has trouble making an outline of an essay before writing an essay. Similarly, when thinking about the design of a program, it's hard for me to avoid straying into the implementation. It would be nice to have a better sense of what parts of a program are important to have in the prototype, and what's better left to the coding.

Daniel Markovich - Feb 21, 2008 03:22:19 pm

I definitely agree with the articles view about the advantages of Low-Fi prototyping. Probably the single most important influence in designing an interface/product is user feedback, and Low-Fi prototyping is very efficient for this task. It takes only a portion of the time that Hi-Fi prototyping does to give the subject an interface that they can interact with and critique. One of the other advantages that I believe low-fi prototyping has over hi-fi is that the designers can easily "scrap" some of their ideas and formulate new ones, whereas with hi-fi prototyping this would take significantly longer.

Paul Mans - Feb 21, 2008 03:20:49 pm

I don't really have much to say about this reading other than I agree completely. The benefits of Low-Fi Prototyping that the author described are completely aligned or have been echoed by almost every "Design Cycle" reading we have studied thus far. Again and again I leave these readings with one point impressed most upon me: that is that prototyping early and in a fast-iteration style will result in designers being less attached to any given design and more likely to change it in the face of glaring deficiencies discovered after user testing. Maybe the reason that this point continues to strike home repeatedly for me is that I have long struggled to fight perfectionist impulses in myself that push me to design in isolation until I feel like I can show someone my work without embarrassment.

I would have liked more details in the article about the number of other ways that transparency paper can be used for low-fi prototypes except as handles for small menus and such. I guess though I could pursue writing by the expert the author mentioned in this category I have forgotten his name.

Although this article described techniques that seemed quite intuitive in practice, I still appreciated them spelled out for me. Details such as how to structure a test interview like having a 3 person testing team and resisting the impulse to guide the user when they go wrong are definitely helpful.

Tam La - Feb 21, 2008 04:41:19 pm

Th article does a very good job at presenting the advantages of using lo-fi prototyping. And I think lo-fi prototyping is a very essential part of interface design that prevents the designing team from wasting time on coding interface features that might not be desired by the users. From the little interface face designing process we had for group project, I can easily see how first round interface designs are bound to have many flaws that are invisible to the designers because they are so caught up in the functional features of design. Also, since they know the everything there is to the design, they usually are able to skip mentally the flaws in logics of the operational flow; while a user new to this interface and its functionalities must perform tasks step by step based on what the interface provides, thus more likely to detect any missing link or error.

I think using screen shots of windows interfaces in producing windows based prototypes is beneficial because then you will be able to see whether the conventional icons are sufficient for regular windows users navigate through the new interface efficiently.

William tseng - Feb 26, 2008 01:21:01 pm



[add comment]
Personal tools