- 1 Slides
- 2 Readings
- 3 Reading Critiques
- 3.1 Charlotte Chen 21:26:19 1/28/2016
- 3.2 Michael Oles 0:31:37 1/29/2016
- 3.3 Robert Webb 11:54:06 1/29/2016
- 3.4 Joshua Fisher 21:58:30 1/30/2016
- 3.5 Tiffany Martrano 12:52:47 2/1/2016
- 3.6 Jonathan Blinn 18:21:08 2/1/2016
- 3.7 Casey Nispel 18:54:07 2/1/2016
- 3.8 Andrew Lucas 19:00:00 2/1/2016
- 3.9 Luke Kljucaric 19:29:05 2/1/2016
- 3.10 Daniel Hui 21:37:41 2/1/2016
- 3.11 Bogdan Kotzev 21:49:09 2/1/2016
- 3.12 Matthew Reinhold 21:54:14 2/1/2016
- 3.13 Max Benson 22:32:07 2/1/2016
- 3.14 Nate Patton 22:52:52 2/1/2016
- 3.15 John Phillips 23:14:23 2/1/2016
- 3.16 Alex LaFroscia 23:53:33 2/1/2016
- 3.17 Jason Naughton 0:06:00 2/2/2016
- 3.18 Arjun Mukherjee 0:13:27 2/2/2016
- 3.19 Chris Finestone 1:08:56 2/2/2016
- 3.20 Sarah Dubnik 2:14:17 2/2/2016
- 3.21 Adhyaksa Pribadi 2:24:33 2/2/2016
- 3.22 Xinhai Xu 3:00:58 2/2/2016
- 3.23 Dustin Chlystek 3:15:54 2/2/2016
- 3.24 Luke 6:25:34 2/2/2016
- 3.25 Alexandra Krongel 6:56:40 2/2/2016
- 3.26 Ishvaraus Davis 7:20:34 2/2/2016
- 3.27 John Riesenberger 8:13:42 2/2/2016
- 3.28 Zane Hernandez 8:19:35 2/2/2016
- 3.29 David Fioravanti 8:34:11 2/2/2016
- 3.30 Yijia Cui 8:34:51 2/2/2016
- 3.31 Clark Nicolas 8:50:58 2/2/2016
- Prototyping for Tiny Fingers, CACM. April 1994. 37(4): 21-27. Rettig.
Charlotte Chen 21:26:19 1/28/2016
This is a very concise and informative article that talks about the benefits and procedures of low fidelity prototyping. I really enjoyed it because at my internship this summer, we actually used this method in prototyping our web application’s user interface at the beginning, and we found it to be very efficient and useful. I strongly agree with the benefits of lo-fi over high-fi, especially the part where developers do not prefer to change their code they spent a long time working on. Lo-fi is less time-consuming while offering similar quality feedbacks from the users. The process of preparing for a lo-fi prototype is very organized and concise, so does the testing section. After reading the sections, I found that the lo-fi prototyping we did before violated a lot of the rules the article suggested. The most important one is that we did not show our prototype to our potential users and have them look through and “use” it, which defeated one of the most important purpose of lo-fi prototyping. For our mobile app project, I definitely will keep the article’s guide in mind to achieve better interface/interaction design efficiently.
Michael Oles 0:31:37 1/29/2016
Low-Fi prototypes seem like an important step for building applications. It's something I've never done before because most of my previous classes have not been focused on UI. I think it will be much easier than programming each interface idea but still pretty hard because on a smartphone there are so many moving parts and some things that cant be modeled like a camera or accelerometer. It also seems like it requires alot of people to have a computer, greeter, observers, and Facilitator as well as end users, there could be alot of disagreement over how to run the tests.
Robert Webb 11:54:06 1/29/2016
I think it's inspiring to read about alternatives to making a hifi prototype and testing user's response with that. Personally, I think that design is not as important as filling the need that the user has, but I can see why you can go to great lengths to ensure the user's easy use path. I like the idea of sitting in a room and having a user use my app, in a lo-fi way. I feel like they placed too many people in the room though because the user is going to feel forced and awkward to have so many people waiting for every single movement that they make.
Joshua Fisher 21:58:30 1/30/2016
I enjoyed this article because the entire article pertains to our classwork. This article will definitely be used when we further develop our ideas for the group projects. I really like the idea of creating paper prototypes of apps, however I feel that you need someone who is artistic in order for the prototypes to look at least somewhat professional. There are plenty of application mockup tools online that are much easier to use and are quicker to produce/edit. Plus a lot of these tools can show previews on smartphones, so you can directly see how the app prototype will look on a screen. The testing portion of the article was also interesting, and should be useful when we work on the second group assignment.
Tiffany Martrano 12:52:47 2/1/2016
The reading for today emphasized upon various prototyping methods in order to create a solid interface for an application. I thought this article was interesting because it highlighted a lot of key concepts that are involved in building prototypes that I never gave much thought to. It also showed how to interact with users in order to make a more appealing product. I liked this article because I thought some of the material that was presented would be applicable to our group assignment that we're doing. It gave a lot of good tips on conducting user studies which I can see myself using for our next group assignment.
Jonathan Blinn 18:21:08 2/1/2016
At one point earlier on, the reading mentions the downsides to building a hi-fi prototype with one of them being how a developer can easily get attached to it and then looks toward change negatively. This is one thing as a developer that I can easily relate to. It usually isn't a great feeling putting in a lot of time on creating it just to have a lot of critical suggestions as to how to improve it. However, I could definitely see how working with lo-fi prototypes would help to eliminate this. It will certainly be weird working with paper prototypes at first but I can see some of the advantages it has. The biggest downside to this approach, however, seems to be the feeling a user would have while testing this paper prototype. Obviously it will be hard to get a paper prototype to feel and look like the finished product and that could impact the way the user feels about certain elements where they may be fine with it in the finished product.
Casey Nispel 18:54:07 2/1/2016
I think one thing that ‘s easy to forget that is brought up in the article is that you both have to know your user and also be aware that you aren’t your user. Many times when creating an application we design the interface and tools to be something that we would want to use ourselves and that we would find simple and straightforward to use. What a developer finds easy to use and what the actual user finds easy to use can be two different things though. Sometimes as a developer and designer you have to step back and remember who your audience is and what they need.
Andrew Lucas 19:00:00 2/1/2016
It was difficult to envision what a hi-fi prototype for an android app would be. If it means creating a functional interface that allows the user to do meaningful work, as the article suggested, then that is all an android app is. Also, I don't understand why the article discourages using family and friends as user surrogates. It states that feedback from friends and family is less reliable because they are more likely to want to please you, but I would expect the opposite. No one is more likely to honest with you than people with whom you share a mutual trust.
Luke Kljucaric 19:29:05 2/1/2016
I thought that these readings resonated well with me. I believe you shouldn't just go and start coding something without a plan on where you want to go. If you start by coding (Hi-fi) you are pretty much locked in to that design whether you want to change it later on or not. The first design of something typically isn't always the best design, therefore, the next design shouldn't require losing a lot of work. If you develop a Lo-fi prototype first, such as a quick sketch, you can visually see what you want to develop and that idea can change with ease if you see something that should be done another way. Prototyping is definitely an important aspect to any design, and I agree it should be done in a lo-fi manner.
Daniel Hui 21:37:41 2/1/2016
We use paper prototyping at my current workplace and I was unaware that this technique is called low-fidelity prototyping. The effectiveness, and efficiency of this method is quite ironic considering its relatively close to an arts and craft project of a elementary student. Hi-fi testing on the other hand, seems like too tedious and long of a process to efficiently and quickly bust out a design. It is way too much overkill for a process that could take a very short amount of time using paper prototyping. When using lo-fi prototyping the team can focus on the conceptual and overall design of the application without having to worry about nitpicky aspects of the application because the design using paper prototyping does not need to be exact/precise, it only needs to show the general and overall concept of the application in a really simple form.
Bogdan Kotzev 21:49:09 2/1/2016
I learned that Hi-Fi is not a very effective way for building prototypes. Learning about flaws in the design in the later stage are much harder to fix. Lo-fi takes advantage of finding these flaws early on by testing their paper solutions with users as soon as possible. Another interesting thing to note is that the designs made on paper from Lo-fi are used as computer screens navigated by a human being who pretends to be a computer. I think Lo-fi this is a very good way to begin designing a program.
Matthew Reinhold 21:54:14 2/1/2016
I agree that using a hands on representation of the software that can be manipulated and remade is incredibly useful for early design and testing work. However, I feel that design or mockup software exists today that is at least as good if not better than using a physical mockup just for the fact that you can redesign it instantly and not have to spend nearly as much time creating the mockup in the first place. I feel like the convenience of using quick but rough software mockup tools makes going that route more worth your time.
Max Benson 22:32:07 2/1/2016
The practice of lo-fi prototyping seems very useful in that it incurs so little overhead while yielding so much information about the potential flaws in a given design. I also think that it would help to separate a developer from implementation concerns and allow them to focus entirely on the front end system usability. Also, it (ideally) allows testers to experience the design as though it worked perfectly, something difficult to accomplish with hi-fi prototypes without putting a substantial amount of time into them. Overall, it seems like a great way to get invaluable feedback on various design decisions without spending a lot of time implementing each one.
Nate Patton 22:52:52 2/1/2016
It was very interesting. I never thought that the use of paper prototypes and the benefits they have. I also never thought of how the low end good be better than the high end prototypes.
John Phillips 23:14:23 2/1/2016
I really liked this reading, although I think they took the low tech theme a bit overboard. It seemed like they pointlessly wanted to remove techology from the prototyping process. For instance, the observers during the testing process took notes on index cards. Something like that I think could be done better with a computer. One part of the reading that struck me as particularly interesting was where he said that when reviewers were presented with a hi-fi prototype, they tended to focus on "fit and finish" issues. I've always known that early stage hi-fi prototypes take unnecessary time to make and take a long time to change, but didn't realize they could actually be worse in certain aspects. But after thinking about it, I agree with the author that in some situations, a high fidelity prototype could actually cause you to get worse feedback (relating to colors, styles, etc and not the general layout). A lo-fi prototype helps the reviewers focus on what really matters.
Alex LaFroscia 23:53:33 2/1/2016
One thing that I think the author overlooked is the amount of time required for the process of paper prototyping. I'm sure that in larger companies that already have design practices, time is allocated for these kinds of trials and tests with users. However, in my experience with startups and small companies that are strapped for manpower and time, it's not realistic to think that we'll spend hours or days cutting up and arranging pieces of paper in the hopes that we can convince one of our customers to sit with us and "play computer". I suppose it wasn't he point of this particular article, but I would have loved if the author provided some suggestions that smaller teams with tighter restrictions can try to implement in order to improve their designs with less of an up-front cost.
Jason Naughton 0:06:00 2/2/2016
At my internship with PayPal over the summer we were building a user-facing app from scratch. I got to sit in with the UX lead on my team during her user sessions. She used the "lo-fi" paper app technique described in the readings. I have to admit that I was doubtful that the exercise would be helpful, but the users' actually did find a few glitches in our original design. I think the points in the reading about the lost cost of time and money making lo-fi prototyping a good immediate gauge are true, but I'd even add that representing the design in something other than software is useful, as it gives an added dimension of the hierarchy of the design and use.
Arjun Mukherjee 0:13:27 2/2/2016
I actually learned briefly about the benefits of paper prototyping in my Software Engineering class I took last semester. I did think the in-depth analysis of lo-fi prototyping and it's effect during the initial phases of the software development process was interesting to read. I could see lo-fi prototypes being of assistance while designing UI interfaces for upcoming projects, because it will cut down the time i spend coding because I wont code any elements that I later find out that I don't need.
Chris Finestone 1:08:56 2/2/2016
I like the idea of prototyping that way, but I think the way the article presented it is a little archaic. I think modern development allows for much more flexibility in the interface design stages. It doesn't need to get sorted out as early, because the project is still growing and evolving. It's best not to set anything in stone, so solidifying a UI at the beginning of a project may be a bad idea since many aspects may change, necessitating the change of the UI.
Sarah Dubnik 2:14:17 2/2/2016
Like previous readings, I thought this one brought up a lot of interesting advice for things I had never had to consider before. I never saw software development as a process as physical as was described for lo-fi prototyping - buying art/office supplies, moving pieces around, etc. But it makes sense because the more physical process will probably stir up more ideas (similar to our brainstorming reading and lecture). Of course even more importantly is the idea of being able to revise quickly. The software developer's dilemma is a very good point: it's hard to test something without having a working model, but the model needs to be tested in order to work. It also makes sense that developers do not want to change their prototype after putting so much time and effort into them. In addition to the distractions afforded by software prototypes (font, colors, etc.), I can see these things being serious hindrances to the process. I am sure we can utilize this lo-fi prototyping in designing our interface for the project.
Adhyaksa Pribadi 2:24:33 2/2/2016
This paper advocates for lo-fi prototyping and describes the process of creating, testing, and improving upon a prototype. Lo-fi prototyping works because it effectively educates developers to have a concern for usability and formative evaluation, and because it maximizes the number of times you get to refine your design before you must commit to code. Advice for building a lo-fi prototype: Have arts&crafts supplies, Set a deadline, Make models with 'moving parts' to simulate interactivity
Xinhai Xu 3:00:58 2/2/2016
Lo-Fi prototyping is is characterized by a quick and easy translation of high-level design concepts into tangible and testable artifacts. Lo-Fi prototyping is preferred over Hi-Fi prototyping because of its extremely low cost in aspects of time and money.
Dustin Chlystek 3:15:54 2/2/2016
i wish the author (or publisher) would have used lo-fi on this reading and made it two columns instead of three. The reading itself was good. I was surprised to read that many people don't use a lower prototype first before an almost finished product. I always thought they did a lo-fi model first and a hi-fi model at the end of development to test the users.
Luke 6:25:34 2/2/2016
I found the idea of low-fi and hi-fi to be kinda familiar. To me in previous classes we talked about ideas such as scrum waterfall and agile to create and design programs. low-fi sounded like an agile way of doing the project by getting as many examples of your project to your user.Hi-fi on the otherhand seems almost like waterfall, where you are given all the requirements and then build it, but does not give a lot of time at the end for any needed changes.
Alexandra Krongel 6:56:40 2/2/2016
Even in the introduction, I very much recognized the pattern of user feedback I have gotten when I have just asked friends or family members how I could improve my websites or applications. Probably the eeriest callback is background color being good or bad. Our team has already completed the second group assignment using a paper prototype and playing computer, so I came into this reading already having accepted the main thesis; the users came with unique problems that we did not anticipate and tried to use the application in novel ways, even though we gave them an app store-sized spiel about what the application was supposed to be for. The author's point about how lo-fi prototypes shift the conversation from non-functional, pure design elements to overall elements key to workflow also very much seemed true from our experience. I would like to apply this in the class I teach. Right now, we have a forum with current and previous students where we all go to ask questions and get feedback, and since the prototypes are all hi-fi, most of the feedback seems to be on smaller design details or total overhauls the students are probably unlikely to fix within a semester. Asking students to present their ideas early on to students outside the course through this paper prototype idea would improve the quality of feedback.
Ishvaraus Davis 7:20:34 2/2/2016
The readings today were very informative, specifically in laying out why hi-fi prototyping is actually detrimental in some aspects. Most notably in the excessive time it takes rather than making lo-fi prototypes and quickly iterating through different designs. Our team is in the process of doing this and it seems much better than making hi-fi prototypes early on.
John Riesenberger 8:13:42 2/2/2016
Our reading consisted of the merits of utilizing lo-fi, or paper, prototypes for interfaces, and contrasted those merits with that of typical hi-fi prototyping. The article states that hi-fi prototypes are great for selling an idea, testing look-and-feel, detailed proof-of-concept, and testing changes to an existing, whereas lo-fi prototyping shines at demonstrating the behavior of interfaces at very early stages of development, while allowing fast and easy modifications and revisions. The author proceeds to outline a few steps to follow to achieve a productive lo-fi prototyping session.
Zane Hernandez 8:19:35 2/2/2016
Lo-fi prototyping seems like a good first step to designing an interface, but I'm a little confused. He is talking about software developers doing this prototyping, but shouldn't that be the job of a designer? I thought designers were the ones who create interfaces, and then software developers add the functionality.
David Fioravanti 8:34:11 2/2/2016
The reading made some interesting points concerning the advantages to using simple paper tools to develop interface prototypes as opposed to using software tools for designing the interface prototype. I do find that people tend to think a prototype is better because of the slickness of the design tool used which really has no bearing on the final result of the interface. In addition, the ability to quickly change a paper prototype is an advantage because there is less resistance than using a software tool. High quality software to develop prototypes are useful for demonstrating the interface for someone that you are trying to impress, because it is more presentation friendly. However, starting with a simple prototype for brainstorming purposes is the better way to come up with ideas due to the ability to change the prototype quickly.
Yijia Cui 8:34:51 2/2/2016
This article gives a great introduction to lo-fi, and made reasonable comparisons/criticism on hi-fi. Lo-fi involves interface design with drawing pictures instead of an elaborate prototype made by a software. It is better for lo-fi to use at the beginning of design is that lo-fi is easy, time-efficient, and low-cost to use. People spend a lot of time on designing hi-fi and it would be time-consuming, and as well as hard for them to make big changes. I am impressed by the iteration process inside lo-fi that people keeps drawing, modifying, testing with users until they have a satisfied design. Furthermore, this article introduces the basics for building a lo-fi prototype, including assembling a kit, setting a deadline, and constructing models. Also, the author talks about how to prepare and conduct a test. I learned a lot from this article. I am happy that for our group project, we use this lo-fi way to design our interface, but there is still a lot of room for us to improve.
Clark Nicolas 8:50:58 2/2/2016
I found the article's descriptions of the importance of lo-fi prototyping to be incredibly informative. The article did a good job of explaining how lo-fi prototyping can simplify design.