The Design Cycle and Brainstorming

From CS160 Spring 2013
Jump to: navigation, search



Reading Responses

Alice Huynh - 1/24/2013 20:18:17

1) The Lewis & Rieman design cycle just seems to be a more intricate description of the three stage cycle described in lecture. The three stage cycle described in lecture leaves more room for interpretation up to the designer of how to do the most important 3 aspects of designing a good software. The three stage cycle described in lecture focuses and hones in on the three biggest aspects necessary for adequate design.

2) In step 1 of the Lewis & Rieman design cycle states, "its hardware should fit in the space that users have available and look like it belongs there." Since a lot of Software is now built on the cloud this statement doesn't make much sense anymore. The "space" described in the sentence is more of a virtual space rather than a physical space.

Also in the mobile world the software is downloaded into an already existing hardware. This means that not all software comes with hardware in modern times.

3) This step is something that’s actually not recommended any longer. In modern times large companies like Apple or Microsoft thrive on finding the next best and biggest thing. In the plagiarize step they advise to "stick to what the user knows", but it’s companies like Apple that utilize brand new ideas that draw customers in. Customers are now attracted to new and innovative things.

Achal Dave - 1/24/2013 22:23:30

Lewis and Rieman's cycle seems to essentially expand out the three stage cycle we covered, except that it adds one step first: "understand".

Their first two steps fall into this broader "understand" step; the next four are essentially various stages of prototyping; and finally, we evaluate (and iterate) with the next few steps. The last steps are a mesh of evaluating, iterating, and finalizing.

While this article is rather old, it is very applicable to today's technology as well. For the most part, their process does hold for web applications, though the last few stages of "track" and "change" should be emphasized far more due to the nature of web applications, where it is very simple to change the interface for users.

Overall, I find Lewis and Riemann's approach very powerful. However, I disagree on two details. First, the article argues that in the "roughing out" of the design, only features which fit in with a task should be accepted. However, occasionally small features (such as the ability to play Snake on any Youtube video) are not justifiable directly from the purpose of the application (or the users' needs), yet it improves the users' view of the product. Such features should not be thrown out.

Second, the authors suggest that designers should spend some time on a customer hotline. While this is a novel and interesting idea, there are far better ways of seeing how people use a product. Since many customer complaints may be irrelevant to the interface, placing designers on a hotline may be a waste of time (relatively). Instead, especially with today's web applications, it may be more useful to find novel ways to track a users' flow through an application.

Overall, this approach is similar to the lecture's three stage cycle, and seems a very powerful method to designing a useful interface.

Sanchit Bareja - 1/25/2013 16:42:05

How does the Lewis & Rieman design cycle compare to the three stage (design, prototype, evaluate) cycle described in lecture?

The Lewis & Rieman(L&R) design cycle is pretty similar to the design, prototype and evaluate cycle discussed in lecture. However L&R is broken up into finer steps.

The design step encapsulates "Figuring out who's going to use the system" + "choosing representative tasks" +"rough out the design"+"think about it". The new aspect that L&R talked about is "plagiarizing". He recommends studying current systems which wasn't discussed in class. The prototype step covers "create a mock-up" and evaluate step covers "test it with users". Finally, "iterate" completes the cycle.

L&R goes further by describing "build it, track it and change it" which actually is similar to prototyping and evaluating but this time with the aim of actually building out the product completely. This is where L&R makes distinction from the theory discussed in class. From the theory discussed in class, building the product isn't a separate step but an integrated part of the process itself.

This article was written at a time when most software was sold "shrink-wrapped" in stores. Does their argument about the design process hold equally for web applications? If not, what has changed?

The design process holds for the most part of it. However, in developing web apps, we are constantly prototyping and testing it with users. As we do that, the product develops by itself further. There is no "extra" building phase. The process is more integrated where prototyping and testing our assumptions with users builds the product out along the way.

Where do you disagree with Lewis & Riemann? Why?

I disagree with the order of "plagiarize" and "rough out a design". I feel we should rough out a design first to remain original and then plagiarize. This way, we remain original and creative while not losing out to similar products.

Mia Kissick - 1/25/2013 17:18:31

Lewis & Rieman has 11 stages, while the last three is to build, track, and change the design. The iteration with users is done in stage 8. This differs from the three stages described in lecture where the evaluate/iteration stage is the last step in the design cycle and the evaluation itself goes back to stage 1. Lewis & Rieman also suggest to use User Interface Management System (UIMS) and other in the prototyping stage so that designers would have a almost working production going into the designing stage. However, the design cycle in lecture suggest rapid prototyping, using tools and simple as paper and pencil.

Since the article was written at a time when most software was sold "shrink-wrapped' in stores, their argument about the design process does not hold equally for web applications. In the SaaS time, softwares no longer represent themselves as physical products, but simply as a server on the web.

I disagree with Lewis & Riemann to put the build/track/change stages after evaluation. In today's world, designers and software engineers have much more accessibility to change the software through user feedback without much cost. This kind of flexibility suggest the last stage of the design cycle to always go back to the user/task analysis phase.

Colin Chang - 1/25/2013 19:34:12

How does the Lewis & Rieman design cycle compare to the three stage (design, prototype, evaluate) cycle described in lecture? They touched on the major points. For each step of the three-stage cycle there was an analogous point in L&R: Design: The lecture slides describe three associated tasks with this step: observing existing practices, scenario creation, creating models. L&R doesn't explicitly talk about observing (going out into the world), but it does talk about the importance of understanding the users and their background (in section 1.1) which, one can argue, has similar aspirations. Existing practices is touched upon in section 1.3, or at least, the sentiment to present the users with an interface they are accustomed to. Creating models really sounds like section 1.4, 1.5, and 1.2, more refining of ideas and initial prototyping. Prototype: Probably a mix of 1.4, 1.5, and 1.6. Want to try various levels of sophistication (starting as crude as hand-drawn improving eventually to balsamiq or an actual (albiet crude) implementation of the design). Evaluate: 1.7 and 1.8, testing and iterating seem to be the key ones here, which get a the same idea, that you want to make sure your design works!

This article was written at a time when most software was sold "shrink-wrapped" in stores. Does their argument about the design process hold equally for web applications? If not, what has changed? In this article, the iterating was happening before the release (exclusively). Since webapps are updatable "in-house" (meaning new updates can be pushed directly to the users), this iteration is likely happening continuously.

Where do you disagree with Lewis & Riemann? Why? I mostly agree with it. In light of the previous question, an easy answer is to say that it hasn't followed its own advice: 1.11 "No matter how well the product is initially designed to fit its task and users, it will probably be inadequate in a few years." (Of course, I understand that this article is held under completely different standards than production software, so ultimately, I'm joking). Jokes aside, with regards to the webapps question, I'd reiterate that continuous iteratation is more necessary now than at the time the article was written, so I disagree with L&R's omission of said iteration.

Kevin Huang - 1/25/2013 22:12:20

The Lewis & Rieman design cycle is almost identical to the three stage cycle that was described in lecture. It requires research and learning about the users and the need for the application. Then they both say to draw out a quick prototype on paper or using software and show them to users to get feedback. After that, go back and revise the design based on feedback and continue this process until customers are satisfied. One difference is that the L&R design cycle stresses selecting a specific task to begin the prototyping and building off of that.

In this day of age, there doesn't need to be that many cycles of perfecting the product before it is shipped to the customer. Software can often be deployed and feedback from users will then act as evaluation and suggestions for change for the next iteration. Software can be pushed out to the users constantly (following the agile development cycle).

I disagree with L&R about the iteration cycle and how it should stop. You should always be improving usability because it is forever adapting. It is easy to push software to users these days and you should take advantage of it.

Mukul Murthy - 1/26/2013 1:26:57

The Lewis and Rieman design cycle is essentially an expanded version of the three-stage cycle discussed in lecture. The first few steps involve researching and deciding on what features to include (design stage). The next few steps involve creating a prototype. After that, their next few steps involve testing and getting feedback on the design (evaluate stage). This whole cycle repeats as many times as necessary.

I think a lot of their arguments hold equally well for web applications and shrink-wrapped software from the store, but one of the major things that has changed is the ease of deploying updates. If a store-bought software was flawed or new features were released, often times someone would need to upgrade to a newer version. The "Think About It" step says "The cost of construction and the risk of failure are too high. Similarly, the costs of building a complete user interface and testing it with enough users to reveal all its major problems are unacceptably high." This isn't really true anymore; while it's obviously better to get things right the first time, it's simple enough now to deploy updates and new features that it's not the end of the world if something goes wrong. However, Lewis and Riemann's philosophy - that we should think designs through and make it as good as possible the first time - still holds.

One of the things I disagreed with was the previously mentioned point about it being unacceptable to make mistakes, although that has to do with the changing landscape in this field and the rise of software as a service. Another thing I found myself questioning was the plagiarize section, and how the article discussed the conflict between picking something efficient and picking something users are used to. I understand that it's easier for people to learn something new if it's similar to what they're used to, but using a flawed system instead of a better one simply propagates the problem. If there is a clearly superior way to do something, people will probably eventually have to learn it anyway.

Ryan Rho - 1/26/2013 17:09:32

Unlike the iterative cycle of design, prototype, evaluate process, the Lewis & Rieman design cycle also focuses on building and changing the software because at that time updating software was difficult. So, it has a cycle in the process but the last steps are more of getting out of the cycle to finalize the process.

Reflecting to the current trend of distributing software such as web applications and websites, some of the steps can be simplified because the software can be updated instantly by updating source code in the server. So, we don't have to spend more time in building, tracking, and changing. In addition, we could try AB test to know which user interface users want more. This can be easily done in a website because developers can update a feature in the website to certain users. As a result, the cost of building user interface can be reduced.

I generally believe the fact that "A system designed for Mac users should provide the generic Mac features that the users have come to expect" when it comes to a simple application. However, if it is a professional application or video game, I believe its developers can create its own user interface to enhance features in the application. In addition, a purpose of an application is to provide the program to as many users as possible across several platforms. In this case, its developers could implement a user interface suitable for several platforms.

In addition, I somewhat disagree to the statement that an application should stick to user interface that users are more familiar with even though it requires more keystrokes. Now that computer devices are more accessible to users, new paradigm of user interface is introduced and learned quicker than the past. For example, Twitter introduced pull-to-refresh. It does not take much time for users to learn these new features as long as they are intuitive and easy.

Tiffany Lee - 1/26/2013 18:01:12

The Lewis & Rieman design cycle is much more detailed than the one described in lecture and includes the whole lifecycle of creating an application from designing to building the application. The cycle in class seems to only be talking about the designing part of the lifecycle which is steps 1 through 8 in Lewis & Reiman. However, Lewis & Rieman's design cycle holds a similar paradigm to the one shown in class; both champion the idea of an iterative process in designing user interfaces.

All of the steps in Lewis & Rieman hold equally well for web applications. However, one thing that has changed is that it is easier for websites to gain feedback because user decisions can be logged real time via the internet. Therefore, getting user feedback is cheaper and less time-consuming.

One place that I disagree with Lewis & Rieman is their strong emphasis on plagiarizing. Although some ways of doing things are deeply ingrained in the average users' mind such as how to copy and paste, processes that are best not changed; innovation is also very important in user-interface design. Innovation is what improves applications and oftentimes if the innovation makes a great improvement to an existing paradigm, that would be an aspect that makes the application unique and attractive to users.

Soo Hyoung Cheong - 1/26/2013 21:13:06

The Lewis & Rieman design cycle is very similar to the three stage cycle described in lecture in a general sense of what it accomplishes. However, the Lewis & Rieman design cycle is much more detailed in that it contains a lot of steps that would be considered “sub-steps” for each stage in the cycle from lecture. Also there are two “cycles” in that one inner cycle for prototyping, and another for the whole process of designing.

I think Lewis & Rieman design cycle’s argument does not hold equally well for web applications. The main reasoning for this is that for “shrink-wrapped software,” it is necessary that the software is almost perfect before it is sold to the public; therefore it is crucial that more intensive iteration of prototyping is necessary. However, for web applications, the updates for improvement can be made continuously without the consumers needing to regularly make purchase for the updates, therefore, it is more fitting to just make sure nothing breaks in the software, and then just keep making changes or add features.

In step 10 “Track the Design,” I am not really sure whether having rotation for “temporary duty on the customer hotline” is necessary, since I think it is more efficient to just have a group of people, that are knowledgeable about the design, designated to such task so that they can assist customers, and also provide insights to the designers. I think the steps in Lewis & Rieman’s design cycle have too much of just “thinking out” things rather than actually implementing things and utilizing them.

Claire Tuna - 1/26/2013 22:17:19

The major difference between the two approaches is that the prototyping presented in lecture is “rapid”, whereas the prototyping in the Lewis and Rieman version is slower and more thoughtful. The latter emphasizes discussing the features in a team thoroughly before building any prototypes, due to the high cost of building. Some steps, such as counting keystrokes and mental operations or doing a cognitive walkthrough, fall after design and before prototyping in the Lewis and Rieman version, whereas in the lecture version these sorts of tasks would lie in the “evaluation” stage.

The initial development process described is applicable to web apps, but the mechanisms for feedback and upgrading are incompatible. In the case of shrink-wrap, one must regularly release upgrades to the software in order to keep up with new technologies. In the space of web applications, this translates to regularly updating the website, so that the updates are below the abstraction that the user sees. Also, a web app can track user's access patterns for real feedback in a way that shrink-wrapped software cannot.

The part of the reading I disagreed with was its suggestion that designers should copy from existing interfaces, even if they require extra keystrokes etc., because the users are accustomed to them. My opinion is that once the user has learned how to use the better version, he/she will notice the clunkiness of the old way. Yes, maybe the user will make some errors when transitioning between the two. But if a new way is never introduced, how can the norm advance?

Jian-Yang Liu - 1/26/2013 23:02:25

The Lewis & Rieman design cycle is actually quite similar to the three stage cycle described in lecture, though it has some more elements that help the design cycle to become more competent. Though the three stage cycle described in lecture may show this, the Lewis & Rieman design cycle is much clearer with respect to the design process, from having the designer determine who the users will be, to the tasks that the design should perform competently, as well as the idea that features that aren't for the tasks should be ignored, or have the list of tasks modified.

The argument about the design process doesn't hold as well for web applications, due to the fact that it is so much easier for applications to reach possible users using the web. Thus, the design process become even more important, requiring more ingenuity, simplicity, and/or completeness, so as for the application to prove itself from dozens of other similar designs.

The only problem I have with Lewis & Riemann is the part where they believe that features that don't support any of the tasks should generally be discarded. Though they may not make it into the final design, the features should still be kept when testing the design with users. Though designers themselves may believe some features to be unnecessary, it's impossible for them to know everything, and it should be up to the user as to whether features are superfluous or not.

Kevin Liang - 1/26/2013 23:02:57

I think the main process of the two cycles are generally very similar. It involves creating a mockup/prototype which is basically a rough draft. Later that gets tested with users and then the designer thinks about what needs to be changed. It is very important that the designer learns from the users.

Definitely still holds for web applications. Nobody gets the design right on the first try. If you compare the design of facebook back in 2006 and now, you can see how many times the UI changed. Another example is youtube. Now they are doing a TV-style layout when before it was more about a social layout. They are clearly experimenting with new things and needs to see what works and what doesn't.

I think Lewis & Riemann are wrong when it comes to their plagiarizing paragraph. While many apps copy each other, it doesn't mean that the UI is suitable for both apps. Sure maybe Facebook's header is nice, but just because you copy how Facebook's fixed header looks, doesn't mean it will work for your app as well. Some apps like Pinterest uses modals for uploads while others like Facebook doesn't. Perhaps modals work better for an app like pinterest because they may want you to keep your browser on the main page and reloads aren't necessary like it is for facebook.

Alvin Yuan - 1/26/2013 23:29:23

Both cycles follow a similar pattern: first gather insight into the users and scenarios of usage, then come up with a mock-up or prototype, analyze and evaluate it with and without actual test users, and repeat. Lewis & Rieman's (L & R) design cycle pays extra attention to their idea of representative tasks, to the point where discussion on features to include and analysis of design all happen within the context of how they relate to the representative tasks. The three stage cycle acknowledges tasks as an important factor but not as the driving force of the design. L & R's cycle also imposes a much clearer order of steps, having more steps that are more specific than the three stage cycle. L & R's order makes sense, but it is not clear if it is actually the best order in which to proceed.

Many of the large overarching ideas (such as understanding the user's needs and using existing interfaces to your advantage) still apply and probably will for a long time. Some ideas though have become outdated to some degree. With the advent of web applications and better development tools, the order in which the suggested steps should occur becomes looser. From my understanding, web apps can now (to a large degree) be analyzed and tested while up and running using tools such as Google Analytics. Thus, nowadays analysis and testing is less of a phase in the design process and more of a task that needs to be dealt with constantly. The ability to gather statistics while running and the ubiquity of software updates also loosens the need to follow a strict process to get design right the first time (not to downplay that aspect too much though as it is still important). Their idea of task-centered design, though still a solid idea, seems less critical nowadays in the sense that many applications large and small are available to accomplish the same important tasks; what separates one app from another may just as likely be its extra features as a small difference in usability to accomplish the important tasks.

I believe restricting the initial design to be on paper is unnecessary, especially with the tools we have now. I agree that if it takes more effort to produce an initial design, the designer is more likely to commit to certain decisions, but to say that the only way to avoid inappropriate effort is to do it by hand is too extreme. I also believe that user testing should happen with at least two types of users: the intended audience as mentioned by L & R, but also with people fairly new/inexperienced to the context of the application. Being attractive to curious shoppers is also important in addition to being attractive to people who know what they are looking for.

Yuliang Guan - 1/27/2013 0:39:46

Q 1: I think the Lewis & Riemann design cycle is generally similar with the three stage cycle described in our lecture. However, the Lewis & Riemann design cycle is more detailed which includes more specific steps, such as make a task and user analysis before design, think about the design after rough out process is finished, and tracking the design after building it. So it provides us a more clear guide about what to do step by step. In addition, the Lewis & Riemann design cycle emphasizes the importance of testing with users. In the design-prototype-evaluate design cycle, testing with real users is in the evaluating part. In other words, the user's need is considered after design and prototype process. However, in the Lewis & Riemann design cycle, the feedback from users is required through the whole process. Establish a good understanding of the users, rough out the design and discuss with the user, test the design with the user, build, track and change the design… All these processes are based on what the user needs. The communication with users runs through the entire process.

Q2: This article was written at a time when most software was sold "shrink-wrapped" in stores. Their argument about the design process largely apply to the design of web applications. No matter "shrink-wrapped" softwares or web applications, the aim of design is to serve the users and achieve the task. So I believe the task-centered design process is also suitable to web applications to some degree but not completely. For web applications, I think the biggest change is the way and frequency to update or upgrade the software. In other words, we can say it is easier for web applications to change the design. Designers can upgrade or make changes to the web applications all the time, so even a small problem in the application can be solved as soon as possible. This is what the "shrink-wrapped" softwares cannot make. Therefore, the "tacking the design" and "changing the design"for web applications are more often. Meanwhile, for web applications, the designers can get feedback from users in time. When a user finds a shortage of the web application, s/he can make a comment, and then the designer can revise it. In addition, the design of web applications need to give consideration to the server mainenance. And also, the design of "shrink-wrapped" softwares need to pay attention to different platform (like windows or Mac), but web application can cross platform.

Q3: Lewis & Riemann offers us a clear and detailed process of task-centered design. However, I do not agree with one of their opinions in this article. In the "figure out who's going to use the system to do what" section, they mentioned that the designer need to keep all generic features that the users have come to expect even though they play no important role in the system's main functionality. In my view, it depends. The designer needs to recognize whether the generic feature is useful or not. If it is useful, then it should definitely be kept and the users must be satisfied since they are quite familiar with this feature. Otherwise, it is not a good idea to keep the generic feature. If the designer choose to keep generic features without thinking about the advantages and disadvantages, the design will become meaningless. The purpose of a design is to bring people innovation and more convenience but not only to get good feedback from users (Indeed, although the users may feel unfamiliar with the new features at first, they will finally give good feedbacks later). Therefore, if the designer can create a better feature to replace the old one, it is better to encourage users to learn how to use it. People need to accept new things if they are better than old ones.

Emily Andrews - 1/27/2013 11:41:01

I think the Lewis & Rieman design cycle is very similar to the cycle described in class, but it goes in more depth. You see every point we discussed in class, but broken down into smaller, more specific steps.

The reading focuses on going through each iteration and then releasing. While for web applications, you can release things before a complete iteration is completed. For example, AB testing is used for web applications, which supports 2 versions of the same software at the same time. The Lewis & Reimann process doesn't seem to account for this.

At the end of the chapter, the authors mention that in order to track the progress of the design, they should put designers in contact with the users by putting them on "temporary duty on the customer hotline". This sounds beyond annoying. I think a nice, virtual suggestion box would suffice. Designers shouldn't be wasting their time listening to crazy customers on the phone.

Elise McCallum - 1/27/2013 12:17:28

The Lewis & Rieman design cycle has many small stages which can be grouped together to form a design cycle similar to the three stage one discussed in lecture. In the design stage, both cycles focus on task-centered design and developing feature based on user needs while incorporating existing practices and norms into the design. Both cycles also point to prototying as the second major phase of development, as it provides the opportunities for users to interact with the first version of the product and potentially diagnose major usability flaws. Lastly, both cycles emphasize evaluation by testing with users to see how effective the design is with the target group of users, and iterating back through the process to improve the existing interface.

The main changes in the design process from "shrink-wrapped" software to web applications are maintenance and scalability. While Lewis & Rieman leave open certain personalization features, they assume that the design and product will largely remain unchanged for a few years. For web applications, however, the period of time before an upgrade is needed is far shorter, as the technologies available make it so that daily deployment is a conceivable possibility. Web applications thus work on a much shorter time frame than "shrink-wrapped" software, with the design process moving more rapidly through each stage. Further, web applications can be deployed after a few iterations of the design process, as user feedback (performed by real users as opposed to test users) can be seamlessly incorporated into development by recording how long people spend using it, which features they use, which they don't etc. from a server standpoint. Web applications thus do not rely only on expressed user feedback but also on how they are actually used (usage statistics), which are easier to obtain from the web than from shrink-wrapped software.

I disagree with Lewis & Riemann when they articulate that the iterations should stop when all the "specific usability objectives" have been met. I believe that maintenance is crucial to design, as users in practice may not actually find the objectives to have been met and thus some features may need to be reworked/redesigned based on that feedback.

Joyce Liu - 1/27/2013 12:58:35

Both Lewis & Rieman’s and the Three-stage cycle focus on starting with the user. Both start out with task analysis and understanding the user. Lewis & Rieman also go into detail about incorporating elements from existing interfaces into your own systems as much as possible to make it easier for the user to use your product. The “Rough out the design” step in Lewis & Rieman asks the designer to write down a rough description of the design and the systems representative tasks. This is not explicitly mentioned in the three-stage cycle. Both design cycles advocate for rapid prototyping, whether on paper or with mockup tools but with no programming. Lewis & Rieman suggest to have a cognitive walkthrough before creating mockups, while the three-stage cycle would classify the cognitive walkthrough as part of the evaluation stage and the mockups as the prototype stage. Additionally, both cycles include evaluation with user testing as part of the cycle.

For the most part their argument about the design process holds equally for web applications. Web applications should also accomplish specific tasks, and task-analysis, incorporating existing interfaces that the user in familiar with, prototyping, testing, and iterating are still just as important. The last bit, 1.11 Chaning the Design, is still quite relevant for web applications, as technology is constantly evolving as well as society. What’s a bit outdated is that the article states, “the costs of building a complete user interface and testing it with enough users to reveal all its major problems are unacceptably high.” Today, however, that is simply not the case. It’s relatively easy to build a complete user interface and it does not cost ridiculous amounts of money.

I disagree with Lewis & Rieman that building a complete user interface and testing it with enough users has an unacceptably high cost in today’s world because web app development does not have high cost barriers or ramifications in today’s world. Nonetheless, I do agree in their process that one should rapid prototype test the design before completely building it. One should not go straight to building without first prototyping and testing.

Dennis Li - 1/27/2013 13:08:07

The Lewis & Reiman (L&R) design cycle is an elaborated form of the design, prototype, evaluate cycle. Each of the phases in the L&R cycle can be categorized into one of the 3 stages. The L&R method also includes the iterate phase which was step 4 in class (repeat until funding runs out)

I actually find it extremely surprising that this article was written so early in the technological era. I believe that the design process is perfectly viable for webapps. I feel that without all of these steps, designers would be lacking a key phase in the development and maintenance of their design. The only thing that might be different with web apps is that hardware limitions would be less of an issue.

I do agree with L&R. I believe that each step they are highlighting is necessary. Without all of these steps, I feel that the overall design and maintenance of a product would be significantly worse. I especially like the phase named "plagiarism". Despite it's ironic name, I believe that it is actually one of the most important steps in the development of a good design. It is the easiest and most efficient way to create an intuitive and complete interface

Shujing Zhang - 1/27/2013 13:11:03

1. Lewis and Rieman’s design process pretty much resembles the three stages version of design cycle, except that they elaborate each of the design steps into more specific details. I summarize them into corresponding three stages.

At design phase, UI designers are required to define problems, observe practices and create models. L & R also requires designers to figure out the type of users and what the software is supposed to be. They recommend choosing representative tasks to form preliminary models. At meantime, referencing to the existing interfaces (so-called plagiarize) is also recommended to save time and adapt to users’ using expectation.

At prototype phase, the three-stage procedure summarizes the three steps discussed in L&R. First, a rough design should be draw on paper, and walk through the process to ensure no functionality is left out. This step is supposed to be quick and dirty. Second, through observing users’ interaction with interface, we can improve the UI furthermore. Third, it’s time to build a concrete prototype with UI management systems, and test them against necessary tasks.

At evaluate phase, users, whose background resembles the target customers are asked to test the software and give feedbacks.

Finally, the software should go through several iterations until it met certain criteria or ready to go to the market.

Some of the points that design-prototype-evaluate cycle fails to include are that L&R places emphasis on the interaction between users and designers. The background of design teams should also be diverse and user-oriented. Also, in order to maintain an up-to-date product, you should react to the user feedback as well as changes in other products.

2. Lewis and Rieman’s design process pretty much resembles the three stages version of design cycle, except that they elaborate each of the design steps into more specific details. I summarize them into corresponding three stages.

At design phase, UI designers are required to define problems, observe practices and create models. L & R also requires designers to figure out the type of users and what the software is supposed to be. They recommend choosing representative tasks to form preliminary models. At meantime, referencing to the existing interfaces (so-called plagiarize) is also recommended to save time and adapt to users’ using expectation.

At prototype phase, the three-stage procedure summarizes the three steps discussed in L&R. First, a rough design should be draw on paper, and walk through the process to ensure no functionality is left out. This step is supposed to be quick and dirty. Second, through observing users’ interaction with interface, we can improve the UI furthermore. Third, it’s time to build a concrete prototype with UI management systems, and test them against necessary tasks.

At evaluate phase, users, whose background resembles the target customers are asked to test the software and give feedbacks.

Finally, the software should go through several iterations until it met certain criteria or ready to go to the market.

Some of the points that design-prototype-evaluate cycle fails to include are that L&R places emphasis on the interaction between users and designers. The background of design teams should also be diverse and user-oriented. Also, in order to maintain an up-to-date product, you should react to the user feedback as well as changes in other products.

3. I disagree L&R in terms of long iteration process before actually building the software. And L & R didn’t mention the testing during the process the software is being built. A lot of efforts are spent on sketching the prototype, which is a very good approach. However, I think a better approach would be to implement part by part and do the unit testing during the building stage. In this case, the product would be much tangible to the target user and eliminate the potential risk of deviating from the user’s expectation.

L &R placed a lot of emphasis on the design before building. If the designer were not dealing with “shrink-wrapped” software, it is also a good idea to release a Beta version to the public and gather information for update before release the final version. Personally, I think it is the best way to keep the version up-to-date, otherwise, it would bear too much risk once the product is sold.

Kate Gorman - 1/27/2013 14:08:45

Lewis & Rieman make explicit the process of "observing existing practices" in the 3 stage process and take it one step further by encouraging designers to adopt current conventions. This thinking allows designers to innovate where its needed and to not violate any pre-existing beliefs users have about how certain features, like spell check, should work given the current conventions in existing, widespread software utilized by the target user group. The notion of task centered design varies from the 3 step approach, because it not only creates scenarios of actual use, as the 3 step process suggests, but task centered design creates a focus for the entire design team and defines scope and MVP more clearly. By more clearly defining the MVP, goals, and scope of the project, it is more clear when the product is ready to ship and iteration can be stopped to release and observe the use of the product at scale.

The article was clearly written at a time of shrink-wrapped software. Their argument holds, but the key differences are that web apps allow for more rapid iteration, without a clear shipping date. The L&R article does not help current day designers look at their tasks, and prioritize their releases. Nowadays, in software instead of holding back a product's ship date until it is 100% complete, many phases and milestones will be set in place, features prioritized and then software developed and shipped in stages. While new features are being developed, data (qualitative and/or quantitative) can be collected and used to inform new features and set up a plan and prioritize improvements on the already shipped feature set. Also, the L&R article assumes that users are a very narrow and specific group of individuals, instead of the "designing for the masses" as many web apps are intended to do. The L&R article struck me as written more for the B2B software designer, because the process of asking your customers what features and functionality they desire then shipping in large pushes, rather than small and frequent incremental changes that are done in the web app world.

I disagree with L&R in a few instances: - In choosing representative tasks, I believe prioritization really must occur of the feature set. It is unrealistic to not have timelines by which a product must ship, and without prioritization of tasks and functionality, instead of leaving out of scoping down a less important feature, the whole product may slip its release date. - The iterate stage says "improve not prove" your ideas. I disagree with this. As a designer, you should be hypothesis driven in the way you innovate. I agree that gaining data and feedback is important to improving, but also observing behavior of existing users can create hypotheses for ways to improve. Without iterating or observing, you cannot prove your thinking was correct. Along this point, I believe A/B testing should be harnessed as to test multiple hypotheses and prove them correct. In web apps with a large user base, this is possible. However, for shrink-wrapped or small scale web apps this is not possible. - Testing premliminary designs and videotaping is great, but I think more realistically for web apps, have users interactions logged with counters and being able to observe behavior of all users is far better than having a few users utilize the software, which could introduce bias.

Zeeshan Javed - 1/27/2013 14:42:21

How does the Lewis & Rieman design cycle compare to the three stage (design, prototype, evaluate) cycle described in lecture?

The design cycle that Lewis and Rieman use and recommend is the “Task-Centered Design Process.” This design process carries a number of overlaps and differences that can be examined. The “Task-Centered Design Process” is structured around specific tasks that the user will want to accomplish with the system being developed. Therefore what’s always kept in mind from the designer’s point of view is how the customer will consider each individual task as a means to evaluating the success of software. While the Interface Design Cycle described in class has three key stages of design, prototype, and evaluate, the Task-Centered Design Cycle focuses on a much larger scope of techniques to consider including figuring out who's going to use the system to do what, choosing representative tasks for task-centered design, “plagiarizing,” roughing out a design, thinking about it, creating a mock-up or prototype, testing it with users, iterating, building, tracking, and changing over time. The Task-Centered Design Cycle does a much better job in maintaining a software’s design over a long period of time as well as has a keen focus on making sure the user can easily adapt to the features presented to the customer. It is however focused on software being released in versions in stores which has changed over time. The Interface Design Cycle does have similarities to the Task-Centered Design Cycle in that both cycles place a portion of their emphasis on designing, prototyping, and evaluating, however the Task-Centered Design Cycle overall does a better job in considering how the user will approach each and every task providing a safe means of satisfying the customer (ie “plagiarizing” proven systems that work and testing design cycles physically before creating multiple times).

This article was written at a time when most software was sold "shrink-wrapped" in stores. Does their argument about the design process hold equally for web applications? If not, what has changed?

Lewis & Riemann is their description of the design process emphasize that after one designs and builds their product, one must maintain of paradigm of tracking and changing the product after it is sold. The key thing that has changed is the pure volume of web applications available and the change in ease of being able to update software. In many ways the ideas of Task-Centered Design carries over to web applications, however the response time that a designer must “track” and “change” the product after release at a much faster pace than one would do with “shrink-wrapped” sold software. Due to the ease of access for web applications and the volume of web applications available to the typical customer, a designer must be able to adapt and a much faster response time than the “every few years” described in the article. Design changes must be more easily iterable in web applications than in those sold in stores to survive.

Where do you disagree with Lewis & Riemann? Why?

The one aspect of Lewis & Riemann’s cycle that I would partially disagree and be extremely cautious over is the idea of “plagiarizing” and using existing interfaces as a means of making one’s own. Not in the sense that “copying” things that work is bad. My caution stems from the idea that customers who approach software that feels “too familiar” may find this particular software a copy or a lesser version of the one they are already used to (even if the new software is superior). Customers and users have a difficult time branching out and trying new software especially in fields where there is already one predominant one already. And if the designer makes many of the features too similar it will be difficult for many users to find a reason to stick with it especially if the “new” and “superior” features added don’t readily stick out in a noticeable and significant way. However, I do agree overall with the idea of “Task-Centered Design” in that I feel the practice of building and changing to adapt is a necessary one as well as the idea of focusing on tasks.

Shaun Benjamin - 1/27/2013 15:47:14

The L&R task-centered design process is similar to the three stage cycle described in lecture, however the design and evaluate steps are broken down into a collection of smaller steps. It begins by evaluating who the users will be and what tasks they will need to perform with the app. After this, the design stage begins on paper, and is improved until a prototype is ready to be developed. The prototype is then evaluated for its usability and iterated and changed as necessary. The three stage cycle encapsulated many of the ideas described in the L&R process, but L&R do not present a clear cycle format to the design process.

Their design process is still relevant to web applications, and the end of the chapter that describes tracking and changing the design is perhaps the most relevant to keeping web applications current. Where "shrink-wrapped" software updates would have to be explicitly downloaded or purchased, web applications can be constantly updated and new versions can be released seamlessly.

The section on "plagiarizing" what the user is already used to certainly makes sense for a lot of applications, however constraining your application in such a way may make it difficult to think outside the box and come up with a creative user experience. This certainly depends on the application, but it would seem like a better idea to keep this as a possible way to design rather than a crucial interface design principle.

Avneesh Kohli - 1/27/2013 16:13:25

The design cycle described by Lewis and Rieman is in essence a more detailed, programmatic approach to the three-stage cycle described in lecture, but at its core represents the same principles of user-centered design. Both processes encourage task analysis, prototyping, and feedback-based iterations. These approaches both closely resemble the agile development model, and seemingly work very well for modern day design projects. Some of the details missing from the three stage process discussed in class include thoughts on design paradigms, particularly whether using a traditional paradigm or inventing a new one is appropriate. The emphasis on looking at past designs and on encouraging consistency is very apparent in the design cycle described by Lewis and Rieman, which are not indicated in the three stage approach.

Overall, I think the design process described by Lewis and Rieman is very similar to the agile development process being practiced by a number of startups working on web applications. The agile process lends itself to working on a short list of specific features, testing them with users, and then iterating on them to improve the application based on the feedback they get. While the processes are quite similar though, the execution is a bit different due to the increased number of tools that designers and developers have available to them today. One key example is how Lewis and Rieman described that designers need to constantly stay in touch with users in order to track the success of the design. Back then, designers had to make a concerted effort to stay in touch with users and continue to get feedback from them, whereas today, designers can work with developers to instrument the web application to automatically garner statistics from application usage that will give them the same feedback (though instrumentation never completely replace actually talking to the user).

One area I disagree with Lewis and Rieman is in the “plagiarism” section where they discuss relying heavily on existing interfaces. They make valid points, particularly on trying to make intefaces that are consistent and familiar to the user. However, I think encouraging a tendency to immediately emulate past design paradigms can be dangerous in that it slows down the eventual evolution of interfaces. As we progress into an age where humans are increasingly computer literate and more naturally able to figure new technology out, I think that taking some risks in trying to innovate on interfaces rather than always sticking with a “tried and true” interface will allow the field to move forward. Especially as new forms of user input make their way into computing devices, as touch and voice have recently, designers will be forced to challenge the status quo, and not rely simply on what they know to be natural for users.

Brent Batas - 1/27/2013 16:53:55

1) The two are similar. Both involve getting to know the users as people to figure out what the system should actually *do*. Then the next step is to create a rough prototype, test that prototype with real users, and after gathering feedback, repeat the process until ready to move on. Finally, both cycles encourage the practice of having many different kinds of people contribute to the interface, rather than just an interface specialist.

2) This article is surprisingly modern, considering its time. The authors’ arguments about rapid prototyping and testing still apply to web applications. The article’s description of “revisions” is a bit antiquated though. Shrink-wrapped software cannot be upgraded in real-time, whereas web applications can be. Also, with web applications, you can be sure that everyone is running the same version, but this is not the case with shrink-wrapped software. The authors say that even a well-designed product will be “probably inadequate in a few years,” but with webapps this is not the case, due to the aforementioned differences in pushing new code to users. With webapps, you can do AB testing to run tests on a live product.

3) Lewis & Reimann make the comment that “interface design hasn’t yet reached the level of sophistication of aircraft engineering,” but I think that might no longer be true. There are a lot of resources for interface design on the web, and there are classes such as CS160 and CS169 that teach these principles. Other than that, I mostly agree with the article. I do prefer user stories over tasks though—so in addition to coming up with a list of things users should be able to do, also come up with a reason why the user would want to do that task.

Jeffery Butler - 1/27/2013 17:42:58

1) The design, prototype, and evaluate is very flexible but less thorough approach compared to the Lewis and Riemann design approach. The L&R design approach has a long series of steps that consists of constant user-developer interaction. The development can be communicated through paper draw mock ups or through the actual coded app. By the end of the development process the developers have a fair understanding of what kind of expectations the user has for the task. However, the L&S purposefully does not deviate from the current market in order to provide the user with familiarity. Concluding, the L&R spends a large portion of its time focusing on the design in the intangible form and attempts to make a familiar product that accomplishes a task in need of a solution. On the other hand, the design, prototype, evaluate approach focuses less on the exact user expectations but rather 1. Design: What is the problem and how can developers solve these problems 2. Prototype: Getting a proposal/draft together to get answers to the developer’s questions. 3. Evaluation: deciding whether the answers are worth incorporating into the app. From these three phases the developer will have assembled a product that is designed to meet a specific purpose. Once launched, the developers will redesign their product based on the desires of their current market. Thus, more emphasis is placed on building a fast working prototype and seeing user’s reaction rather than anticipating user reactions, building the actual product, and improving upon the product once the product is released launched. While the R&S approach is more applicable to in store marketing the design by its emphasis on the beginning stages of the development while the design prototype, evaluate approach adapts to the constant changes in the user’s demand.

2) Applications are developed in a very specific fashion while store commodities can shrink wrap their products to provide the consumers familiarity and convenience. Due to the unique target audience preferences and concerns app developers cannot shrink wrap their products for their specific users. Because of the constant fluctuating expectations of app users, the Lewis and Riemann approach in particular lacks flexibility While the R&S does place emphasis on the initial design features of an app, the app can only have optimizations in the iterate phase. The design, prototype, evaluate approach is more appropriate in relation to the sacrifice for perfection in the exchange for quick development in juxtaposition to the R&S approach where the roots of an app are based off of the initial expectations of the users.

3) Even though the Lewis & Riemann approach does an excellent job of communicating with potential users, this approach is too slow in development. There's an enormous amount of time and effort placed in the initial stages. This process places enormous emphasis on the phases before the product is released thus making the root specifications in the app centered around the user’s initial expectations. When the app is released based off of these initial expectations, the released product will have a very difficult time adapting when the users sudden changes in their expectations. In addition I think their plagiarism phase does not work in all circumstances. A new user interface has the potential to appear to be more attractive than the previous version; therefore in the L&S approach when a developer mimic’s what is already on the market the developers fail to produce a new product that appears new hence better. ‘New’ in this case pertains to a characteristic that the user has not seen before.

Christina Hang - 1/27/2013 17:50:36

Lewis' and Rieman's design cycle is similar to the three stage cycle described in lecture, because both are recursive processes with overlapping steps. Both cycles emphasize the constant need to interact with the users to gain insight into what the system should do and to receive feedback. Lewis' and Rieman's design cycle includes a plagiarize step, in which the designers should start with interfaces that users are familiar with and add features required for the system’s tasks. In both cycles, prototyping is used to evaluate the design as well as reveal any missing design components. Designers should use the feedback and iterate back to the design stage to modify and improve the system. However, while Lewis and Rieman say that iteration should stop when “specific usability objectives” are met, in lecture, it was said that the cycle should continue until there is no more time and money. On this point, I will have to disagree with Lewis and Rieman, because even if the design incorporates the necessary tasks, there may be room for further improvements that will enhance the system for the user. Thus I believe that the cycle should continue until resources have been maxed out just as it was discussed in lecture. As for web applications, Lewis’ and Rieman’s design process may not hold equally, because web applications are more easily updated than shrink-wrapped software. Although it is still important for the designers to realize what the users want and need in the application, I think that the time spent in the iterative process before putting the application on the web may not be as necessary as with shrink-wrapped software. Maybe due to my lack in understanding the backend of web applications, but I think that since web applications can be easily updated on the user’s machine more often, then launching an application that’s been analytically tested and functions properly instead of a perfect application may be a better choice. Of course, in either case, the system should be tracked and upgraded as users give feedback on the design.

André Crabb - 1/27/2013 18:05:16

The L&R design cycle is very similar to the three stage process from lecture. They both are centered around the agile design strategy and focus on first designing, then prototyping, and finally evaluating and iterating the process over again until a successful design has emerged. I think its important how both procedures emphasize the necessity of doing all these steps before any code is written, although the UIMS of the development environment could be used for prototyping. Another point L&R make in their book is the post-process; tracking and changing the system after it has been tested plenty and even implemented.

I think the process described by L&R still holds even in today's world. The steps for designing a good UI have not changed, and that is what they outline. What might be different in development today are how quickly iterations happen. Especially for web applications, features can easily get pushed to users, and users can quickly and easily provide feedback to system owners.

I have not really had significant design experience where I tried to follow a set system, so I can't really see where L&R's system might not work. In general, I agree with their steps, and I believe that if they are each taken seriously by all parties of a software development team, with proper management, then the resulting product will be very successful from a UI/UX perspective.

I am interested in seeing how these steps play out during the course of the semester, and gathering evidence on the success of such a system.

Sumer Joshi - 1/27/2013 18:46:56

1. The three stage cycle of design, prototyping and iteration is a pretty basic rundown of the life cycle of a product. The Lewis & Rieman design cycle compares with a very direct and keen ability to prepare the reader with basic examples of situations and to look out for common pitfalls. The design process from lecture tells us to recreate scenarios that are usable by observing situations and create a model based on those situations. Lewis & Rieman gives similar statement, but also gives added pointers that I found useful. For example, the section "Plagiarize" talks about incorporating ideas that have already been used before into a system that is being created, but also improving that system as much as possible. The article has a good question for the designer: Should he or she use existing convention of a system that already exists or create a new system of convention? I had not thought about this in depth, but its something to consider based on how comfortable the user is tailoring to a new system. The prototyping phase is very similar for both design processes. L & R offers more focus into not creating the design itself, but rather using visual representation or any form to convey ideas more clearly. In the "Thinking about it" section, L & R talks about indepth methods to collect user data, i.e GOMS Modeling. The evaluation phase for both has some differences but is more or less very similar. L & R forces the team to make the design and then be able to track it and change it depending on user feedback and testing, which it what the lecture slides say in very few words. L & R's more indepth commentary provides a better understanding of why its a circular evaluation process: because you may find surprises you had not envisioned.

2. Their argument does not change for web applications because the process will still work. You are going to inevitably figure out a need that will help a consumer, design a mockup of the website and then test it with user feedback. This user feedback will occur in the "beta" phase of the project because typically for web applications, you do not want to test the product after its released, but rather improve on it as much as possible with a small user test group before releasing the product.

3. I disagree with the L & R assessment of the waterfall model. Although L & R says that it is meant solely for software engineers, I think that designers could operate under the same paradigm, but also consistently test the product while in production even after the requirements phase. It would be a modified waterfall model, straying away from the prototypical model that we know.

Eun Sun (Annie) Shin - 1/27/2013 19:30:04

The Lewis & Rieman design cycle and the three stage cycle described in lecture have some similarities and differences. Both cycles observe existing practices, create mock-ups, and run tests with real users. The Lewis & Rieman design cycle consists of more steps that the three stage cycle lacks and thus goes into more specifics. Choosing representative tasks and closely paying attention to each of them throughout the cycle is one of the biggest differences--especially because it is the foundation for creating products according to the Lewis & Rieman design cycle.

Lewis & Rieman's argument about the design process could be used for web applications. However, some of the specific examples mentioned by them are obsolete--such as putting designers in contact with users by rotating designers into temporary duty on the customer hotline.

Lewis & Rieman mention that "testing should be done with people whose background knowledge and expectations approximate those of the system's real users." Although I agree that testing should be done with those people, I believe that more testing should be done with other types of people. Because products usually attract new users, it would be good to have people with little knowledge of similar systems to test the product so that the team could observe how quickly, easily, difficulty, or slowly new users learn to use it. As mentioned in lecture, the team should also have experts testing the system. Experts may find ways to more quickly break the product in ways, thus saving the team time.

Timothy Ko - 1/27/2013 19:31:40

The Lewis and Rieman design cycle is similar to the three stage cycle from lecture in that they both depend heavily on the interaction between the designers and the users, especially in the beginning. There are also iterations involved in both methods, which is helpful in continually modifying the application in order to meet the needs of the users. The difference between the two is that the the Lewis and Rieman cycle establishes specific tasks from the very start that the product must perform. These tasks are the measuring tool for determining whether the product is complete. Although a product from the three stage cycle obviously needs to produce primary tasks for their application, these tasks don’t necessarily have to be defined from the very beginning, and they may be changed later according to user feedback.

The process described in the article mostly holds well today, in particular the part of the process that emphasizes using multiple quick iterations to narrow down what the user wants in their application. One place it doesn’t hold well is in that it focuses a lot on the planning stages. This huge emphasis on thinking about what tasks the application should perform forces each cycle of the design process to be quite lengthy. This makes sense for “shrink-wrapped” software, since releasing multiple versions of this can be expensive. With web based applications, however, you can easily release multiple versions of your software at low cost. This does not mean that you spend less time planning, but rather less time per cycle. Ideally this would just allow you to go through more cycles of development, which would allow you to get more feedback from customers.

I disagree with the article on the notion of stopping iterations. The article explains that iterations should be used up to the point where you actually start building your application. I believe iterations should be used throughout the lifetime of the cycle. Testing, in particular, should always be conducted, even after the product is released.

Zach Burggraf - 1/27/2013 20:34:57

The L&R design cycle is just a more in-detail version of the 3-stage cycle as far as I see. For example, the design stage encompasses all of the first five stages of L&R (user analysis through think about it) and the evaluation stage encompasses the test and iterate stages in L&R. I'm not going to go into every connection but basically I feel it's really the same process, just a more specific instance of it.

Regarding web applications and even modern software and mobile "apps" this process can be made a little differently. Although it is true that actually coding an app to a release candidate is time consuming, it is still possible with the use of downloadable and server-side patches or upgrades to gather feedback live from users and fix problems they have with the interface. Where as when software was bought in stores, the production speed prevented this "live" testing and maintenance.

L&R claims that close personal contact between design team and the people who use a system is difficult to achieve. I disagree with this. In many cases, core users are passionate about the software they use and they want to make it better. This is very easy and many companies manage it with simple forums. Especially independent developers (take minecraft for example where the online community of players is extremely active and the developers actively read their feedback across the web). In many cases, the real problem might be too much feedback and how to determine who's concerns and ideas merit investing time into.

Tim Wu - 1/27/2013 20:36:27

The three stage design process described in lecture and Lewis and Rieman's design cycle are similar in that they have the same basic steps and tasks. Lewis and Rieman's cycle is seemingly more detailed than the one in lecture because it enumerates tasks as entire steps, where the lecture abstracts these additional steps into just three steps. Steps 1-2 in Lewis and Rieman correspond to the lecture step 1, steps 3-6 correspond to lecture step 2, and steps 7-11 correspond to step 3 and 4 of the lecture.

However, there are differences between the two design processes. This is probably a reflection of the fact that the article was written in a time where software was sold "shrink wrapped". I believe that their argument for steps 7-11 in the design process are different with web applications. What has changed is that it is now very simple to build the entire prototype and test the whole thing with users very quickly because you can deploy a web app at low cost in time and money. Lewis and Rieman assumed that you needed to test the design with users several times separately before actually building the design, which I think is not as efficient with the dawn of web applications.

I disagree with Lewis and Riemann on the issue that I mentioned above, namely that I think it is better to simply build the entire application and show it to users instead of building the design and iterating on the design separately. Doing so would require the development team to wait for the design, which would create a bottleneck in production. I think these bottlenecks can be eliminated by simply releasing the entire product out to users and asking for more holistic feedback through detailed surveys.

Samir Makhani - 1/27/2013 20:44:35

I believe the Lewis & Reiman design cycle is similar in some sense, but not entirely. For instance, there are a lot more detailed steps that can be similarly abstracted into the three state cycle described in lecture, but not necessarily in order. L & R’s steps (1-5) can be classified as the “design” step, step 6 and 9 is the second step of the three step cycle, steps 7 and 10 is the evaluate third step, and finally, 1.8 represents the cyclical nature of the three stage cycle. Although these steps are not necessarily in order, majority of the L & R design cycle steps can be incorporated within the three stage cycle. I don’t think the L & R design process does not imply a cyclical nature as the three stage cycle. Instead it makes “iterate” a step in the design process, which doesn’t make much sense to me. According to the three stage cycle, building the design can also be integrated into the prototype phase.

Question 2

No the design process does not necessarily equally hold for web applications, because at this time, software did not automatically update like web applications do today. The only way to update back then was to buy the newest model. SAAS allows for rapid update and changes to web applications, which allows for designers to quickly iterate and receive analytics based on live usage.

Where I disagree with Lewis & Reimann

I strongly believe Step 8, “Iterate”, and and Step 11, “Change the Design” can be placed in the same category. By iterating on the product based on user feedback, this could also lead to a design-change, which is entirely dependent on user needs. Thus, in my perspective, iterating could imply changing the design. The cycle is much more emphasized in the visual three-stage cycle, but that may be because it’s much easier to iterate and push out changes on web applications as opposed to “shrink-wrapped” software in stores.

Monica To - 1/27/2013 20:52:41

The design cycle that Lewis & Rieman describes in chapter 1 depicts very similar concepts as the three-stage cycle described in lecture. However, Lewis & Rieman's approach differs in many ways. One vastly different approach is the placement of the evaluation stage in the cycle. Lewis & Rieman vouch that evaluating your design early in the design cycle, before implementation, is crucially important. I found their argument to be quite agreeable. Evaluating the effectiveness of certain design decisions and critically analyzing details of the design before implementation would not only save money and resources, but it will also make the overall process simpler and more intuitive. The three stage cycle described in lecture encourages the designer to make rough mock-ups, create a minimal working prototype, evaluate the design, and re-iteration. In my opinion, evaluating the design after implementation seems hasty and inefficient. Working off early stage mock-ups will require the more than necessary programming and a lot of iteration. I certainly believe that, although this article was written in an earlier time, it still holds true. Initially after reading this article, I did not even notice how long ago it was written because I think the content is still applicable to today's applications. The concepts written in the article intuitively describe a reasonable approach to design. Web applications and mobile applications are still products that require user interfaces and because of that, I think the core of what Lewis & Rieman's design cycle still has a lot of usefulness and applicability. Overall, I agree with Lewis & Rieman's design cycle. However, in today's technology, the cost of producing applications with user interfaces is generally low-- for example, an everyday person could potentially pick up a book about programming and slowly learn to program a mobile application. And because of wide accessibility to the technology today, I think an extremely intricate design cycle like L & R's design cycle might not be the best choice for some parties. In the past, with "shrink-wrapped" software, cost of producing was high, so the quality and intricacy of the UI had to be absolutely perfect or close to it. In some sense, I do agree with L & R's design cycle, but perhaps not for all design cases.

Soyeon Kim (Summer) - 1/27/2013 20:57:49

The Design cycle of the Lewis & Rieman, the Task-Centered Design Process seems to be more detailed and expanded version of the three stage cycle. Though there is additional evaluating step in the middle of the L&R design (i.e. “1.5 Think about it”) before the prototype stage.

Whether the interface design goes for web applications or mobile app applications, the design process and cycles should remain persistent with very similar goals and principles. Nowadays, the prevalence of touch capacitor technology is not limited to smartphones, but widely expanded to tablets and tablet-PCs, so the user interface and user experience design seems to be less unique either its web application or mobile application compare to the past.

When I encountered one of the L&R design cycle, “Plagiarize”, I was surprised, though as I finished the reading, it made a lot more sense, however, despite the advantage of “plagiarism”, sometimes it could be very tricky to do so, and often it can be a very bad idea.

	Not too long ago, there was this popular trial, Apple v. Samsung, and the jury decided that Samsung devices infringed Apple’s software patents on the iOS UI, though the court decision became controversial. 

To me, what Samsung did was to follow this “Plagiarize” design step of the L & R design cycle; rather than creating a novel interaction paradigm with the high risk of failure, they followed existing interfaces for easier and more comfortable operations for the users. Now that lots of interfaces can be patented, maybe this particular step of the L & R design process can only minimally adapted. Also, a novel UI does not necessarily mean inconvenience and confusion; a well designed novel interface has a potential in bringing more convenience and efficiency to users.

Kimberly White - 1/27/2013 21:03:27

The Lewis & Rieman design cycle seems pretty similar to the one described in class, in that it still has iterations of design, prototype, and feedback. As opposed to looking at the interface overall though, it puts focus on individual tasks within the program, like the number of clicks required for the user to access a specific menu, or do an operation. It also makes a point of involving real users (or those who act and think as users) throughout the entire process, and not just during the evaluation of the interface.

In terms of web design, I think certain points of the design cycle become more important, while others play less of a role. Shrink-wrap software, once it's shipped doesn't have much opportunity for change, at least not until the next iteration of the software. On the web, shipping is simpler (in terms of uploading new code, rather than waiting for a manufacturer) and can be done more often. As such, it's important for shrink-wrapped software to be near perfect when the design cycle is finished. While it's still important for web-based applications to have a good interface, making changes can be done faster, and testing can be done (easier) across a large number of users. So, getting it completely right seems to apply more to shrink wrap software, while adaptability and flexibility appear a little more important for the web.

I don't really disagree with Lewis & Rieman on anything, the process is general enough that it should be applicable to most situations. It's hard to evaluate anything without trying to apply it, the same way a UI can't be evaluated without users trying it out. Until we try this design process, we don't know the pros and cons of it.

Elizabeth Hartoog - 1/27/2013 21:12:53

Instead of having a continuous cycle like the diagram shown in class. Lewis and Rieman (L&R) showcase design style of a soft 3 stage cycle followed by a more firm one. The rough out a design, think about it, create mock up, test with users and iterate is like a soft cycle similar to described in class. This is the one where you are evaluating on a prototype and you keep doing it until you think you have it right. However, L&R were writing this during a time where the internet was not used to push out updates. If you bought a piece of software, it was given as is until you bought the new piece of software. As a result, the "firm" part of the cycle where they describe build it, track it, change it. Once it has been built, there is already a huge investment in the design and it is difficult to push minor changes to the userbase, so they have to get it completely right on launch day.

Web applications on the other hand do not necessarily and often do not need to get it 100% right. In fact, user input is extremely important to getting it right, and the best way to get large amounts of feedback is through actual deployment with more users. For example, Pandora wasn't 100% perfect when it was first deployed several years ago, but they are constantly changing the web app and responding to user feedback... working the 3 stage cycle. Pandora didn't need to reach the usability requirements in the iteration stage because they could always come back and deploy new features in the future very seamlessly.

This means developers can adapt the product gradually as user expectations change instead of providing major upgrades every couple of years. Thus it is more logical to use the 3 stage cycle on a web app where you can design, deploy, and evaluate it with added feedback from a large customer base.

One thing I'm not sure I agree with L&R about is how they structured the think about it stage. They said that you should mentally work through an idea on paper which is obviously very important. But working with paper doesn't necessarily bring up all the problems that actual program and prototyping might bring up. For example on the android, maybe some gesture combination you thought was fine ends up being difficult or the phone misinterprets it often but you wouldn't know that on the paper side because well.. it's paper. Prototyping on a physical system before sending it out to users is only common sense, and is likely much more applicable since we are working on the android platform. I feel like that wasn't properly emphasized in that portion of the instructions.

Linda Cai - 1/27/2013 21:42:53

The Lewis & Rieman (L&R) design cycle is very similar to the three stage cycle described in lecture, and many steps in the L&R design cycle correspond to one of the stages in the three stage cycle. Task and user analysis is included in the design step, except there is more emphasis on understanding users’ background. Both find representative scenarios or tasks for which the design will likely be used, and create rough designs and models before creating the mock-up design. Likewise, both suggest building mock-up designs on paper or other mediums. As expected, the suggested ways to do so were different, appropriate to the type of software (general shrink-wrapped software vs. digital, mobile applications). The L&R design cycle doesn’t suggest evaluating the near-final design without users, but both cycles suggest testing with real target users. Also, the L&R takes into consideration issues with the final released design and updates throughout the lifetime of the design, while the three stage design cycle does not mention such.

For web applications, it is much easier to push and get users to apply updates to their software, whereas for older, usually shrink-wrapped software, it was not easy to update regularly. Thus, the iterate step (step 8 of L&R cycle) may require much fewer iterations and tracking the design is much easier. Much more of the design effort can be instead put into changing the design, since it is seamless and easy to work with real target users and apply updates very quickly to address real issues.

I disagree with the extent to which a design should plagiarize existing interfaces. Depending on the type of software one is creating, it generally seems better to choose efficient interactions that work best within the program you are creating, rather than requiring unnecessary extra actions that serve little purpose. While the convention may be well known, the interaction may be highly inefficient or simply tedious and redundant in the new design, and so simply accepting previous conventions may not be worth it. The design’s new interaction style may even create new widely accepted conventions, especially if the software adopted on a large-scale basis.

Winston Hsu - 1/27/2013 21:44:39

The Lewis & Reiman design cycle seems to follow the design prototype & evaluate cycle fairly similarly, they just expand a bit more on what to do in each step. I think some of their ideas still hold true for modern web applications, however I would disagree with the extent of their focus on representative tasks. Its seems like concentrating on getting only a certain set of tasks done might encourage designers to produce wizard-like interfaces. There are likely to be cases where it is more intuitive to create a good paradigm for the user to understand the data they are manipulating, rather than focusing just on a few tasks that the user may want to complete. It may not be possible for the UI designer to imagine every possible task that a user would want to accomplish with the software.

Minhaj Khan - 1/27/2013 22:15:40

i feel that the lewis and rieman design cycle is similar to the three stage cycle discussed in lecture. this is because both cycles have an iterative quality by which the interface is further improved, assuming that the "evaluate" in the three stage cycle gives rise to further improvement to the interface. in both cycles, there is an initial design planning and a paper prototyping which is then used for feedback for its visual and functional qualities. overall, the two cycle frameworks have similar stages.

i feel their their argument about the design process holds well for web applications, with few exceptions. their design process of evaluating with feedback loops and real users is very similar to how web applications are developed, often having a feedback button built in right in the online application. the exception, or difference, would be that web applications can usually be pushed out to production more quickly and with less constraints because they can be iteratively improved as the users continue to use the application in the real world, especially with beta releases.

one place where i would question their methodology is when they argue that if you find a better method of achieving a result, its better to stick with convention rather than innovate your own solution. although i understand the reasoning behind this idea, which is to keep familiarity in interfaces over anything else, i do still think that innovation through occasional trial and error could produce overall better and transformational results.

Aarthi Ravi - 1/27/2013 22:50:45

1) The three stage cycle described in class is a more generic version of Lewis and Rieman's design cycle. The L & R design cycle provide a deeper understanding for each stage thus providing clarity on what could be done in each of the designing, prototyping and evaluating phases. Both the models emphasize that a good design can be achieved only through an iterative process with constant feedback from users.

2) In my opinion, the design process by L&R does not hold true equally for web applications due to the following reasons: -> Web based applications suffer from the curse of bandwidth limitations. The design, besides providing the complete functionality, must also provide sufficient user feedback especially when there is lower bandwidth so that users don't get frustrated and quit the application. L&R only focuses on usability and feedback but doesn't focus on latency issues as these don't exist for shrink wrapped software. -> Testing web applications for scalability is very important and this has not been taken care of in the L&R cycle -> The design should not only be task-centric but also should be engaging and self explanatory with a lot of help so that users don't switch to other applications.

3) L&R suggest that it is a good practice to stick to the conventions of the existing applications to make it easier for the user even if it involves more keystrokes. I strongly disagree with this stage as I believe in order to provide a better user experience designers should first reduce the keystrokes and the work that needs to be performed by the users.

Cong Chen - 1/27/2013 22:53:39

The Lewis & Rieman design cycle is similar to the three stage cycle described in lecture; you can see the three stages among the 11 steps they outline. In my opinion, you can group them.

Figure out who's going to use the system to do what, choose representative tasks for task-centered design, plagiarize into the design stage

Rough out a design Think about it, Create a mock-up or prototype, into the prototype stage

Test it with users, Iterate, Track it, Change it into the evaluate stage.

For the first 3 steps, they capture the idea of designing the user interface as you have to analyze your users, tasks, and the overall structure of the design from previous successful UI's. The next few steps capture the idea of prototyping and getting a simple version of the UI working. Finally, you need to test it with users and learn from them to evaluate the success of your UI and then, you need to iterate, which in the 3-stage process is simply starting over.

However, Lewis & Riemann's 11 step outline differs to the 3-stage in that improving the UI from the user (iterating) is a simple step that does not include all the other steps such as analyze, plan, mock-up, etc. This, I feel, is probably a more accurate portrayal of what will happen when you iterate as each time you get feedback from the user for a computer software (not web application), you probably will not have to start all over again from analyzing from the base up. However, an 11 step outline is much harder to remember than a simple 3-stage cycle. Thus, I think the 3-stage cycle is more practical for designers to remember when designing UIs.

There argument does not hold equally when applied to web applications. Lewis & Riemann argues that after you make the initial product, you should try to avoid making drastic changes to it in iterations. I do not think this applies to web applications. Web applications differ from "shrink-wrapped" software like word processors or spreadsheets. They differ in that web technology changes much faster than general software technology, whether it be in languages or web frameworks. Thus, to keep a web application up to date and satisfied with the users, I believe it is necessary to constantly need to update the design and maybe even change it. For instance, Facebook changes the user profile layout every so often despite people's protests as it helps Facebook stay novel and up to date with the newest web technology.

I disagree with Lewis & Riemann on their "plagiarize" step. They argue that when designing a new UI, you should follow previous successful ones as it is the "safest" way to design a new UI. Yes, it is true that you save a lot of work when designing a new UI by basing it off our previous successful UI's, but this kind of mindset is wrong and will lead society nowhere. Today, technology is booming because people try different UI's, different approaches, and different ideas. UI designing should follow in suit. By trying new UI approaches, you will be able to discover news ways that may be much better ways for user interaction never thought of before. This is what leads to true success in our world, like Google, Apple, and Microsoft. They create new UI interfaces and ways that have changed people's lives.

It is true that there are a lot of risks and may turn out unsuccessful when not basing UI's from previous successful ones, but this is why we have user feedback and iteration cycles. Plus, designing a prototype and testing it with users should not be a big hassle; it should not be a deterrent from being creative. This is where the 3-stage cycle comes in. You design, prototype, evaluate, and if it's a complete failure, you start over with the previous feedback.

Brian L. Chang - 1/27/2013 22:54:34

The L&R (Lewis & Rieman) design cycle is very similar to the design, prototype, and evaluate cycle from lecture. Both cycles have a time to design, prototype/mock-up and evaluate/test with users phases. The L&R cycle continues on to say that this is not enough and that you but iterate on this, track your work and change based on new/unmet needs.

Much of this is same. This task-orientated design was created as a solution to the waterfall design which has been proven a poor approach for software with an important UI component. I think one thing that L&R hits on the spot is the call to change the design. Never stop iterating because when you do, your program gets old and might not meet the needs of your users anymore.

I disagree with L&R when it comes to testing with users. I think that with the web and mobile platforms people can constantly iterate and so rather than spending time videotaping users, I think its better to just release a basic but complete version and then improve from there. When your app gains more popularity it might then be more useful to spend time videotaping users.

Si Hyun Park - 1/27/2013 22:59:15

Lewis & Rieman design cycle is surprisingly (given that it's written twenty years ago) similar to the three stage design cycle described in lecture. Task-centered design process starts by analyzing users' needs, and choose representative tasks for them. This is equivalent to design step described in lecture, which involves task analysis and contextual inquiry. Once the designer completes the design step, he/she creates a prototype that accomplishes users' needs, or more explicitly the representative tasks defined. This is the prototype stage. Finally, there is the evaluation stage, where the designer evaluates the prototype, iterate, and ship the product. Even after the product has shipped, the designer continue to track and change the design if necessary.

I believe that although it has been twenty years since this article has been written, the design process still holds valid for web applications. Even though the technology has changed, the target audience for the technology is largely the same - the users. As such, we must first assess the users' needs first and foremost, then create a MVP (minimal viable product), and iteratively evaluate it to create the final product. If there was one thing that changed, however, is that the amount of time designing the prototype has decreased, replaced by far greater number of iterations. Since users' needs change quickly today, it is important to iterate more often to satisfy such changing needs.

Although I agree with most of the contents in this design cycle, I honestly disagree with the "prototype" cycle. I personally believe that there shouldn't be a difference between the "prototype" stage and the "build" stage. I believe that an application should be built to its highest quality as possible from the start, and iterate from there. Perhaps this is due to the fact that I come from web design background, where it doesn't take a while to create a full-fledged UI using CSS. It's difficult to test the user when you only have a half-baked product, which users will generally respond negatively. I think it's best to deliver the best possible product from the beginning, and build off from there.

Brian Wong - 1/27/2013 23:21:44

Both the Lewis & Rieman cycle and the three stage cycle from lecture follow a similar structure of ideation via observation and thought, prototyping with users, and changes based off of feedback. The three stage cycle, however, appears slightly more fluid and iterative, compared with the L&R cycle, due to a slightly greater emphasis on changes from user input. The L&R cycle starts with a heavy focus on the designer thinking of tasks and using natural instinct to build out prototypes. The three stage cycle, however, will often be based off of use cases from users, and iterating based off of user iterations with the model rather than designer thought-out tasks.

The general idea of the L&R cycle still holds, however there is a huge change that has occurred with web applications, and that is the ability for immediate and strong feedback from users, as well as the ability for quick changes by a designer and programmer. Essentially, the whole process has been sped up dramatically, which means one must rely on user feedback more-so for ideas for change since there is less time between releases. For example, the moment a user visits a web application, they can tweet about it, post about it on facebook, and send the developer feedback via email. The designer and developer can then gather all this immediate feedback and make quick changes that can pushed instantly to the web.

I believe one step that has probably changed the most is the third step: plagiarize. While it may have been true in the past that sticking to the norm is a good idea, today bold and new ideas are what help many designs stand out. For example, Facebook is constantly changing their layout and design structure, and while they always receive some flack at first, eventually nearly everyone doesn't even remember the previous design. Another example is the major change from Android 2.3 to 4.0 in terms of UI. The entire menu button at the bottom of phones suddenly became useless as Google took the bold move of completely removing the bottom 'hidden' menu in place of a visible menu bar.

Jonathan Lin - 1/27/2013 23:37:58

1. The Lewis & Rieman design cycle essentially is a more detailed version of the three stage cycle described in lecture. Steps 1.1 through 1.5 are part of the design phase and describe steps to take when beginning to design a product. Step 1.6 is a prototyping phase and step 1.7 is the evaluation for the beginning of a design. Step 1.8, or the iteration phase, comprises many design-prototype-evaluate cycles, and after that step, the product is ready to be built, which is step 1.9. Steps 1.10 and 1.11 also comprise many design-prototype-evaluate cycles, but apply to a released product that needs to be improved in time. Although these eleven steps can be reduced to multiple iterations and versions of the three stage cycle, it is often useful to know or have a reminder of the details of each of the three steps and what actions pertain to them at each stage of product development.

2. The argument about the design process holds equally, if not more, for web applications as well as shrink-wrapped software. The major difference between the two types of software is ease of deployment, which has many implications, including that web applications are often cheaper and there are many web applications that have the same or similar functionality. Having a detailed design process is critical because at every iteration, a potential update can be released, and a consistent design process is needed to produce these constant updates to keep up with potential competing applications.

3. In general, I agree with Lewis & Reiman regarding the design process. However, I disagree with step 1.5 being a separate step by itself, even though the steps probably are not meant to be completely separate and have many overlapping parts. I think that "think about it" in terms of how it is described in step 1.5 should be something that is done throughout the entire process. For one of the examples given in the step, estimating the amount of time to perform each action, that should be done in step 1.3 while analyzing other existing interfaces, step 1.4 when drawing a design, and other steps while interacting with users and building a functional program. Because of the breadth of this step, I think that it should be given as a task to consider throughout the entire process.

Scott Stewart - 1/27/2013 23:48:19

The Lewis & Rieman design cycle is very similar to the three stage cycle. Both involve creating a design quickly, getting user feedback, adjusting the design, and then repeating the process. The main difference is that the process described by Lewis & Rieman includes steadily making more advanced mock-ups that steadily move towards a finished product. It seems more linear than a perpetual cycle of design, prototype, evaluate

The main thing that has changed from "shrink-wrapped" software to web applications is that with shrink-wrapped software, the product has to be finished at some point and shipped. The design process described by Lewis & Rieman is one step in creating the software, but once the user interface is designed, then it is done for that product. With web applications, deployment is much more dynamic. The user experience can be evaluated while the actual application is being used, and can then be changed at any time.

The main point that I disagree with Lewis & Rieman on is the "Plagiarize" section. They heavily advocate for using protocols that are similar to other programs, even in cases where a new standard would benefit the particular program being built. While I understand the benefit to providing what the user expects, new programs should also not be afraid of innovation or progress at the cost of a small learning curve. If every program was only designed to do what every other program did, nothing new would ever happen.

Christine Loh - 1/27/2013 23:51:53

The three stage cycle (design, prototype, evaluate) includes many of Lewis & Rieman's steps in each of its stages. For example, the design stage contains task analysis and contextual inquiry (as described in lecture), which can encompass at least the first two steps of L&R's design cycle. The third stage, evaluate, includes tracking the design and changing it -- also including more than one of L&R's stages.

Though the processes are very similar in this manner, they contrast in the freedom given to designers; L&R's design cycle is more formulaic, and includes steps that can be minimized or even removed in certain design processes, especially with web applications today such as Facebook (which rolls out weekly updates and does not necessarily follow L&R's rules precisely, or else the updates would take much longer than a week to complete). Since web applications can be updated if they are not perfect, it is no longer imperative for the design to be absolutely perfect before rolling it out to users; an application can be easily launched within the design phase if it's "good enough" -- this would minimize time wasted in L&R's "iterate" stage. After designers receive user feedback, they can go ahead and update the application accordingly.

I feel that L&R's design cycle can hold for web applications; however, it is no longer as effective and efficient for web apps as it was for shrink-wrapped software. Many of its attributes can be transferred to the web application world, such as designing software for different operating systems (which may be applied to different browsers as well). There are universal design options such as smooth merging into the user's environment and task analysis that will continue to be essential regardless of how technology changes. However, since the L&R cycle is so specific, it leaves less room for making the process different -- and I believe that each design process is unique depending on what it's for. As stated previously, though I do enjoy some aspects of L&R's design cycle, such as its specificity (compared to the three stage cycle, it feels much more productive to follow), I fear that it is too formulaic and does not allow for enough freedom in the design process.

David Seeto - 1/27/2013 23:55:11

Both the lecture and Lewis & Riemann's book advocates for similar design cycles with the lecture taking a much more general approach. The first step is to design the UI. In lecture, design is based on developing a design hypothesis through task analysis and contextual inquiry. In contrast, while still doing both task and user analysis, the reading's design phase is focused on developing representative tasks. This task-centric approach is more directed in focus, allowing for a very specific set of metrics to measure weather the UI is effective in allowing users to accomplish those tasks. In the other two stages, prototyping and evaluation, Lewis & Riemann offer similar structure, but they also offer various techniques such as building from existing interfaces and GOMS analysis. Although the 3 phases in lecture are broken up to fewer steps, the basic idea remains the same in the reading.

The rise of web applications changed the design process. For example, analytics are almost always built into web apps offering real time and in dept look at the effectiveness of changes in UI design. The widespread use of ruby on rails and other agile web application programming practices allow for close collaboration with users and the ability to respond to change quickly. Compared to "shrink-wrapped" software that followed cycles of design, user testing, redesign and finally shipping out, the agile web programming environment is inherently collaborative and iterative in the design process, even initially.

I disagree with Lewis & Riemann in choosing to plagiarize in interface design simply because it is "what users [already] know." While perhaps practical, plagiarizing does not always lead to good design. In fact, it impedes designers to truly see what might be better for users. Emphasis should be placed on finding why that particular design became popular with users and how to implement design choices basedon those reasons.

Tiffany Jianto - 1/27/2013 23:58:59

Question 1: There are only three stages of the design cycle in lecture—design, prototype, evaluate—while the Lewis & Riemann design cycle contains 11 steps total. While the steps basically go through the same process of designing, prototyping, and evaluating, there is more freedom in the three steps to fulfill each step in any way, while the Lewis & Riemann design is much more strict and specific, with detailed steps. For example, the prototyping step in lecture’s 3-step design consists of steps 4 (rough out a design), 5 (think about it), and 6 (create a mock-up or prototype) in Lewis & Riemann’s design. Also, the Lewis & Riemann design process is task-centered, while the 3-stage cycle does not explicitly declare that.

Question 2: One step that seemed to be a little outdated was step 7: Test the Design with Users. While I do think it’s important to test the design with users, Lewis & Riemann recommend asking users to perform specific tasks and then to videotape the tests and analyze those; I think with modern technology, there should be others ways to analyze users without physically videotaping and watching them work. For example, mouse tracking is a useful tool to collect user information about user patterns, and it outputs the same goal of this step without having to physically videotape and watch the user. This may also have been because the software was “shrink-wrapped,” but since software can be downloaded easily from a webpage, this is not a problem at all, and we could get a wider audience. Similarly, their way of tracking the design in step 10 also seems a little outdated; they want to put designers in contact with users by rotating them into temporary duty on the customer hotline, or using group meetings. However, I think there is a lot of customer feedback available on the web today so that it’s not necessary to physically meet but, similar to my response above, to track reactions through the internet and other tools. For example, all mobile applications today have ratings and reviews which would be helpful.

Question 3: The places I disagree with Lewis & Riemann are:

Step 4: Rough Out the Design - Lewis & Riemann say that the rough description of the design should be put on paper, but with the tools that we have nowadays, this isn’t necessary. We can design great pages without using paper but with software, as described in lecture.

Step 6: Create a Mock-Up or Prototype - Again, Lewis & Riemann want to create a paper mock-up, which I don’t think is necessary because of the software we have available.

Step 7: Test the Design with Users - Similar to my response in question 2, I think that this step is a little outdated because we don't need to physical videotape the tests and analyze them, but we can use software such as mouse tracking software to collect and analyze user information.

Step 9: Build the Design - I’m not sure if it’s because of my lack of experience and knowledge, but Lewis & Riemann think it’s best to use UIMS for prototyping, and I’m not sure why that would be more beneficial. UIMS strictly defines and enforces the boundaries between the business logic and the graphical user interface, and I think some overlap might be okay. I can definitely see the necessity to separate to an extent to test with variables and other parameters, but I’m not sure why separating it completely would be a better idea.

Step 10: Change the Design - Again, similar to my response in Question 2, I think that this may also be a little outdated because of the technology today that can easily collect feedback from consumers without physically having to meet.

Arvind Ramesh - 1/28/2013 0:12:30

The Lewis and Rieman design cycle is similar to the one described in class, with each stage being broken down into several sub-stages. For example, the design stage in class is equivalent to stages 1-5 in the L&R cycle, the prototype stage is equivalent to stage 6 in the L&R cycle, and the evaluate stage is equivalent to stages 7-9 in the L&R cycle. Lewis and Rieman have stages 10 and 11 as well, which come into effect after the product is launched, and these don’t really have an equivalent in the design cycle discussed in class, but are nonetheless very important for the continued success of a product. Overall, the most important thing I took out of the article was the idea of task-centered design. If left to myself, I would have always focused on the “waterfall” method mentioned at the bottom of the article and design a system based on certain requirements, without ever taking specific tasks into account. When designing future apps I will definitely try to look at things from a task-oriented perspective.

For the second part of the question, I do not think the article’s relevance has been diminished at all by the transition to web based applications. From the perspective of a user who needs to accomplish a certain task as efficiently as possible, it makes not difference if the software he or she uses is web-based or shrink-wrapped.

And for the final part of the prompt, my biggest disagreement with Lewis and Rieman is when they state “You might be able to create a novel interaction paradigm that's better suited to your application, but the risk of failure is high. An existing paradigm will be quicker and easier to implement because many of the design decisions (i.e., how cut and paste will work) have already been made.” I definitely see where they are coming from, but I think if you have a compelling reason to believe that you can make a new way of making a task more efficient, then you should still try it rather than sticking with what people are used to. Of course, at first your idea might not take off, but if it is a good idea and well thought-out, people will eventually see the value in it.

Bryan Pine - 1/28/2013 0:31:35

1. The main difference between the article's presentation and the cycle described in lecture is that the article presents a task-based approach while the lecture focused on the application as a whole. At the core, they basically hit the same concepts: talk with real end users to get ideas, make simple prototypes before investing time to develop an end product, and use several rounds of feedback from users to improve the product. However, the article suggests applying these concepts to specific identified tasks, and building up the application as essentially the sum of the features required to perform these tasks. The three stage cycle instead seems to first consider the application as a whole, and then build out the specific tasks that are necessary to implement the main purpose of the application.

 The article also presents a more concrete, linear approach to design, while the lecture cycle provides less structure (only indicating that design should come before prototyping, which should come before evaluation).  Because of this, the lecture cycle may be harder for designers to follow, but will ultimately be more flexible as a framework for considering a wide array of projects.

2. A key difference between web applications and store-bought software is that it is (relatively) easy to make changes to web applications. This doesn't change most of their fundamental points, like the need for constant input from end users or the importance of iteration and revision, but it does blur the lines between many of the steps in the process. For example, because it is easier to create, deploy, and update a web-based application, it might be useful to create a fully working prototype earlier than they suggest. With a working application, a design team would get more useful feedback and actually be able to observe their application in action, which can only help with the iteration process. I also think that the idea of an end goal product is no longer meaningful, since users expect web applications to change quickly in response to problems or opportunities. The article suggests separate monitoring and revising steps; today, these will need to be integrated to meet users' expectations.

3. I fundamentally disagree with the concept of design process "steps", especially in today's environment. It makes sense to take time to consider end users' needs before jumping in and designing a prototype, but I think that the step-based system risks pigeonholing the team into forgetting about the users once that "step" is done with. I believe (and I'm open to being proved wrong) that it is helpful to think about system design issues right up front, and even discuss them in general terms with users. For example, I think you can get useful information from users by asking them to do things like rank tasks in order of importance, considering factors like how much data the task might consume. I think that is information that could be missed with a rigid task-identification-based approach. In general, I just picture the process as a constant flow rather than a series of concrete steps.

 Also, I don't think the article stressed the importance of testing users in as near to a real use situation as possible.  I imagine it would be easy as a designer to accidentally influence your users' experience in a controlled testing environment, which could make it hard to identify issues that only come up when the user has no direction or doesn't even know what the product is.

Yong Hoon Lee - 1/28/2013 0:39:26

The design cycle described in the text is similar to the one described in lecture in several important ways. Most significantly, they both emphasize a user-driven design process, in that the process of building a user interface begins by observing and interviewing users on how they use data and "ends" by receiving the users' feedback and restarting the design process. This iterative nature of the design process is also a similarity between the two cycles, as both emphasize that the design of a UI is never really complete. The Lewis-Rieman cycle does differ from the cycle presented in lecture (hereafter known as the DPE cycle) in that it makes its steps much more numerous and granular. Roughly speaking, steps 1 through 3 in the Lewis-Rieman cycle correspond to the design step of the DPE cycle, steps 4 through 6 correspond to the prototyping stage, and steps 7 and 8 correspond to the evaluation stage. Furthermore, the Lewis-Rieman cycle appends further steps which correspond to the actual building of the software and the post-release cycle, while the DPE cycle embeds this into its three stages, with the prototyping stage being expanded to cover more forms of prototypes. The DPE cycle does not concern itself specifically with the actual design process, but broadly speaking, the actual design of the software could be taken as another prototyping step, and the cycle could still be used in that sense. The other significant change is that the Lewis-Rieman cycle places heavy emphasis on the tasks users perform, while the DPE cycle does not. Indeed, the Lewis-Rieman cycle takes as a philosophy that the design of the UI as well as the software's functionality should be informed by a list of tasks that the user could perform. The DPE cycle, on the other hand, is not as focused on a task list, and instead leaves the subject of exactly what information should be used to develop the program somewhat vague. However, in my opinion, the DPE cycle does not exclude using a task-based approach, and in fact is compatible with the Lewis-Rieman cycle. The first similarity that was noted above is ultimately the most important factor of the two cycles, and this congruence in philosophy contributes significantly to their overall similarity.

For the most part, the cycle that Lewis and Rieman describe do still hold, in that it is still prudent to focus on the user when developing a UI and do the necessary research before starting to develop. With web and mobile applications, it is still somewhat important to make sure that the interface is consistent with those users may have used in the past, but due to the relative flexibility of current user interfaces, I don't think that it is as hard as it was to innovate on an interface or improve on the old standard. For instance, many alarm clock applications do not have a consistent user interface in terms of how to create or set an alarm, but most are relatively intuitive and indicate their different functionalities in clear ways. Furthermore, because web applications do not have to be as large as boxed software was when the reading was written, the design process can be much shorter and can even be thought of as an extension of the prototyping process. Of course, with larger applications, the original steps could be applied, but for smaller programs, the user interface is actually the main part of the program, and an accordingly larger portion of the design and evaluation process can be focused on that aspect. In relation to the last point, namely changing the design, it is of course much easier to release new versions of a program currently than it was, so that a developer does not need to be as concerned with larger trends in relation to the program itself and its next iteration. Iterations are now much more routine, and while the advice given is still worthwhile in terms of a next major update, it is easier to improve on a user interface and respond to feedback in a timely manner. Finally, the value of a task-centered design process may not be as high as it was, as many applications focus on performing a small number of tasks in a very polished manner, and thus are not as informed by the various tasks that users can perform. The research phase, correspondingly, is more important, as the amount of competition that one faces has increased, and the difference between a mediocre application and a good one is not necessarily that the good one has implemented another task, but that it has implemented the same tasks as the former in a more polished manner. Hence, the user-centered approach to UI design is still valid, but the focus should shift away from being specifically task-centered and toward being more generally "user-centered."

My two main disagreements with Lewis and Rieman's design process have already been elaborated upon. Namely, I do not think the task-centered approach nor the "plagiarism" process described in step 3 are as valid today as they were, especially in the domain of small web and mobile applications. Other than these disagreements, I agree with the two authors, as it makes a lot of sense that one would consult with the user as often as possible in order to obtain a clear sense of what he or she wants as well as to get constant feedback about the UI design.

Sangyoon Park - 1/28/2013 1:39:13

Basically, Lewis & Rieman design cycle is explaining the three stage (design, prototype, evaluate) in more detailed way. At the time L&R is written, products had to be finished before it is on sale in stores because there was no reasonable way to alter the product afterwards (now there is a easy way to do this, an online patch). Especially, for web applications, it is so much easier to make changes than the software that was in 1990s. The change between the two times is from buying a hardcopy product to being able to distribute/buy(download) a program via internet. I disagree with the author about providing the generic functionality. It seems pretty fair to have generic functions in programs, having it in every program can make the program harder to build. And, having generic functionality in a program that doesn't necessarily need any of these functions is just a waste of space, time and money.

Eric Xiao - 1/28/2013 1:40:48

The Lewis & Rieman cycle is much more fleshed out, but follows the same principles. We need to figure out who's going to do what and how, 'design' around tasks, 'prototype' with users, iterate and track it so we can 'evaluate.' Lewis & Rieman focused on task-centered behavior, but sometimes tasks can be so general that multiple user interfaces will work for a specified behavior, so how can the best one be chosen? There also needs to be more evaluating after prototyping within the Lewis & Riemann Cycle, I didn't think there was enough gathering of customer feedback.

Their arguments hold ready for web applications, so much so that I didn't even notice it was written in 1994. I liked how they put designers on the telephone hotline to listen to customers, but I think that's stone age material now. Designers can most likely collect e-mail feedback and connect with customers over instant chat. Web applications are also much easier to change and deploy on the fly, which makes testing and iterating much faster.

Weishu Xu - 1/28/2013 1:59:31

1. From a high level, I believe the steps outlined in the Lewis & Rieman design cycle compare very closely to the three stage cycle described in lecture. According to both cycles, the first step is to conduct a task analysis and understand the needs of the users and the processes that the product will be used for. Both seem focused on identifying key representative tasks and envisioning these scenarios. Lewis & Rieman also make the claim that it is often beneficial to plagiarize and base new designs on existing models in order to meet user expectations and reduce the amount of new learning, even at the cost of a few extra keystrokes.

The next stage described by both cycles involves prototyping the design. In Lewis & Rieman as well as the lecture, there was an emphasis on quickly creating the prototype, whether it is through mock-ups or interactive prototyping tools or UIMS.

The final step described by both cycles focuses on evaluating the design, testing with users, and iterating on improvements from comments because the user could always engage with the product in an unexpected way. By improving upon the design, the product can be continually enhanced and developed to be better suit the needs of users.

2. While the high level outline of the design process might stay fairly consistent from the "shrink-wrapped" software times to today's mobile applications, the amount of time dedicated to each step in the cycle has changed. In the old days, software would be distributed as a physical product, which means it would be more difficult to deliver upgrades and modifications and the user would expect a more "finished" product upon purchasing. This means that there would be less room for error before the software is published and distributed to the user. This might mean the designer might have to spend more time performing careful task analysis and testing evaluations (although not with an audience of a similar scale to today). Today, designers of mobile applications can quickly produce new products and easily allow users to download and upgrade their software through various application stores. This means the designer can push out products more quickly and receive more feedback and testing from real users in order to improve their product. More time and less cost can be spent conducting evaluation, and iterations can be delivered without having to ship and distribute new CD's or software systems.

3. One area where I do not completely agree with Lewis & Rieman is regarding their emphasis on "plagiarism." While I believe a valid point can be made about delivering a product that meets user expectations, I do not believe a designer should shy away from trying out a new improvement over existing designs because of a fear of users avoiding their product because of the hassle of learning. Part of it might be because of the fact that software is often downloaded on mobile devices instead of "shrink-wrapped" as addressed in question two. I think there are plenty of examples of successful companies that have created products that very different from predecessors but more "intuitive" for users, leading them to be very successful in spite of their differences. For example, Facebook's website can be considered fairly different from MySpace's model, but users made the switch because of new features and improved designs (especially due to innovation in advertising technology and layout). Many PC fans also made the switch to Apple in the past decade after the company released its line of Macbook computers. Especially in today's world of multiple forms of technology access (TV versus laptop versus tablet, etc), there is a lot of room for designers to create new and innovative products that challenge existing standards and succeed in capturing users.

Ben Dong - 1/28/2013 2:00:17

The Lewis & Rieman design cycle very closely mirrors the three stage cycle described in lecture. Both start with a general task analysis focusing on usage patterns, and then move into rapid prototyping and iterative development. The Lewis & Rieman cycle described in the reading simply goes into more detail about specific design phases.

Much of the design process described holds equally for web applications. In order to build an app with a solid user interface, it is essential to identify common tasks and usage patterns, and testing the app with users is a great way to get feedback and iterate. The main thing that might have changed is the incredible speed with which modern web applications can iterate.

I agree with most of Lewis & Rieman's general ideas, but there are some specifics I take issue with. Plagiarism of design ideas may work out well in some scenarios, but there are many fields in which startups are really making inroads, and they certainly didn't do so by following what had already been done. Also, I don't believe that designers should ever be forced into a customer support position. While they may choose to do that to gain insight into their product's usability, their time could be more valuably spent during user studies or on other tasks -- customer support really doesn't help much and is not the right place to be.

Cory Chen - 1/28/2013 2:00:52

  • The design cycle in the reading is actually very similar to the cycle we learned in lecture. The Lewis & Rieman cycle has 11 steps but they can be seen in the same three design-prototype-evaluate steps. Steps 1 through 5 can be seen as the "design" step, step 6 is the "prototype" step, and steps 7 and 8 can be seen as the "evaluate" step (step 5 is also part of evaluation). Steps 10 and 11 (and 8) occur after evaluation and brings us back to prototyping and iterating the product. Both cycles have the timeline of planning out the system, building a crude version of the system, testing how it works, and then refining it. The main difference I see is that the Lewis 7 Rieman cycle seems to separate prototyping and the final product a little bit, saying that one should iterate a lot with the prototype and then build the final project, changing that one if necessary.
  • I don't think that their argument holds as well for web applications these days. With web applications, we have the advantage of having any changes we write instantly show up on the site without any hassle. This allows for greater flexibility in prototyping and pushing out changes. As a result, we can modify the Lewis & Rieman cycle a little and push up the "build the design" stage. Instead of iterating through a bunch of prototypes, we can now iterate through designed products and push them out to a mass of people with ease. I feel like it's not absolutely imperative to have all the features done before building the design since updates can be released with ease.
  • I agree with pretty much everything that Lewis & Rieman wrote. It's all very solid advice and I think it generally stands the test of time. The only issue I have with their approach is that there seems to be too heavy of a focus on "task centered design". From the reading, it looks like all that matters is functionality and getting your tasks done. There isn't as much of a focus on the actual usability and experience.

Tananun Songdechakraiwut - 1/28/2013 2:52:53

1. The Lewis & Rieman design seems like a more detailed version of three stage cycle that was described in lecture. The authors break the three general steps(design, prototype, and evaluate) into more specific phases as shown below. Design consists of the following: - Figure out who's going to use the system to do what - Choose representative task for task-centered design - Plagiarize - Rough out a design Prototype is broken down as the follow step: - Create a mock-up or prototype Evaluate as follow: - test it with users Then iterate till running out of money, etc Finally, build/track/change the design

2. No, it doesn't. Web applications are those applications that can be accessed by users over the internet. Thus, they are easily released and re-released. In particular, designers can release software and later re-release the more sophisticated version after receiving complaints about problems(evaluation). Therefore, it is not necessary to keep iterating before building the design(part 1.8 and 1.9).

3. It is the similar concept of the above answer. At present, we commonly access most applications over the internet and thus exploiting this fact is a very good idea. In particular, we can directly get our product to market and do the testing with users for free! To sum up, we somewhat(but not completely since the product has to be a working one too) ignore part 1.8, go straight to the building the design phase, and release the product to users. These possibly imply lower the costs and more beneficial/profitable to us.

Lishan Zhang - 1/28/2013 4:56:20

1. In general, the Lewis & Rieman design cycle is similar to the three stage cycle described in lecture, but L & R's cycle is more complicated and with far more details on each step. The similarities involved that they all loop in a cycle in order to improve the design by testing with users before running out of money. However, Lewis & Rieman's cycle emphasizes on task-centered design process while in the lecture the professor said it is difficult to identify the problem in UI design.

2. I think that the design process described in the article is kind of outdated. Tasks and users changes dramatically fast nowadays. The design process for “shrink-wrapped” software is no longer suitable for web application because there is too many steps in the design cycle so it takes longer to update and will be easily beaten by other competitors. Besides, it is not convenient for users to purchase and compare the similar products. Now the users can purchase software through app store in the Internet and select the most relevant one by recommendations and reviews.

3. Basically I agree with the Lewis & Rieman’s design process. The major disadvantage for the design cycle should be the complicated steps. It will take longer time to accomplish one loop and get the regular upgrades. The competitors can easily catch up with it in the meanwhile. In addition, the designers’ duty on customer hotline described in Chapter 1.10 is a waste of time and less helpful because individual user cannot represent the whole group. It is more effective if we can collect a large amount of data and generate a convincing feedback like reviews.

Zhaochen "JJ" Liu - 1/28/2013 5:16:42

1. Similarities

  • They both adapted an iterative design methodology, that is, to refine the products based on users’ feedback from the previous version.
  • The two designs both stop when the money runs out, the time runs out or the requirements are met.


  • Clayton Lewis and John Rieman’s design process is more of task-centered. It already knows what the problem the designer wants to solve. However, in the lecture, the professor says in HCI, the designers sometimes don’t know what the real problem is.
  • Lewis and Rieman’s process focus a lot on the design after the iterate steps (1.8). However, the cycle descried in the lecture is a full cycle, where each cycle starts with design.
  • Lewis and Rieman’s design process has far more steps than just “Design, Prototype and Evaluate”. However, the essence is similar.

2. No. Although the general concept is correct, it might not necessarly still be the best practice in today’s world. For example, something has been chanced: 1. Designing & creating software becomes easier because of better development tools, more online tutorials, and more distribution channels. 2. Today’s software has become much smaller and modular (a simple iOS app VS. Microsoft Word), thus easier to develop. Also, it should have a shorter development cycle. 3. Today’s users have a stronger need for better UI and aesthetic joy (e.g. Fruit Ninja). So the focus of designing the software has been changed (focusing on features -> focusing on features & art) 4. Today, the evaluate & feedback channel is different. As described in the chapter (ch. 1.10), they use hotlines. Today, the reviews are usually can be found in app stores (iOS stores, Google Play stores)

3. 1. The book chapter (ch. 1.4) says the first design should be on paper. I don’t agree with this because there are some easy-to-use tools (for example, Balsamic) that allow us to quickly do a much better looking rough design on computers with very short time. Also, it is easier to save, revise and share my design using a software tool, rather than using paper. 2. There are too many steps described in this book, thus making the development period too long and too complicated. Today’s software usually has a shorter life cycle and needs constant update. So, a ‘design-prototype-evaluate ‘might be more appropriate for today’s software. 3. In chapter 1.10, it says they the designers should talk to customers directly via hotlines. Nowadays, the feedback channel is different. Usually, there’s a review system in app stores, such as Google Play and iOS stores. The developers should utilize those to quickly gather feedback.

Erika Delk - 1/28/2013 8:29:04

1. In a general sense, Lewis and Rieman follows the three basic steps: they have an extensive design phase, a prototype phase, and an evaluate phase. However, they stress the involvement of the user with each of these phases as well as the need to continue to improve upon the software.

2. I think that for the most part, their argument does hold up for web applications. Some differences is that web applications usually have a much broader audience (the entire internet) and many times, the designer gets to choose which specific audience (say, senior citizens or elementary school children) they wish to target. Furthermore, many web applications are free and lots of them exist, so the competition is different and copying existing interfaces might not be as useful as it once was.

3. I suppose I am somewhat skeptical of their advice to "plagerize" existing interfaces. While I understand their point about users already being familiar with certain interfaces, in some cases I'm sure this results in the same bad design decisions being made over and over again.

Michael Flater - 1/28/2013 9:33:46

The cycle described in L&R is obviously much more detailed than what was presented to us in lecture. L&R emphasize not getting ahead of yourself in the design process and not committing to anything before it is absolutely necessary. Though the article was written a while back, in the days of floppy drives I'd bet, it still hold for web development. The thing about the web that didn't hold in the days before mass connectivity is that we can now program our systems to automatically send feedback about how it is being used and improve it with these reports. The days of having a designer sit on a hotline are probably over. Survey also can give good feedback from customers. The problem and place where I disagree with L&R is that in this new era of web development we don't know who the user might be, what practices they are comfortable with, etc. The article says to "plagiarize" but we really don't know from whom to do this. We can make large assumptions about our user base but in practice this is harder to achieve than when applications were written for very specific tasks.

Marco Grigolo - 1/28/2013 10:10:52

User is involved in the early stage for L&R, as studying them and ask them allow us to better understand what functionality we want to employ. At the same time thou, user is not as much involved as in the 3 stages design, since in the latter one the user is involved at the end of each cycle to evaluate our progresses. In the L&R users are involved only in the first stage and in the final by testing, while during development, implementations and task are "evaluated" by the team.

In L&R there is less emphasis on plagiarism, since by being task-centric, we focus on the task and apply other UI ideas only when they suit us and after much thought about what is best for the UI, while in the 3 stages cycle we use plagiarism more extensively in order to have a fast prototype to evaluate.

The 3 Stages cycle is more agile, because consists in shorter but frequent iterations (agile development), while L&R establish a more robust, slower cycle of development (looks like an adaptation of the waterfall model for UI, where instead of system requirements, we have tasks requirements), where the main work in done in one long iteration, and at the end of it no much change can come (just improvements and fixes). On the lecture cycle, mayor changes can occur between different cycles to adapt better to the users needs once we receive the feedback after each cycle. They are both good procedure that can be applied to different situations, L&R when we have big programs that cannot change easily, or where interaction with customers are not easily organized (for example when we have millions of users), while 3 stages cycle are better for small customers who need specific apps for their needs. L&R have room for more innovative solutions, since it is less focused on plagiarism, but is much more hard to recover from failure in the design.

Eric Wishart - 1/28/2013 10:28:24

1) As compared to the three stage cycle described in lecture, the Lewis & Rieman design cycle puts a much heavier focus on the design portion of creating the interface. The design step is broken down into five steps that has the creator thinking about the user right away and then breaking down the program into tasks. The focus of the process described by Lewis & Rieman is very much that of thinking everything through, where the three stage cycle wants you to iterate through designs much faster.

2) Most of the ideas of the article still hold regardless of the time written but there are most certainly some aspects of deployment and testing after deployment that should be updated. It is now much easier to create a rapid prototype, so a large portion of the time spent thinking about how a user is going to use something can be removed by just building it and getting feedback from a user. It is also easier to monitor how customers are interacting with a UI after deployment, so tracking the design is much easier.

3) I disagree with parts of the plagiarizing section. While it is true that you want to look to existing procedures for common tasks, not looking for new and improve ways to interact with our technology is what leads to design stagnation. If the answer to "why do we do it like that?" is "Oh, that's just how everyone always does it", it seems like this is a good place to analyze a process's effectiveness. If you want to revolutionize how people interact with devices, you can't do it by copying everyone else.

Edward Shi - 1/28/2013 11:30:14

The Lewis & Reiman design first emphasizes finding out who the target user is as opposed to the lecture simply stating to go observe first. They also further delay the building of a prototype until much later as the encourage a lot of thinking first. Moreover, they also encourage looking at existing models and successful implementations before beginning with your own prototype. On the other hand, both design cycles emphasize rough prototyping which may simply be sketches as there may not be time and resources to constantly build full scale implementations. They also suggest that there will always be mistakes and strongly encourage low cost designs as well as implementing the interface with the idea that change will be inevitable.

Despite the fact that software is not necessarily "shrink-wrapped" anymore, I feel that the general design principles still apply. There may be some more lee-way in allowing more rough sketches of designs to be tested as instead of people going in store to buy the product, you can create betas or release rough work and where they can download from the web and then continue to patch it up. This ease of communication with the user is an advantage that the shrink-wrapped software did not have at the time.

In general, I agree with the Lewis & Rieman design cycle. If I were to change anything, instead of thinking of a representative tasks purely with the team, I would also ask the target users about what a representative task would be like to them. As such, user and developer communication can begin even earlier. It would be disastrous if the representative task chosen is irrelevant to the target user.

Jin Ryu - 1/28/2013 11:31:57

The Lewis & Rieman design cycle seems to have many more steps than the three-stage (design, prototype, evaluate) cycle. It also emphasizes re-using and building on ideas from previous existing works in user interface to develop the new project instead of starting everything from scratch. The L&R cycle is more task-oriented as the critical first step appears to be in creating representative user tasks that the project needs to be able to accomplish which are then later used to specify a design. It also includes some variants of the three stages: designing, prototyping, and evaluation, but more specific with additions. It insists on adding a pre-evaluation (thinking step to analyze the design) step before prototyping, and only after the necessary iterations of designing, making changes, evaluating, and testing of prototype by users, then the final product is built.

Their argument can also hold for web applications. Users have easier access to these apps than software they have to buy in store, so the cost of building a complete user interface for the web and testing it with users are probably not as high as mentioned by the authors. Tracking and changing the final design can also be done more instantly after release so the thinking step, prototyping and testing with users of prototype probably would not have to be so extensive before building the final product.

I think instead of building the final product separately from prototype at the last step, the design cycle should be developing continuously from the beginning on an application that will be the final product eventually. A new final build of a product that has not been through the same several iterations of the cycle as well might have hidden problems that were not caught by withstanding persistent testing/evaluating as the prototype. The "plagarism" step may also reduce some creativity in building an unique user interface design for new projects.

Haotian Wang - 1/28/2013 11:38:44

1. It seems to me that the L&R cycle is just a more detailed version of the three-stage cycle in lecture. Design, as described in lecture, is broken down to steps 1-5 in L&R, prototyping is step 6, and evaluation is 7-8.

2. Some of the thought processes, such as making sure the hardware for the program fits comfortably in the place of use, seems no longer relevant, since web applications run in the cloud, and users can use browsers on any hardware they choose. Furthermore, it seems that since users will be using different devices, separate cases may need to be considered for how users are expected to use the application. Laptop access could be much different from smartphone access in terms of UI requirements.

3. I don't really disagree with L&R on any of their suggestions. Since I am extremely new to UI design (have never myself designed a comprehensive UI), design is itself new to me, so that such careful well-thought-out steps seems a big step-up from what would otherwise be my no-thought-just-code-it process.

Ben Goldberg - 1/28/2013 12:05:49

The iterate stage of the Lewis & Rieman design cycle is very similar to the three stage cycle described in lecture. I believe the main difference between the two is only the increased amount of detail in the Lewis & Rieman design cycle, which includes splitting up the design and prototype stages into multiple smaller stages.

The main thing that has changed with web applications is that you can implement changes to the software in virtually real time, as opposed to shrink-wrapped software which took weeks to get from the developer to the user. Because of this, you can do much of the testing remotely using beta versions of the software, as opposed to doing the testing in person. It's also now possible to get much larger amounts of feedback at a decreased cost.

I'm not sure there's much to disagree with Lewis & Riemann about. Though it's outdated, most of their advice is fundamental. I would be foolish in disagreeing with the amount of prototyping that should be done before building a real product, but that's probably the area I'm most critical of, if any.

Tenzin Nyima - 1/28/2013 12:14:14

The three stage cycle described in the lecture and in the reading basically share the same concepts and ideas. In the reading, Lewis and Rieman went in with more details. For example, in the lecture, Prof. Hartmann talked about "Task Analysis & Contextual Inquiry" where he mentioned about the importance of knowing what are the things that users want to do with the application, what are the needs of these users. And to do these, one has to talk to them, ask them questions and observe them, which will then lead to creation of scenarios and abstract models. But on top of that, Lewis & Rieman also writes about "Plagiarize" which means that one should be able to identify existing interfaces that users are familiar with and then implement those in your design. Also, for the second stage of the cycle - prototype, one important difference between the lecture and reading is that, in the reading author wanted us to first do a rough design on paper and then think about it. Use cognitive walkthrough techniques to spot the mistakes users might make and then go for a more concrete prototype using tools for mock-up. While in the lecture we did not specifically talked about the importance of having two stages of prototypes with evaluation in between.

Yes! It is very much hold equally for web applications. We built an app application last semester for CS169 class project and we applied the techniques these techniques.

I may not fully disagree but I am little skeptical about Lewis and Rieman’s advice on “Plagiarize”. Especially their example of the spelling checker. I believe that in order to bring out the best UI, one should take risk by going beyond what was already there - obviously your new implementation should have a better UI, else it won't make any sense. Lewis and Rieman writes, “But more often than not, the best answer is to stick with what the users know, even if it does require an extra keystroke or two.” I would not stick with what the users know if I could implement a new UI that require less keystroke.

Lauren Fratamico - 1/28/2013 12:20:12

The Lewis & Rieman (L & R) cycle is very similar to what was described in class in that they both go through the same three major phases. The L & R method seems to focus more on major releases of the next version and iterating many times before release while the method mentioned in class seemed to allow more minor code pushes after the product was released. But the design phases themselves were similar.

L & R's design cycle still holds true for the most part, however now that we have web apps, it is easier to push design changes. In this way, we do not have to release major changes, we can just keep iterating on our design and push a minor change every time we see an opportunity for improvement.

I disagree with the "change the design" section. This section appears to be more catered towards the older software development models. It is true that design and functionality need to change and reflect the new needs of the users, however L & R describe these changes more as huge code updates. Users of today's world hate large changes to the products they are using. We see this every time facebook releases a new interface. People "boycott" and complain for a month or so then quiet down. So while I do agree that updates need to be made, these updates do not need to be as revolutionary as the paper made them seem. Users can remain happy with the software if it is still performing the task they purchased it for, and new customers can still be gained while marketing a similar product.

Moshe Leon - 1/28/2013 12:33:36

They are almost exactly the same, only that Lewis & Rieman expand their description of the design stage and get into the smallest details. According to them, the design stage is composed of: Learning who the users are and thinking about the product they need (emphases on need), getting the user stories written down with more and less complex features, and plagiarizing (With similar, already-existing products) to insure the design's success-fullness and popularity amongst designated users. 1.4 And 1.5 are pre-prototyping stage, and they can either fit in the design or in the prototyping stage. They mainly focus on thinking and mentally running through the suggested design, before a prototype is made. 1.6 is the prototyping itself, and it is pretty much straight forward- build a mock-up or a prototype that would simulate the real product (Rather than spending money on a product that would not be satisfying). 1.7 is analogous to the evaluation stage, when users are using the product (prototype) BUT: in class the evaluation is testing with and WITHOUT users. It is notable that the testing without users has been moved to the pre-prototyping stage. After the evaluation, 1.8 is discussing the iteration process, in which the prototype is being re-designed to fit the new, adjusted features. It is only then, that the product is being built, at stage 1.9. Obviously, with the "shrink-wrapped" methodology, there was a huge emphasis on insuring that the product is as precise and ready to ship as possible, since dealing with errors and major changes involved complicated process of workload that would hinder the company's profit. Today, especially with SaaS applications, it is easier than ever to change, modify, and add new features to existing products. The main reason is that most services are cloud based, and can be changed instantly, without having the customer even notice that any change ever took place. You might have had to check regularly with customers after shipping the product, but today, the connection between the client and the manufacturing company is easier, and faster. Feedback is no longer chased after, but is transmitted with a click of a button by a customer- satisfied or unsatisfied. 1.10 stage would be extremely different if it was to be written today, and 1.11 as well. Revisions to designs can be made by a simple downloadable content that takes no more than a few minutes and is completely automatic. I disagree with Lewis & Rieman in the emphasis they place on testing, before even manufacturing. Many companies today release and ship an unfinished product, and build it according to live feedback from their customers. Web applications have made it easier to not even need to download anything, and cloud based products are providing a "one copy for all" methodology- no more "shrink-wrapped" products in stores.

Anh Mai - 1/28/2013 12:37:05

Even though the Lewis & Rieman design cycle goes into more details, in essence, it is the same as the design -> prototype -> evaluate cycle we saw in lecture.

Because the their argument about the design process was made mainly for shrink-wrapped software, the Iterate phase seems to be made before the software is put on shelves, whereas with web applications, iterating can continue right after the application is released to the public since pushing updates require no extra production cost beyond man-power.

I disagree with Lewis & Rieman in their initial belief that early prototyping can only exist on paper - we are at an age where coding up a quick prototype for better evaluation of design ideas is not a costly move, so early prototypes are not limited to paper sketches at all.

Kayvan Najafzadeh - 1/28/2013 12:46:59

Both cycles cover the important parts of the design but Lewis & Rieman design cycle is a bit more in depth and has more detailed stages than three stage design.

In today's technology things happen so fast that I believe producing a product should not take so much time. the revision stage could happen while users are using the system and giving feedback on it. In this case the system does what its suppose to do and also we are improving it on the go. The other thing that has been changed is the ways to approach users are way easier than before. we can have a product that self reports and changes could be made and product can be redistributed in no time.

One things that I disagree with L&R is that in today' world there might be millions of people who are our potential customers but they are not around us and finding them is not an easy task to accomplish so I would suggest the other way around this issue, lets develop the product and the system then let them find us instead. As I said before developing systems and web applications are so easier to do and deploying the product is much easier than before which allows us to develop any idea and wait for the potential users.

Nadine (Jordan) Salter - 1/28/2013 12:52:06

The Lewis & Rieman design cycle is analogous to the three-stage cycle described in lecture, with more details specified for each stage (e.g., GOMS analysis as a metric for usability). I like its focus on choosing and referencing "representative tasks" and accompanying technique for avoiding feature creep (i.e., "if this feature doesn't solve a task, don't include it").

Their design process could technically be applied to web applications as well as shrink-wrapped software, but the convenience of modifying already-released software has changed drastically in the intervening years. Even desktop software traditionally sold on CD or DVD, like Microsoft Office or Adobe's Creative Suite, can receive major updates over the Web, and a web application can be changed literally every time you access it. As such, there is less of an emphasis on "getting it right" the first time, and "evaluate" can be merged with "release": different subsets of your userbase can be presented with different versions of your application, allowing people to use your software while you search for ways to improve the user interface.

I disagree with Lewis & Rieman over plagiarising. Copying existing paradigms is certainly a reasonable default way to proceed on platforms like OS X and iOS where consistently adhering to the platform's paradigms is a requirement of good software. Web applications, however, may attempt to emulate desktop software and do so incompletely because of inherent limitations — a webapp can't get it exactly right on every platform, and there can be an "uncanny valley" effect. Also, if nobody challenges the status quo, there won't be improvements! The Twitter iPhone app (I think?) introduced pull-to-refresh, which has found its way into everyone's muscle memory and even Apple's own software. Standing out with a different, but better, user interface can be a good thing.

Matthew Chang - 1/28/2013 12:54:04

The Lewis & Rieman design cycle is almost a more detailed version of the three stage cycle described in lecture. Whereas the version in lecture is more broad and therefore able to handle more situations, the Lewis & Rieman version lends itself towards larger, more complex projects that have discrete milestones that freeze the development of the product.

With the cycle discussed in class, the emphasis is on iterations. It focuses on taking an idea, getting mockups, and then testing. Whereas Lewis & Riemann emphasize the planning process and directly reflects the fact that the product can be difficult to change when released.

I do not necessarily disagree with Lewis & Riemann, so much as to qualify that their cycle emphasizes getting the product absolutely correct on the first release. With the software being sold at the time, first impressions were far more important. Now with web development, it is possible to continuously make changes and improve over time.

Brett Johnson - 1/28/2013 13:04:35

I think that Lewis and Rieman’s design cycle is very similar to the three state cycle we saw in lecture, albeit expanded a great deal at each step. Their steps 1-8 are basically the same as the three step cycle, and then after that they say to build and track the design. So, they are treating the “build” stage separately from from the “prototype” stage, unlike the three step cycle, which encloses these two steps into one. It makes sense to put more emphasis on prototyping, as that is what will advance the UI and save later programming time.

For the most part, I think their design process holds for web applications. In an ideal world, designers and developers would iterate constantly on their application to make it as good as possible, but now that companies can push updates out via the web so quickly means that there is less pressure to have a one hundred percent polished product at launch. But I think that despite the changes in the way that software is now deployed, their design process is a reliable guide. While tracking and changing the design is arguably easier now as well, prototyping and interaction between consumer and designer is still fundamental to improving the product.

An area where I disagree with Lewis and Rieman is on plagiarism. Instead of immediately looking to a similar product and copying button placement and other interface elements, I would be more inclined to do the “rough out the design” step first on my own. This way, I would not be constrained by past designs, so when roughing it out an innovative interface may manifest itself. After roughing it out, I would then do the “plagiarize” step and see where my interface deviates from the norm, and alter it if the traditional interface made more sense.

Thomas Yun - 1/28/2013 13:04:47

The Lewis and Rieman design cycle seems to be a more detailed version of the design cycle that was described in lecture. The design cycle showed in lecture touches on the key points in which the Lewis and Rieman elaborate more on. The design cycle from the reading includes: figuring out the users, deciding tasks, plagiarizing, roughing out a design, thinking about the tasks, creating a prototype, testing, iterating, building, monitoring, and changing. The first four points, minus the plagiarzing, can be considered the design step. The next 3 can be considered the prototyping phase, and the last 3 can be considered the evaluating phase. The reason plagiarizing isn't included is because we didn't really mention anything about borrowing ideas from existing interfaces but I guess it's somewhat necessary for a successful product. The key points that both lecture and the reading both touch on include speaking with users to find out what the interface needs in order to satisfy the needs of the users, designing a rough prototype on paper even before prototyping the interface with actual code, testing this rough design with users, then designing a final prototype and testing and changing it if necessary.

I don't really think it the argument for the design process really changes much if at all. Most of the points/phases that Lewis and Rieman mention are key to designing a product with specific users in mind. Actually, with today's applications being web-based instead of being physical copies, it would make most of the design process a lot easier. With applications being web-based, it's easier to have users test the design online and have them submit any problems they see. Although, it is better to do the testing in person with the user, it's not really necessary with web-based applications. But after thinking about it for a little, I don't think anything really has changed. Shrink-wrapped software is only sold after the product is complete and the only difference between the two is that one is a hard copy while the other is on the web. It's like comparing the difference between a digital download and a DVD copy of essentially the same thing. There really is no difference since they are both essentially applications with the exception that the web-based may be easier to provide patches for. If anything, it would be a lot easier to monitor and change the product if bugs were to be discovered.

I can't really find anything about Lewis' and Rieman's argument to disagree about. Everything they mention are important in designing a good product. Why else would both lecture and the reading both mention essentially similar key points? Actually, if I had to choose something to disagree with, it would have to be the "Think about it" phase. They mention that in that phase, that building a product and testing it with enough users to reveal all the major flaws is not good. Rather, it would be a good idea to think about the task and the steps etc. before allowing users to test. However, I don't think this step is really necessary. Isn't the point of testing a design with users to find out these major flaws? Even if you were to calculate the amount of steps in a task and to realize that it may be too many, that is something the users can do. I'm not saying that we shouldn't think about our task during the design task but it seems that this phase can be ignored (in our case at least) as we aren't designing a huge product. I just think it's a better use of time to have users test and provide direct feedback on a design since the interface is for the users. They also mention in the reading that we should design tasks that the user is used to even if it requires an extra keystroke. I just think the two points don't agree since one is asking to count steps and the other is asking to keep what the users are used to.

Thomas Yun - 1/28/2013 13:05:40

The Lewis and Rieman design cycle seems to be a more detailed version of the design cycle that was described in lecture. The design cycle showed in lecture touches on the key points in which the Lewis and Rieman elaborate more on. The design cycle from the reading includes: figuring out the users, deciding tasks, plagiarizing, roughing out a design, thinking about the tasks, creating a prototype, testing, iterating, building, monitoring, and changing. The first four points, minus the plagiarzing, can be considered the design step. The next 3 can be considered the prototyping phase, and the last 3 can be considered the evaluating phase. The reason plagiarizing isn't included is because we didn't really mention anything about borrowing ideas from existing interfaces but I guess it's somewhat necessary for a successful product. The key points that both lecture and the reading both touch on include speaking with users to find out what the interface needs in order to satisfy the needs of the users, designing a rough prototype on paper even before prototyping the interface with actual code, testing this rough design with users, then designing a final prototype and testing and changing it if necessary.

I don't really think it the argument for the design process really changes much if at all. Most of the points/phases that Lewis and Rieman mention are key to designing a product with specific users in mind. Actually, with today's applications being web-based instead of being physical copies, it would make most of the design process a lot easier. With applications being web-based, it's easier to have users test the design online and have them submit any problems they see. Although, it is better to do the testing in person with the user, it's not really necessary with web-based applications. But after thinking about it for a little, I don't think anything really has changed. Shrink-wrapped software is only sold after the product is complete and the only difference between the two is that one is a hard copy while the other is on the web. It's like comparing the difference between a digital download and a DVD copy of essentially the same thing. There really is no difference since they are both essentially applications with the exception that the web-based may be easier to provide patches for. If anything, it would be a lot easier to monitor and change the product if bugs were to be discovered.

I can't really find anything about Lewis' and Rieman's argument to disagree about. Everything they mention are important in designing a good product. Why else would both lecture and the reading both mention essentially similar key points? Actually, if I had to choose something to disagree with, it would have to be the "Think about it" phase. They mention that in that phase, that building a product and testing it with enough users to reveal all the major flaws is not good. Rather, it would be a good idea to think about the task and the steps etc. before allowing users to test. However, I don't think this step is really necessary. Isn't the point of testing a design with users to find out these major flaws? Even if you were to calculate the amount of steps in a task and to realize that it may be too many, that is something the users can do. I'm not saying that we shouldn't think about our task during the design task but it seems that this phase can be ignored (in our case at least) as we aren't designing a huge product. I just think it's a better use of time to have users test and provide direct feedback on a design since the interface is for the users. They also mention in the reading that we should design tasks that the user is used to even if it requires an extra keystroke. I just think the two points don't agree since one is asking to count the number of steps and the other is asking to keep what the user is used to.

Glenn Sugden - 1/28/2013 13:07:09

How does the Lewis & Rieman design cycle compare to the three stage (design, prototype, evaluate) cycle described in lecture?

They are very similar ideas - Lewis & Rieman have broken the major steps outlined in the lecture down into more granularity, added some extra steps (including some meta ones), but the most of the same ideas are represented in both:

<--------------   Iterate   ----------------->

Design		Prototype	Evaluate
Figure out(1)	Rough out(4)	Build it(8)	
Choose Reps(2)	Think(5)	Test it(7)
Plagarize(3)	Create(6)	Track it(9)
Think(5)	Change it(10)	
Change it(10)

This article was written at a time when most software was sold "shrink-wrapped" in stores. Does their argument about the design process hold equally for web applications? If not, what has changed?

There argument doesn't change (in my opinion), but the iterative process is FAR "tighter" than in the "shrink-wrapped past." Web apps are, by design, available to be updated (almost) immediately. The real challenge is to maintain the same discipline to think, research, get feedback, etc. in the face of "ooh! I can roll out a quick fix that *I* think is super-important!"

Where do you disagree with Lewis & Riemann? Why?

I totally agree with their "ideals," but I found that, especially in the latter stages, it was very difficult to maintain the iterative process after a product had shipped*. I think their last steps (track it, change it) are very solid ideas, and I hope it gets built into more time/money budgets for large projects in the future (when people realize how important it is for a products' longevity).

* Web-only apps have a much easier time with this, as tracking and changing is much less disruptive (and tracking is even built into a lot of web engines/frameworks/etc).

Raymond Lin - 1/28/2013 13:15:29

I think that the two models are very similar in that Lewis & Rieman's design cycle's stages can be categorized in the 3 more general stages described in lecture. Steps 1.1-1.5 effectively detail how we should think about creating our design. What it boils down to is creating an interface that is familiar, useful, and simple to the customer. While, section 1.6 is exactly the same as the 2nd stage, prototyping, Lewis & Rieman go into further detail about evaluation, including potentially changing your design and repeating the steps if necessary. I think that their argument still holds primarily because there are so many Internet users that it's more essential now then ever to develop a suitable interface to be able to compete with a ton of other web applications out there that have a similar functionality. I think the only area where I would disagree with Lewis & Riemann would be trying to keep the interface familiar. What I mean by this is, even if to a certain degree we don't want to force anything to difficult on the user, I believe that changing it and pushing the user to learn something more practical (limiting the degree of difficulty) can be better than an intuitive interface.

Andrew Gealy - 1/28/2013 13:27:59

The Lewis and Rieman cycle essentially follows the same three stage cycle from lecture, with some further subdivisions -- especially in the design phase. Steps 1.1-1.5 all fall under the initial design phase. They describe initial need-finding and task selection for a task-centered design along with consideration of previous design principles and the environment within which the product will exist. 1.6 entails creating a prototype, and 1.7 describes one part of the evaluation phase with a focus on user testing. 1.8 describes the cyclical nature of design iterations.

Their argument should still hold true for web applications, with some subtle changes. Primarily, the ease with which web applications can be changed and updated makes it such that one may release at an earlier design iteration and continue making changes as problems arise. Beta testing is easier than ever. However this may also lead (and has led) to the release of less polished, less complete, and potentially more unstable software. Regardless of the quality of the initial release, updates may be smaller and more continuous than with shrink-wrapped software, where it might be more likely to sell or otherwise offer a large yearly upgrade. Web applications may also employ less formal user testing, relying more on the responses and tracking of their actual users rather than bringing in groups for testing prior to the product's release.

For the most part I agree with Lewis and Rieman and feel that their approach remains valid. They seem to generally endorse sticking with current standards, even if they are inefficient, for the sake of user familiarity. This is probably the right approach in many circumstances, but certainly not all. Standards like the QWERTY keyboard are so broad and ingrained that changing them is difficult and has proved largely unsuccessful. But in many cases there may be a standard where user familiarity or frequency of use is not as significant, where changes will feel less obtrusive. The scale of your project also plays a role. A company like Apple is large enough that they may be able to defy Lewis and Rieman's advice and set new standards that eventually become the norm. For example, reversing the scroll direction on their latest OS X operating system is disrupting at first but ubiquitous enough that it has the potential to set new standards.

Alysha Jivani - 1/28/2013 13:31:21

The Lewis & Rieman design cycle is, at its heart, very similar and closely tied to the three-stage cycle described in lecture. It brings specific attention to the necessary user research, contextual analysis, and survey of current user interfaces that needs to be conducted before entering the design phase and breaks each of the three stages (design, prototype, and evaluate) into more specific sections. I think you could easily fit their steps into the three-stage cycle: 1.1 – 1.3 are the pre-planning steps necessary for the design stage, 1.4-1.5 seem to fall into the design stage, 1.6 coincides with the prototype stage, and 1.7 seems to coincide with the evaluate stage. The remaining stages get at the iterative nature of the “cycle” diagram—evolving the design, prototyping it again, and then testing/evaluating it again.

I think the *principles* behind their design process holds equally for web applications for the most part. However, web applications allow for different ways of obtaining/tracking how people use and interact with the interface, and it has become easier to obtain user feedback. With tools like A/B testing and the ability to obtain data on the usage of the application, the evaluation and iteration processes have also become somewhat easier. Also, it has become possible to release new changes in “waves” or to select groups of users and evaluate the response/usage to the changes instead of releasing or applying the changes to everyone at once.

While I agree with most of the steps and ideas proposed by Lewis & Rieman, I don’t necessarily agree with their belief that features that are not directly related to any of the tasks should be eliminated because it is possible that these other features could enhance the user experience or meet needs that the user might not have explicitly realized or specified. Also, I think that the step about “plagiarizing” can be useful in some ways, but I think that it also important to look at unsuccessful user interfaces to understand what to avoid.

Eric Leung - 1/28/2013 13:33:39

The Lewis & Rieman design cycle is very much in line with the three stage cycle described in lecture. The first three steps, figuring out who's going to use the system for what purpose, "plagiarizing", and choosing tasks for task-centered design are all part of the design phase. The next four, roughing out a design, thinking about it, creating a mock-up, and testing it are the relevant phases to the prototyping phase. All the other steps, iterating, building, tracking and changing it all have key components of evaluation involved. Lewis & Rieman detail out more steps than the three simple stages, but the ideology behind it remains the same: get a product out, and test it with real users.

While "shrink-wrapped" software has the drawback of being hard-to-update and hard-to-test, web applications are easily updated and can almost instantaneously be pushed to all users. Also, not having to ship software onto consumer's machines allows for A/B testing and quicker iteration. However, it still holds true that the product still must be focused on consumer needs, and iteration over it after testing continually will improve

I disagree with Lewis & Rieman in building out a non-functional prototype in order to begin testing. While I agree with sketching out low-fi mock-ups of products before implementation, I think that a fully working prototype will provide much more valuable feedback. Because of the quick development tools now available, the argument that prototyping a fully working product uses too much time and resources has become less relevant.

Oulun Zhao - 1/28/2013 13:55:01

a. They are very similar in a sense that design is similar to what L&R's 1.1-1.5 steps, prototype is step 1.6, and evaluate is 1.7. At the same time, L&R also emphasizes the importance of iteration that we need to go back and re-evaluate and change some of the original designs.

b. Yes, according to my opinion their arguments still hold. This design process is very similar to the agile development cycle that was used for SAAS(software as a service) project and web-applications.

c. I agree with Lewis & Riemann mostly. I do not have any significant point that disagree with them.

Harry Zhu - 1/28/2013 14:08:27

1) Their design process is similar to the three stage cycle described in lecture, but what parts of the process they emphasize is different. The first first steps can all be grouped into the design stage, and the next two are similar to the prototyping/evaluate phase. However, they do heavily emphasize the design stage. They heavily push for careful planning and consideration before releasing the final product, while the process described in lecture is a constant cycle of planning, prototyping, and feedback. Another key difference is that the article describes creating a "final product", while the process in lecture describes it as a constantly changing product.

2) In general, their design process does not entirely hold true for the modern web applications, because the distribution mediums are so different. With physical "shrink-wrapped" software packages, big changes to the code can take a long time before it gets out to the public. With web applications, its really easy to make changes, since its all done digitally.

3) I disagree with Lewis & Riemann mainly on how much emphasis they put on planning, especially in today's world. With mobile apps, developers can push changes to their code much quicker than before. This makes the value of feedback from the users much more valuable and the planning phase of the process much quicker. While I don't think that careful planning should be neglected, it doesn't have to be so meticulous as they have described now that pushing out a change can be almost instantaneous.

Juntao (Alice) Mao - 1/28/2013 14:15:23

Lewis & Rieman design cycle further expands on the three stage cycle from lecture. The first two steps of L&R cycle similar to the Task Analysis & Contextual Inquiry stage from lecture. And in addition, the L& R includes a user analysis process in order to define task. Also, while Lecture cycle creates scenarios of actual use, the L&R focuses on defining all the representative tasks, and the whole L&R cycle is focused on completing these tasks. The third step in L&R is one that the lecture does not explicitly mention. Plagiarizing is a pre-step in order to come up with an initial design. L&R also explicitly adds a step to evaluate after the very first initial design. Last big difference is that L&R also includes steps of building product and tracking after release. Most of the argument about design process still holds for web applications. However, with the significantly shorter release cycles of web applications, and that it is a lot cheaper to update an web app than an shrink-wrapped software, there should be a larger emphasis on the process after product release. And also, it is also possible to try out pre-release beta testing versions of the software on a wider range of potential users. I disagree with L&R in that I think there should be more interaction with the customer/potential users during the design process. Especially with a commercial customer, very often their requirements would be changing, and with these changes, the list of representative tasks that is central to the L&R model also need to be updated.

Lemuel Daniel Wu - 1/28/2013 14:16:37

Like the design, prototype, and evaluation recommended in the lectures, Lewis and Riemann suggest roughing out a design, and discussing whether it works as hoped, followed by creating a prototype, and testing the prototype with users. Lewis and Riemann also suggest looping this procedure. However, I am not entirely sure I agree with how Lewis and Riemann have described the entire design process. They highly recommended sticking to what people are used to in terms of interacting with programs on their computers. However, a lot of software today comes in the form of web applications, meaning that software is much more accessible, and there are a lot of similar programs. Because of this, software that is similar to programs people have already seen is not worth as much. Thus, it is better to be more open to differences from what people are used to. But even more than this, it is not true that websites need to be designed first, and then prototyped, and then checked iteratively. This is because testing of a website often requires putting it out on the internet already, meaning that it is already released to the public. As such, I believe that Lewis and Riemann should have written out a different process for web applications. For these applications, it is possible that the designers need to test it themselves several times before allowing users to give input, so that other people cannot see a faulty web application, and end up being biased against this application before its truly ready for a release.

Derek Lau - 1/28/2013 14:18:41

The Lewis and Rieman design cycle is a more detailed version of the design-prototype-evaluate cycle as described in lecture. The "task and user analysis" is a big portion of the design phase, as studying the necessities of the users is key to the the task-centered design cycle. Mock-ups and prototypes are used to solidify and commit ideas to paper, while not overcommitting by implementing in code, but allowing for changes during the review of the mockup. Evaluation comes from testing the design with users and receiving feedback from users who are very similar to the target audience of the software.

Because user interfaces are a huge portion of web applications, task-centered design is still very applicable today. However, rapid and iterative design and prototyping is more important now than ever, due to the amount of new ideas and products releasing every day, with the highly accessible and easily scalable invention of SaaS and cloud services.

Lewis and Riemann make very good points, but one point that I disagree with in particular is the decision to lean towards "plagiarism." It is a well-known fact that users like to stick with what they know and conventions with which they are familiar, but in this day and age, there are many reasons not to as well. If ideas always stuck with convention, innovation would be limited and new and upcoming ideas would not be able to flourish. In addition, there are often obstacles as well, such as patents, that disallow new products to stick to a universal convention.

Alex Javad - 1/28/2013 14:26:01

The Lewis & Rieman design cycle has a more detailed, and specific "Design" phase as we would find in the three stage cycle described in lecture. Not only that, but in the Lewis & Rieman cycle... the "evaluate" phase is known as "Test Design with Users" blends into the "design" phase because we must also "Build the Design", "Track the Design", and "Change the Design"... ALL for the new design... the one we are iterating on.

I believe nowadays with SAAS companies such as Amazon, Dropbox, and eBay... this design process would work just fine. It follows a Test-Driven as well as Behavior Driven design which meets users needs... and if not... the design undergoes a new iteration through which features are modified to meet user needcs.

I really can't argue with their design. It even meets safety needs. But in the situation where a prototype is needed quickly... we could take out the "think about it" phase so we just get an idea of what the U.I. looks like.

Tony Wu - 1/28/2013 23:34:34

The Lewis & Rieman design cycle seemed like a more descriptive explanation of the cycle described in class. It was so similar that as I was reading, I didn't even know it was the Lewis & Rieman design cycle, I had believed it was the cycle discussed in lecture! L&R's cycle is about figuring out what tasks users seek to accomplish, designing to achieve those tasks, developing models to test, and testing how users feel about the modeled design. It follows the design, prototype and evaluate cycle very closely.

A significant difference between "shrink-wrapped" software and web applications is the ease of updating. For shrink-wrapped software, the software is sold in it's final form and is basically "you get what you bought". On the other hand, web applications can be more fluid and can be constantly updated as necessary. Although there is this key difference, the design process still holds equally for both. Web applications merely allow for more communication between user and developer via the internet and also software updates. Because of this, most shrink-wrapped software developers must test and redesign more than web application developers. Their product must be in a final complete form when released.

I almost entirely agree with Lewis & Reiman. The only thing I slightly disagree with is the section upon "plagiarizing". They mention that an existing paradigm is easier to implement, which is completely true. They seem to discourage creating one's own system. I, on the hand, would encourage others to be creative and to try to design new and more efficient conventions. I would happily take the extra time to learn an interface that I don't entirely understand if the benefits and boost in efficiency or convenience is worthwhile.