Lo-Fidelity Prototyping

From CS1635 Spring 2014
Jump to: navigation, search

Contents

Slides

slides

Readings

Reading Critiques

xiaoxuan Chen 17:07:07 1/28/2014

The article began by comparing two different methodology to design a user interface with the better one being: in the early period of development, they created a paper prototype that contains all ideas and test with typical representatives of the user community with one member being the 'computer' and other members observe and take notes, afterward, they learn from their observation and redesigned and retest until their final time is close. This techniques is called low-fidelity prototyping (aka lo-fi). Hi-fi is everything from demo-builders to multimedia tools to high-level languages to build prototypes. Some problems with it are: 1) take too long to build and change, reviewers and testers tend to comment on 'fit and finish' issues, developers resist changes, a prototype in software can set expectation that will be hard to change, and a single bug in a hi-fi prototype can bring a test to a complete halt. By describing lo-fi as "Trojan meme", we see how fast it spread a general appreciation of the value of usability design. The two important lows are: Know your user, and You aren't you user. Lo-fi prototyping works because it effectively educates developers to have a concern for usability and formative evaluation as well as maximizes the number of time we refine out design before final commit. The process of building a lo-fi prototype is: 1) Assemble a kit, 2) set a deadline, 3)construct models, not illustrations. After building we can prepare out tests: 1) select your users, 2) prepare test scenarios, 3) practice. When all is done, we can conduct a test and give different roles to our group. Four essential roles are: greeter, facilitator, computer, and observers. Each plays a very important role in terms of making the user behave normally as well as recording the feedback. After all, we can evaluate the results and make changes to our design. This is a really detailed article on how to make a lo-fi prototype, with very detailed description on each steps. From it I learned the advantages of lo-fi prototyping in comparison to hi-fi prototyping, and got a clear idea of why to use lo-fi and how to use it effectively.

Steven Bauer 20:45:29 1/28/2014

Today's reading is prototyping for tiny fingers, the first topic is using low fidelity prototyping. This is when you make your interface on paper and watch customers use the fake "app". After this is done they take the comments of the customer into account and adjust their application, this changes several times before the interface is complete. This is in contract to high fi prototyping which is using high level programming languages or other advanced tools to create the prototype. The problem with this approach is that it is expensive in time to create each prototype. It can offer features such as feel that one can't get from low fi but you can achieve many of the same design revelations from using the low fi first and save a lot of time doing it. Low fi also saves you from getting too attached to your current design, after a high fi prototype is created a developer might be reluctant to take customer feedback and completely redesign everything. They suggest that when you are testing your interface that you can get more input by "buying" customers time. The low fi prototype should be made of cheap materials and also be made on a deadline. Choosing the right users and having test senarios for them to use are very important. It is also crucial for you to either record the testing using either diligent notes or a video camera. Once all of your data is collected it is important to carefully review the data, after all, you took all the time to create these prototypes and now it is important to make sure you take advantage of every comment made by your users.

Sara Provost (stp28) 23:43:55 1/28/2014

From this reading I learned about the two different types of design prototypes that are commonly used. The lo-fi prototype is the paper and ink prototype. Despite its simple nature, for many groups this type of prototype is a good option because it allows for the demonstration of the behavior of an interface early in development, allows for testing with real users, and if used early enough in the design process can greatly increase quality. Lo-fi prototypes also allow users and developers to more easily focus on the design itself and not small elements such as font choice and colors. The hand-made appearance of the lo-fi prototype forces users to think about content rather than appearance. Additionally, they can be created and modified quickly. The other type of prototype that exists is the hi-fi prototype, which is created using demo-builders, multimedia tools, and high-level languages. Despite their more solid appearance, hi-fi prototypes have issues that could make them an inappropriate choice for some teams. They can require much time to create and modify, once created developers might be unwilling to change the prototype too much, a software prototype can create expectations that are difficult to change, and any bugs in the prototype can bring a test to a halt. The article also goes into detail about the proper way to create a lo-fi prototype. According to the article, in order to build an effective lo-fi prototype a person needs white paper, 5’’ x 8’’ cards, glue, markers, sticky notes, scissors, and acetate sheets. When building the lo-fi model it is important as well to set a deadline and to be sure that a model and not an illustration is being created. Finally, when conducting the test with the lo-fi model, it is important to have an understanding of who the target audience is and who will be using the software, to prepare test scenarios that describe the product in a typical work situation, and to practice so that all errors with the model are caught before users interact with the prototype. During this test every group member should play a role, and from this test useful information should be gathered to be analyzed.

Guoyang Huang (Guh6) 11:11:58 1/29/2014

In this reading, I learned that low-fidelity prototyping or lo-fi is building prototypes on paper and testing them with real users. Even with the paper technique, one can achieve quality in early development because it’s fast and brings results early. Hi-fi is the opposite of using tools to create a highly visualize example and takes a longer time to build. I’ve also learned that the more time spent on an interface, the less more attached the designer will get and unlikely to change for hi-fi. The way lo-fi works is because it make the developers have concern with usability and revise their iterations based on them. The first stage is get all the materials you need to assemble paper together, cut them, and make design with them. Second point is the set a deadline to always have something there so that the users can see and make refinements based on that. Third stage is similar to our programming uses of modular which is make models so one can move them around so they’re not fixed and immutable. The second stage is to prepare for your design to be tested. The first point is to use task analysis that we went over in class to select our user base. One new idea I learned is surrogate users, those who are not the clients and free from whatever association to prevent testing. The Second point is to prepare a test scenario that is to do a walkthrough of the design for actual uses. The third point is to run the design in-house with the design team before sending it out for outside testing. The actual test takes four types of people: greeter, facilitator, computer, and observer and the roles should be rotated among the team with session lasting a little over an hour. The most important part of the process is to write the information down so that it can be used later on, otherwise the hi-fi or lo-fi can be useless.

Guoyang Huang (Guh6) 11:12:26 1/29/2014

In this reading, I learned that low-fidelity prototyping or lo-fi is building prototypes on paper and testing them with real users. Even with the paper technique, one can achieve quality in early development because it’s fast and brings results early. Hi-fi is the opposite of using tools to create a highly visualize example and takes a longer time to build. I’ve also learned that the more time spent on an interface, the less more attached the designer will get and unlikely to change for hi-fi. The way lo-fi works is because it make the developers have concern with usability and revise their iterations based on them. The first stage is get all the materials you need to assemble paper together, cut them, and make design with them. Second point is the set a deadline to always have something there so that the users can see and make refinements based on that. Third stage is similar to our programming uses of modular which is make models so one can move them around so they’re not fixed and immutable. The second stage is to prepare for your design to be tested. The first point is to use task analysis that we went over in class to select our user base. One new idea I learned is surrogate users, those who are not the clients and free from whatever association to prevent testing. The Second point is to prepare a test scenario that is to do a walkthrough of the design for actual uses. The third point is to run the design in-house with the design team before sending it out for outside testing. The actual test takes four types of people: greeter, facilitator, computer, and observer and the roles should be rotated among the team with session lasting a little over an hour. The most important part of the process is to write the information down so that it can be used later on, otherwise the hi-fi or lo-fi can be useless.

Brian Kelly 11:42:01 1/29/2014

I found this article funny because it focuses on the tendencies that application programmers have but shouldn't do. I know that I am guilty of many of the things that the author mentioned, like you shouldn't jump right into a hi-fi prototype and you shouldn't try to manipulate your user to use a system that makes sense to you but not to them. The idea of lo-fi prototyping seemed pretty simple but after reading the article, there is far more to it than I realized. Those that embrace the lo-fi "paper" prototypes spend a lot of time and effort developing and testing them in order to save time, money, and effort later.

Zach Liss 12:18:59 1/29/2014

Today's reading was about the benefits of using lo-fi prototyping vs hi-fi prototyping. The idea of using paper to quickly craft many prototypes in a short period of time seems relevant to the next phase of our group project. It will allow us to apply Fudd's fist law of creativity... "To get a good idea, get lots of ideas." I like how the appearance of a paper prototype forces us to think about content instead of just appearance. It also allows us to go through the maximum number of iterations of designs in the shortest time period.

Ariana Farshchi 12:36:15 1/29/2014

The reading, Prototyping for Tiny Fingers outlined the technique of building prototypes on paper and testing them with real users, which is known as low-fidelity prototyping (lo-fi for short). Lo-fi prototyping is a simple and effective tool because it allows you to demonstrate the behavior of an interface early in development. To build a lo-fi prototype, you must first assemble a kit of all basic crafting supplies such as: paper, blank cards, adhesives, markers and sticky notes. You then must set a deadline so you are forced to take a preliminary crack at every important aspect of the problem you are solving. After this, you can begin to construct the model, striving to make something that will be easy to control for the person playing the computer. Once the model is complete, you can begin preparing for a test. You start by selecting the users. To do this you must understand the backgrounds of the people who will be using the software. The group must have test scenarios ready, so that the tests are meaningful. The group must also practice these scenarios so that when actual testing begins, things will run smoothly. The testing group is made up of four people: the Greeter, Facilitator, Computer, and Observers. The typical test session usually lasts a little over an hour and goes through three phases: getting ready, conducting the test, and debriefing. When the hour is over, a 10-minute debriefing session takes place to ask questions and gather impressions.

Michael Mai 18:26:04 1/29/2014

This paper is talking about the importance of lo-fi prototyping. The author discusses the general ideas behind lo-fi prototypes and their benefit.s Lo-fi prototypes are a blueprint for a project done with paper and pen. This method is very effective because many different interfaces can be presented quickly and cheaply. This is contrasted with hi-fi prototyping where it takes weeks and a lot of money to get prototypes up. Any changes to this method will cause even more delay. With lo-fi prototyping, ideas can be changed around quickly because it is just using a piece of paper. It is also important to have potential users present during this process so that their critiques and ideas for improvement can be heard and implemented into the interface. The author talks about having users test the interface doing something such as order food from a menu to display the ease of use of the interface. Then the author describes steps for preparing for a lo-fi prototyping session. Some of these things include selecting the right users, preparing test scenarios, and practice. Finally, he talks about the importance of evaluating the results, whether using lo-fi or hi-fi methods. Without doing this, the process is useless. Overall, I think is a good article on a subject that I really never heard about. This article brings up some very good points. I definitely think that lo-fi prototyping is the best way to go about designing an interface. The author makes very good arguments for this method and it has really changed my views on the importance of prototypes. Also, highlighting the importance of having the target user groups test the interface was very good. This article definitely opened my eyes to a new way to design a project.

David Grayson 19:37:43 1/29/2014

“Prototyping for Tiny Fingers” begins by introducing two types of prototyping, the latter of which is called lo-fi or lo fidelity prototyping and is very interesting. Instead of doing a computer based prototype, the developers in the presented example of lo-fi prototyping made a paper model of their interface and pretended to be the computer to test the functionality of the interface with potential users. Lo-fi prototyping seems appealing largely because it is potentially faster and cheaper and actually allows user feedback. Also, playing the role of the computer can provide valuable insight to the developers concerning the flow. The author also mentions, however, that hi-fi prototyping can make developers lose focus, concentrating instead on things like font, and it can be tough for developers to separate themselves from the difficulty of implementation, resulting in a developer less likely to want to change his/her product. After discussing the benefits of lo-fi paper-prototyping, the author discusses how to go about building a lo-fi prototype. He says that first you should ensure you have the materials, since not everyone has an arts and crafts supply lying around (the author also includes specific supplies here). The author then says you should set a deadline and worry about getting a prototype before working out every detail, and to construct models instead of illustrations, to help out the person playing the role of the computer. Most intriguing to me was the explanation of the testing. The author says, surprisingly, to try to find users representative of the ones who will be using your interface. Most testing I know of is in-house with hired testers, not necessarily your tech-unsavvy individuals. Overall the article is intriguing and provides an alternative means of rapid prototyping that I very much look forward to trying out myself.

MJ (Mary Letera) 20:28:29 1/29/2014

This day’s reading, from 1994, was called “Prototyping for Tiny Fingers”. It talks about prototyping, both lo-fi and hi-fi. Lo-fi prototyping can be something like sketching out a design on paper. Hi-fi involves more technological means of constructing a model. The hi-fi method has some downfalls. Among these are the length of time that they take to build, and that they can distract from important areas that need evaluating rather than superficial details. Additionally, a hi-fi prototype can set expectations about the final product that are hard to change.

Robert McDermot 20:49:24 1/29/2014

This was certainly an interesting article. Going into it I was definitely skeptical about the advantages to using a "lo-fi prototype" to test out user interfaces. I would have thought that using a drag-and-drop interface builder (ala Visual Studio) or an even xml editor with a nice preview (ala Android Studio) would be a decent way to prototype interfaces.

Upon considering some of the author's arguments, however, I came to realize the value in doing some design testing via "pen and paper". First, it would certainly be easier to deal with any bugs that might happen. During such an early stage, a program is sure to not be in a complete working state and your interface may not be complete enough to deal with all possibilities that a user might perform. A paper interface can solve this problem because you could, on the fly, fix an error you hadn't seen before.

Second, the author has an excellent point about the kind of feedback that you would receive on your design. When using a hi-fi prototype, the tester is a lot more likely to comment on things that aren't mean to be in a finished state yet, such as widget margins, fonts and colors. While this is helpful, it is also probably known as the designer didn't want to spend the time on it right now in order to look at the bigger picture. When using a paper model, the tester will be more forgiving and understanding of these things and will more likely just comment on the "big picture" that you were testing for in the first place.

While I don't think this kind of lo-fi testing is appropriate for every project, there should definitely be a place for it in any semi-complex team project and I plan to try it out in the future.

Nicholas Amoscato 21:41:26 1/29/2014

After discouraging system-based design in which user feedback is not considered until the end of the design stage, Marc Rettig’s article “Prototyping for Tiny Fingers” introduces the concept of low-fidelity prototyping. This technique in which designers use traditional paper to illustrate and test software interfaces, has proven to be fast, cheap and effective. Unlike “hi-fi prototyping,” simple paper prototypes force the reviewers to focus on the big-picture content and flow, concepts that can easily be changed without the unnecessary complexity of programming. Rettig described his adoption of low-fidelity prototyping as a “Trojan meme” – that is, the usability concepts demonstrated by the rapid, paper prototypes were realized by the entire team. In the next section of his article, Rettig describes how to build a “lo-fi prototype.” This process involves (1) assembling a kit that includes heavy white paper, index cards, various adhesives, markers and sticky note pads; (2) setting a deadline that forces you to look past details at this stage in the game; and (3) constructing models, not illustrations, that attempt to emulate the interaction of different components on the screen. Next, Rettig describes how to prepare for a test. This process involves (1) selecting your users who should at least fit a similar profile as your actual clients and represent the whole range of characteristics in your target audience; (2) preparing test scenarios that incorporate realistic data and tasks; and (3) practicing. Rettig suggests that it takes four people to actually execute a test session that lasts an hour on average: a greeter puts the participant at ease before the test, a facilitator takes the lead by giving instructions and adhering to the time schedule, a computer manipulates the interface, and an observer(s) takes notes. After the test session, notes are organized, summarized and prioritized. Overall, lo-fidelity prototyping seems extremely effective, and I look forward to using this concept when designing interfaces in the future.

Brett Lilley 21:53:59 1/29/2014

This reading was all about "lo-fidelity" prototyping, which is a interface design prototyping technique. Basically, it is quite simple: the designers build the prototypes for their designs on paper, allowing for physical interaction between the prototypes and the users. This technique is opposite of "hi-fi" prototyping, which is prototyping using high-level programming languages or other software to design computerized prototype models. Although hi-fi technique seems more modern and less labor intensive, the author puts forth a good argument for lo-fi prototyping, which is what the reading was about. The author introduced the supplies necessary (which are physical supplies, ranging from paper, to writing products, to adhesives, etc), the process of building the lo-fi prototype, how to plan for the actual user test, how to carry out the user test, and then finally, how to deal with the results. With either technique, the end goal is to have a model that is user tested, then modified based off the results, often the modifications are made over several iterations. The author makes several good arguments, however I thought the best pro-lo-fi technique was how it allows the designers to take a step back from the actual design and focus on the functionality, which is simulated during the testing phase by the designer acting as the "computer." This was a highly relevant reading, given our current course work.

Zhanjie Zhang 22:15:36 1/29/2014

The reading begins by explaining the idea of low fidelity prototyping. The process is done by having developers spend a few weeks designing the interface. One plays the computer while the other observes and takes notes. This process continues until the team has revised the design. Prototyping is very important however developers do not always see the value. Another method is the hi-fi. The problem with this methodology is that it takes to long to build and change. Because we cannot evaluate an interaction design until after it is built changes to the design is very difficult. Paper prototypes however it’s much faster and it’s much easier to learn. We are trying to find feedback on the important things, generally the controls, terminology, and expressiveness. We must also be aware that developers resist change. This prevents people from changing up their old design, which is bad in the developing of applications. Also, a bug in hi-fi can bring the test to a complete halt. To build a lo-fi prototype we must follow the following steps: assemble a kit, set a deadline, and construct models not illustrations. We must also, assemble our users, prepare test scenarios, and practice. We must conduct our test and evaluate our result. Because we have spent a lot of time gathering and analyzing data you must also spent a lot of time sorting Reading our results drink out test sessions. These piles inform a written report on all findings of forms agenda for next meeting.

MJ McLaughlin 22:37:48 1/29/2014

“Prototyping for Tiny Fingers” provides a really interesting and in-depth look at an idea I had never really thought that much about before. This idea, “lo-fi” prototyping, helps interface designers to rapidly come up with, test, and improve upon a great number of ideas about the interface they are designing. As opposed to “hi-fi” prototyping, which describes such approaches as actually developing a prototype interface in software, lo-fi prototyping relies on very simple and powerful tools like paper and creativity. In this approach, designers essentially come up with an idea for an interface, construct the different windows, widgets, menus and so on out of paper, markers, tape and the like, and present this prototype to testers with similar backgrounds and skill sets as the actual target customers. A greeter will welcome the tester and make sure they are comfortable with what they are about to do, and then a facilitator will guide the tester through accomplishing certain tasks that should be enabled through the interface, and inquire about their though process while they do so. A person acting as the computer responds to input (finger motions/voice typing) by the tester by switching around the paper interface “components” as appropriate, while an observer takes notes on notecards about any problems with parts of the interface, as well as possible solutions to those problems. After testing, these issues are compiled, their notecards placed next to the appropriate component, sorted by priority, and the designers then come up with possible solutions to implement and test all over again with even more users like those that will end up actually using the product. This approach to prototyping allows rapid development of ideas as well as improvement on those ideas based on feedback from people like those who will actually be using your product (probably the best kind of feedback there is), which all results in a better interface and better experience for the end user. Unlike with hi-fi prototypes, lo-fi ones are easy to change and allow for focus to be placed more on actual usability, important ideas like mental models and affordance, and improvements than “fit and finish” issues like font color choices. It allows for evaluation in the formative stages of production when there is still time for ideas to be tested, evolve, and be implemented before any actual coding is done. Setting deadlines and having easy-to-use materials like construction paper lets designers get ideas out quickly, test them, and improve them. By helping designers get out, test, and improve their ideas and interface designs in a very rapid and useful way, “lo-fi” prototyping is an invaluable tool in not only the design process, but also in users’ experiences with your product. All of this can be meaningfully applied to mobile interface development with its inherently wide user base and rapidly evolving nature, as well as to our group projects, and have a pretty powerful impact in a very positive way.

Longhao Li 23:39:00 1/29/2014

The author begin the article with the description of lo-fi, low fidelity, which is the technique that building prototypes on paper and testing them with real users. It is good to increase the quality of software since the paper prototype is easy to be revised. It is better than hi-fi prototypes because it take too long to build and change. Since hi-fi prototype need to build the software then do test, it will caused a lot of time to change the application, and the test may lead to some suggestions that may not be important like fonts and colors etc. Developers don’t want to keep changing the software because it is complicated. One bug may cause the test achieve nothing. Then the author introduce an idea, Trojan meme, which is the idea that developers need to listen to the suggestion of their users not themselves so that the software will fit the requirement of the users. After that, there are some suggestions to make a good lo-fi prototype: Assemble a kit to give the team the right tools; set a deadline to make job done on time; and constrict models not illustrations so that the test will much more useful since the test have a paper based simulation. Also, there are some suggestions on preparing for test: 1. select right users. The tester should be in the same situation with the potential customers so that the results will be reflecting what user needs. 2. make test scenarios. Using scenarios will help to narrow down the test scope. proper scenarios will help the test to get meaningful result fast. 3. practice. doing practice before real test will help to eliminate something that put there by mistake. There are some suggestions about how to conduct the test people’s rules and duties. Meanwhile, there are suggestions about evaluating results.

Zach Sadler 23:46:56 1/29/2014

Today's reading was actually really useful. Soon we're going to have to make a prototype of our app to give to users and get their feedback, and making physical paper prototypes seems like a fantastic solution. As I read my mind was already wandering towards how applicable this is to our class! What a reading! Lo-fi prototypes seem like a much better idea than Hi-fi, especially in the context of our course where we're on a strict deadline. Being able to quickly iterate on the design (hey, sounds like the Iterative Design Process!) is a really neat thing that everyone likes! Yay! The idea that we should have multiple overlays and papers for our interface to truly capture the interfaces changes over time is a great one, and I think it will be easy to do with the mockup tools we used for our group brainstorm. Finally, the actual methodology for conducting the tests with the users and the setup of 3 people and a camera to conduct the tests seems like exactly what we'll do in our group. What an informative, enjoyable reading! Hooray!

Alex Stiegel 23:48:45 1/29/2014

The reasoning against hi-fi prototyping is pretty solid. My favorite from experience is that developers are against making changes. Once you finish something you are like yes I like this. Please don't make me do it again. Making the prototype seems a lot like arts and class time. It's interesting, but I'm not sure it needed to be explained so much. On the other hand, I find the set up section very important. TEST YOUR PROTOTYPE. It's really awful when you give someone a prototype and there is an awful bug that just ruins the testing. Everyone just points out that bug. Although it seems much more easily fixable with paper. The next section is about testing. I have learned about this in our game design course. And looking at the person playing is so helpful. Their facial expressions and hand movements are VERY informative. Sometimes you can just tell that they are confused based on their eyes. And it's REALLY hard not to help them.

Matthew O' Hanlon 0:05:53 1/30/2014

The first section of the article talked about prototyping as being some code for the actual product, but not a final product. The author then went on to describe a scenario where a group of people prototyped the user interface with paper cutouts instead of using an application for mock prototyping. Having someone interact with paper widgets being powered by a human computer is the best way to find the usability of your design. This technique is called low fidelity prototyping, or lo-fi for short. The author also was a little bit concerned about the fact that lo-fi prototyping isn't widely adopted in the software engineering community. The author believes that paper prototyping or lo-fi prototyping can help organizations that need to use prototyping as part of their development process. He says that allows you to demonstrate the behavior of an interface early in the development and test those designs with real users. I don't know how you can test the paper cut out with users considering how complex some user interfaces are today. Nevertheless I do agree with the author if you want to get a good idea then you need a lot of ideas to test. The author argued against using hi-fi prototypes because they take too long to build and change. I agree with the author on this one. The author claims that each iteration means it is an improvement of the last design. I don't know that I agree with this necessarily. I do know that having more iterations gives you better quality control possibly or better opportunities to see the best design. I don't know that it provides improvement over each single iteration. The author points out a dilemma with prototyping. He points out that some interface prototypes take a long time to build but after building you need to make changes but the design changes are difficult. That is why you need to get feedback on the large components of your design. In general you need to get feedback on the flow, the general layout, the terminology, expressiveness in the power of your basic metaphor. In other words you don't want to get into the nitty-gritty of design while you're still prototyping. Sometimes you can obsess over small things like colors and fonts. There are pitfalls that many developers take when prototyping. First of all, developers resist changes. I can vouch for this. The author makes a very good point when he says that you should use lo-fi prototyping at the very beginning of your design phase. I certainly do agree with the author that you as a programmer would be less hesitant to re-craft a design if it only took you a few hours to make. There's another point the author brings up that if you have a very complex and mostly finished prototype that it might set expectations that are higher than what you can deliver. You should be very careful to give a basic functioning prototype. The author also points out that a single bug in a hi-fi prototype can bring a test to complete halt. I don't know that it can bring a test to complete halt, but depending on the circumstances they could do just that. Depending on the particular test, it doesn't necessarily bring everything to halt, but like I said there are dependencies on every test. I do agree with the author that your prototype should be complete and robust. Lo-fi prototyping gives developers a chance to learn about usability and formative evaluation. He also points out that it maximizes the number of times you get to refine your design before you commit to code. I agree with the author that it is a very good learning opportunity for developers to see the reactions of users after each successive iteration in their design that they present. Handmade prototypes force users to think about content rather than appearance. I don't know how much users will focus on the content or appearance. I know that users are usually put off by an ugly display. You also have to concern yourself with making working models for prototypes, and it can't be just an illustration. Think about the components and the widgets that you will be putting on the palate, and think about how you're going to transition to another interface or another view that the user will interact with. You might want to create handles or use smooth surfaces so that it won't destroy everything in your prototype when you're trying to transition from one display to the next. You can get creative with certain types of widgets on the display. The author pointed out that you can use machine paper with hole cutouts in a menu and then that way you can mimic a kind of sliding wheel. You can also use the photocopier to make copies of widgets that you'll be using over and over again, but also make liberal use of white out. Make sure that people who excel the different types of design get those responsibilities and work well with other people who have abilities that Excel and other areas. User selection also matters very much. You should take the time to do user and task analysis to understand the people who are going to be using the software. You can run ads in newspapers recruit user university students and contact local user groups. The person testing your prototype doesn't have to be the end-user per se, but they have to fit the same profile. Before you go about testing you need to prepare some test scenarios. Make sure that they're drawn from your task analysis and that they describe the product and use in a typical situation. Then just select a few scenarios and use these for testing. Do some review with people to make sure that any data you’re using is realistic. Be sure to practice some of your scenarios that you selected before you do the testing. It's good to just conduct dry runs before you do the testing with people outside of your team. After conducting a test, take some time and evaluate the results. The author suggests that you take at least a day with each iteration that you use for testing. Sort out all the notes that were taken, and try to prioritize them. Use this prioritization to form an agenda for the meeting where people will make suggested changes to the user interface. From there, you must successively improve each new design, building on the corrections from the last one.

Matt Landram 0:14:51 1/30/2014

Today's reading was very helpful in designing an application interface. While the interface design in the text was for a desktop environment, the concepts can be brought over to the mobile environment. Having an "interactive" paper mockup can be really helpful in helping both the creator and the consumer test out what designs are most intuitive/useful, and the tips for what materials to have on hand were very useful.

Hao Zhang 0:19:04 1/30/2014

This article shows us the important of prototype: when we come up with an idea, the first thing we need to do is draw a prototype instead of coding. Sometime we have a new and great idea. We may become excite and wrought-up—we want to finish it immediately! However, in this situation we may ignore many details and don’t even know where to start it. In these cases, we need to make an outline, list all the functions and details we need. After thinking deep into the idea, you may find out some problems or better solutions. When we finish a complete outline (there may be not a “complete” one; everything could update in the future), we can draw our user interface on paper. Why by hand? Because hand make drawing is flexible and free. You may not able or hard to draw something on computer tool because of the technical restriction. The author also shows us some prototypes of the projects that his team makes. It is not hard or serious but useful. And then, the author introduces us three steps to Prepare for a test after coding: 1. Select your user; 2. Prepare test scenarios; 3. Practice. These are important and meaningful steps. And finally, we should collect evaluating results and make a data statistics for improving this project in future. In Chinese old saying: Haste makes waste.

James Devine 0:19:26 1/30/2014

This article explains the process of low-fidelity prototyping, or “lo-fi”, and how it can be more beneficial than hi-fi prototypes. The author states that developers often spend too much time building fancy hi-fi prototypes. Even once they are built, these hi-fi prototypes can become even more time consuming to debug. Lo-fi prototypes are built with paper and other arts and crafts materials, and they require the developer to act as a computer when a user/tester gives input. This allows the developers to test many iterations of the program before they ever have to write any code. Once a developer has spent a considerable amount of time writing code, it is often difficult to get him/her to completely change the code. I am certainly interested to try this form of prototyping as I begin to design my group project, as it seems like an extremely useful tool.

Brian Kacin 0:53:19 1/30/2014

The article starts with the advantages of lo-fi, or low fidelity prototyping. That putting prototypes on paper is beneficial to get many users test your product for appropriate feedback. It is a cheap way rather than actually creating the interface and having them test it first, which makes the most sense. As the article claims, a “hi-fi” prototype that is advanced, is too difficult to change and that’s more time to make rather than the “lo-fi” system for design. If something needs to change from the hi-fi prototype, it could even take weeks to change, however with just a paper design, you can change for the better on the fly. Once making a hi prototype, the developers took a long time to implement it, so their work is devalued once they have to change something. One of the major problems about hi-fi is that if there is a bug in it, it might bring the whole operation to a shut down, not to mention a waste of time and money. Using the lo-fi, it creates a high number of times to redefine your design before the software developers commit to code. This can be thought of as seeing a house built on paper before you build it with brick, wood and materials, because if the paper one can be evaluated and fixed easily, the already built substance will be terrible to fix to perfection. To build a low prototype, first you must get paper and drawing tools. Once you create a few designs, set a deadline to strive to get to. You must also build models, not just illustrations, things the user can see and interact with. You must pick your users to test the designs and listen to their feedback and evaluate the results. Once you have a high number of feedback and finalize good low prototypes, it will be a great investment to start the high level prototype.

Bret Gourdie 1:33:36 1/30/2014

This reading expands upon the subject of paper prototyping, namely the numerous advantages that a virtually cost-free prototype brings. They are easy to create as well as alter, beneficial for rapid prototyping and quick changes without having to reimplement anything. They lack the emotional attachment that developers hold over their crafted work, even if it is just a prototype. Any bugs in a lo-fi prototype can be somewhat ignored with a frivolous hand-wave. After an anecdotal instance where paper prototyping worked quite well with a restaurant application, the sets to building a lo-fi prototype are shared. First, assembling of art supplies is a must, albeit cheap. Next, a deadline must be set; this approach hammers home the notion of "make something, refine it later," as thinking too much may lead to a sort of "development hell" where a product never leaves the mind. Finally, they urge one to construct models, not illustrations, in that the prototype should be something usable. This involves making the common components of windowed forms accurate to their electronic counterparts, like highlighting lines or drop down boxes. Testing is a crucial step here. The users that are picked should be representative of your target group, but they suggest finding all types of people, which I find to be a succinct idea. These users should be given a prepared test scenario such that one can gauge the effectiveness of their design by requiring a task to be completed, much better than "figure it out" as I would have thought. Most important of all, in my opinion, is the effective evaluation of results. After using a paper prototype, there is a lot of information to harvest that may not be immediately clear. It is important to note what went right, wrong, slow, fast, frustratingly, pleasantly, and so on. Putting the user at ease during the testing process is key to having a good test; pressure would negatively impact the results, perhaps manifesting a false positive. Paper prototypes are a fantastic idea to form an accurate prototype of a product cheaply and quickly. In this way, users can attempt to use a product before any code is ever written, the imagination being the most powerful tool here. Although not appropriate in every situation, lo-fi prototyping is clearly the way to go for our group projects and even individual assignments if need be. It is my hope that we find time to utilize such an approach.

Melissa Thompson 2:19:06 1/30/2014

This reading is about lo-fi prototyping, and the advantages it gives designers over hi-fi prototyping. The author discusses a simple "implementation" for testing designs: paper prototyping, where actions are simulated using pieces of paper and a human acting as the computer. This is a type of lo-fi prototyping that can be used early on in the design process to improve the final product significantly. The opposite, hi-fi prototyping, is when high level languages, software, or other similar tools are used to create detailed prototypes. One downside of hi-fi prototypes is that they can take a lot of time and knowledge to implement and test. Then, if changes are needed, the changes could take a lot of time too, and the developers might not want to make the effort to even make the changes. Lo-fi prototypes, like paper prototyping, require virtually no knowledge and very little time. Changes are easy, so more time can be spent coming up with a good design, and less can be spent focusing on the implementation. Designs can be changed many times allowing developers to really create a useable, refined product. Users are also more likely to focus on big design flaws when using lo-fi prototypes, because they aren't hung up on minor details like fonts or colors like they are when rating hi-fi designs. The author then details how to build a good lo-fi prototype: He suggests buying a bunch of school supplies to get creative with (away from a computer), setting deadlines so you don't spend too long on little details that don't matter as much in the beginning, and creating separate models for every response that could happen in response to a users actions. When testing, you should use a diverse selection of people who fit into the target user group and plan realistic testing scenarios. The author states that there are four people that are needed to successfully conduct tests: a greeter to introduce the prototype to the users, a facilitator to run the tests by instructing them and asking questions, a human computer to "run" the application, and one or more observers to take notes on what happens during the testing process. The whole point is to get information about how the target users respond to the application, how they use it, any roadblocks they encountered, etc. Reports are written and these are used to restart the prototyping process with updates to the design. All in all, he recommends lo-fi prototyping because it allows for flexibility to make changes, users can focus on major design elements better, and making the actual prototypes is faster and easier to accomplish regardless of knowledge.

Megan Ziegler 2:35:17 1/30/2014

Today's reading explained the ideas behind a lo-fidelity prototype. Many people jump straight to coding to produce their product, but this article suggests that, instead, prototypes can be made with paper and pencils. These designs should be modular and reflect the final product, but they are faster and less expensive to make, allowing for more testing and easier revision. Testing a paper prototype works exactly as one would test a hi-fidelity prototype, only with a computer being replaced by a silent person who automates the task process. A tester can press a button, for instance, and it is the "computer's" job to work through the task. Only one person may speak to a tester, and this model has proven very effective in working out design flaws.

Pedro Alvillar 3:27:14 1/30/2014

Good development teams practice low-fidelity prototyping. Low-fidelity prototyping (paper prototyping) encompasses drawing prototypes on paper and testing them with real users several times before beginning to actually develop the product (in this case the interface). Paper prototyping allows for fast and cheap production of multiple ideas. With this in mind we must highlight the downsides hi-fi prototypes entail; some of these downside are: hi-fi prototypes take too long to build and change due to the tools used in creating said prototypes, reviewers of a hi-fi prototype tend to overlook basics and simply critique irrelevant details about the prototype, and designers of the prototype tend to become attached to said prototype because they put a lot of effort into designing it. There are several guidelines one most follow in order to successfully build a lo-fi prototype. These guidelines include: assembling a kit containing materials (sticky notes, markers, notecards, etc) that will be used in drawing the prototypes, setting a deadline in order to avoid over-thinking, and keeping in mind that a model is to be constructed and not just an illustration. Even before starting to design your prototype, you must keep in mind who will be using it (the users) in order to look for testers and implement their feedback into the design. You must also prepare test scenarios which you will ask the testers to execute in order to get meaningful feedback from them. In order to get the most out of a test session four people are needed: the greeter, the facilitator, the “computer”, and the observer.

Buck Young 6:18:45 1/30/2014

This column champions the usefulness of low-fi UI prototyping. Low-fi prototyping is a system where one person "plays computer" and moves little squares of paper around which act as the UI for any given system. The main benefit of prototyping this way is the higher number of design iterations, which can certainly improve quality. Hi-fi prototyping is useful when selling an idea to a client or testing a look-and-feel, so let's not completely discredit it! However, hi-fi prototypes have several problems: they take too long to build and change, feedback is usually on specific things rather than big ideas, developers are reluctant to change their work, they set expectations high, and they can be buggy. Creating a low-fi prototype is easy; assemble a kit (heavy-duty paper, index cards, adhesives, markers, sticky notes, and scissors). This system seems like it would drastically improve the quality of designs and I look forward to testing it out!

Aamir Nayeem (aan14) 8:07:19 1/30/2014

This reading focused on the concept of lo-fi prototyping (or "paper prototyping") and its advantages. While the author definitely does a great job selling the concept, it just seems like, similarly to the group brainstorm, it's often seen as unnecessary or a waste of time in a corporate environment, so I'm sure it's probably not used too much, which is unfortunate. I really do like the idea, though. It seems like, based on how early paper prototyping is used in the design process, the design ends up being the thing that pushes forward the development rather than the features and functionality. This is also good, since we've learned throughout the course so far just how important design can be—the best ideas carry no weight if a user cannot/does not use them. I'd definitely want to try it out at some point for a future project.

Derrick Ward 8:16:49 1/30/2014

Today's reading was about the different processes one could take to develop an efficient user interface for mobile devices or tiny fingers. Two approaches to finding the correct user interface are lo-fi prototyping and hi-fi prototyping. Lo-fi prototyping is the process of using items such as computer paper or construction paper, as well as other supplies to come up with a quick and dirty user interface design that can be demoed. The author discusses several reasons for this approach: one is the short time it takes to come up with different iterations of the user interface. Another is that the developers will not emotionally lock themselves into one given iteration, because it didn't take long to design that given iteration. Also the author discusses that lo-fi prototyping encourages and helps motivate creativity from the team members, because of the use of art supplies as oppose to just software tools. The other approach to finding the correct user interface is hi-fi prototyping. With this approach you spend a lot more hours coming up with a close-to-finish product before you demo it off. Usually with this approach the developers are emotionally locked into their given iterations because of the amount of time they have spent working on it. The author then begins explaining how to find the proper user groups you would like to demo you user interface to. To find a user group one must think of the knowledge and skills the users should possess when using the user interface and then go and try to find that audience. The author discusses that the final customers and team members, and friends are the wrong audience to demo your user interface to because they will try to express their opinions while still trying to make you happy. From this reading I have done a complete 180 on my views towards lo-fi prototyping. I always imagined that the user groups that one would demo his or her designs to would feel less motivated to give honest opinions because of the quick and ugly paper designs put in front of them. I had not considered the other aspects. I also would have thought the hi-fi prototyping approach would be the most professional, even though I knew it would take way longer.

Ryan Ulanowicz 8:47:29 1/30/2014

This reading deal with creating lo-fi prototypes for user interfaces. In the beginning user interfaces were created in paper models, that allowed a team member to react to user touch the same way the computer will once the interface has been written. Doing this sort of testing with users is known as “lo-fi” testing. Since the barrier to entry is so low it allows for maximum creativity because as Fudd’s first law of creativity says, “to get a good idea, first get lots of ideas.” The other alternative, that includes most other techniques (such as programming in specialized languages), is called “hi-fi” prototyping. They take a long time to make, weeks in some cases. Reviewers will also often critique fit and finish issues, when you really want them to give you more general feedback. This is caused by their expectations of computers. Bugs in these can bring the whole experience to a halt and cause more time loss. The rapid rate of change, that users can see is also very important. They are able to react to changes in real time instead of having to come back and potentially forgetting their initial tests with the product. To do a lo-fi test you must first get a kit of materials together, then set a deadline. Deadlines help to keep the test small, while putting some pressure on the team. Make sure that you are testing models, not the illustrations and graphics that you intend to eventually use, keep it high level. Selecting users is also important, it is important to get users similar to those whom you expect to use your product in production form. This means education level, level of computer knowledge, etc. Then you must prepare for your test by assembling the users facing items and practicing amongst the team. Now it’s time for your test. There are important roles to fill while doing a lo-fi test. First is the greeter. This will help the user keep their stress level down. They will then be handed off to the facilitator who is the only person that deals directly with the user. They will give them instructions and encourage them to say what they feel. Next is the computer, the person who manipulates and changes the model. This requires a deep knowledge of the behavior of the model that you intend to test. Observers are the people who take notes. They must take notes about the model with trying ignore any sort of issues with the test itself. They also must try and ignore the users feeling of passing/failing the test. Now that the test is over, we must use these results to improve our interface, potentially doing the whole thing over again, with the information gathered in the first helping us to improve.