The Design Cycle and Brainstorming

From CS160 Spring 2014
Jump to: navigation, search

Slides

Media:Cs160-sp14-02.pdf

Readings

Optional Readings

Videos


Reading Responses

Weishi Wu - 1/22/2014 21:14:05

Comparing the three stages mentioned at class, I think the Lewis & Rieman design cycle provides more important supporting details, yet follows the same way as ‘design, prototype, evaluate’. They also focus on identifying target user group's need, starting with low fidelity prototype instead of high fidelity, gain design experience from existing UI, etc. These details are important aspects to concentrate on for UI designer.

The basic point and design processes mentioned from the article is well presented. While comparing to software design & analysis process to airplane industry is inappropriate, at least in these days when there are tons of new apps in the market every day. The testing methods between these two industries are biased, and the cost of software testing is getting down with usually shorter design/constructing period. Testing the a jet airline's structure could use complex CAD, FEM software like Ansys/Adams plus expensive real plane stress test, which can take a long period and spend a significant amount of money. The app development period is much shorter.

For today user group meeting for large system product analysis, in the design stage, instead of just talking to random user group, I would interview with extreme users, but test my final product with normal ones. This is because by talking to extreme users, for example, if I plan to design a pc game user interface I probably will spend time talking to those crazy pc gamers first. From it designer will gain more inspiring thoughts because this type of user spend a lot time with the products, and will definitely yield some surprises ides/improvement about the application/product. Then evaluating the high fidelity product with normal users since they will be the majority of consumers.


Tristan Jones - 1/22/2014 22:04:05

1) The design talked about in lecture is pretty similar to what Lewis and Reiman talk about in their book: the only caveat is that theirs has a bit more steps. Besides "test the design" and "plagiarize", if you expand out all the steps of "design, prototype, evaluate" you get pretty much the same thing. Lewis & Rieman just spell out the implicit steps. I guess that's good for a book, but for a quick mnemonic I think "design, prototype, evaluate" wins for simplicity.

2) It's like asking the question "Do we design ships the same way we did 100 years ago?" and the response is always going to be some mix of "yeah kinda" and "no not really". Today we've got 100x faster computers, better compilers, better debuggers & profilers, and better crashmetrics reporters. It's much easier to write complicated software today. But back then it was much harder to fix bugfixes after you shipped (after all, you couldn't just send a floppy disk with a sw patch on it). So now developers can launch early with just a MVP and add features on later. However, the core process of 1) design 2) prototype 3) evaluate 4) repeat hasn't really changed since then, and I doubt it will in the near future.

3) This model is not really effective for super large software projects. I've read about the development of AAA videogames and these organizations spend *huge* amounts of time planning. It's totally necessary since 1) it takes a huge amount of work to design the game 2) making assets takes up >70% of the time 3) missteps are extremely costly 4) how do you deal with huge teams 5) also, how to deal with teams across different timezones. Back when this was written I think it was meant to apply to small (like <20 people) software projects. Nowadays, software projects are huge (GTA V had a team of 400-500 working for 3 years). A different set of rules apply, and their book needs to be adjusted as such.


Michelle Nguyen - 1/22/2014 21:40:17

The Lewis & Rieman design cycle follows the three stage cycle that was described in lecture. However, what sets the Lewis & Rieman design cycle apart from the standard three stage cycle is its focus on the tasks of the application. Knowing which tasks must be addressed is the core of the design stage. For instance, in the design stage, the designer tries to figure out what tasks the application needs. The designer must discuss with the potential users to formulate the functions the application should have, and also look at current technology to see what features may need to be emulated. Prototyping then follows, and the evaluation stage is performed by testing the design with users by asking them to attempt the tasks. This then iterates as necessary.

Now that most mobile applications can be downloaded through app stores, their argument about the design process does not hold equally for today. Previously, it was necessary that the sold product would be the final, complete product. Updates in the future would take the form of a new version of the product that must be bought again, usually taking place many years after the release of the first product. Now, with the app store, updates can be done frequently and can be downloaded instantly. Also, from the app store, the designer can easily receive feedback from its users, regarding bugs and possible new features or changes--often shortly after any new updates. Thus, the design process does not need to be so rigorous, as if the end product is the final product. They can release their product when they feel it is mostly complete, knowing it can easily be changed at any time. For instance, an app easily has a version 1.0.2 or 1.0.3, etc. Thus, there can be less iterations of the design cycle with the existence of the app store. There also follows a new cycle where evaluation is done using the actual userbase, and design changes are made accordingly. Likely, this cycle may never end.

For the most part, I agree with Lewis & Rieman. However, at one point, I felt they were too focused on the tasks. When the design team is roughing out the design, the text states that when someone proposes a new feature, it should support one of the tasks in the list of tasks. Otherwise, it should be ignored, or a task should be made that involves that proposed functionality. I feel that many ideas may be a good addition to the product despite whether or not they fit into one of the main tasks of the product itself. Thus, I don't believe an idea should be discarded for just that reason. I do believe a product should be able to adequately perform its main tasks, but a good product is not simply just its tasks. A discussion should follow about how that feature might improve that users experience, whether or not it is related to a task or not.


Gregory Quan - 1/22/2014 22:14:19

The Lewis & Riemann design cycle is very similar to the three stage cycle described in lecture. They both have elements of task-centered design, prototyping, testing, and iterating.

Their argument about the design process still applies today. In fact, since most mobile apps are downloaded over the cell network, applications can be updated and iterated on faster than when they were sold on shelves. One drawback of mobile applications is that designers must be especially conscious of battery, storage, network, CPU usage, etc. as all of these resources are more scarce than they are on desktops or laptops.

I do not necessarily agree with Lewis & Riemann's suggestion to 'plagiarize' or imitate existing interfaces or design paradigms. While it is helpful to make interfaces familiar to a certain extent, too much of this thinking could potentially stifle innovation. For example, if no one had thought to use multi-touch displays, our smartphones would not have fast, intuitive gesture controls such as pinch to zoom or swipe to go back/forward.


Jamie Cai - 1/22/2014 22:26:03

The Lewis and Rieman design cycle known as task-centered design is very similar to the cycle described in lecture except sprinkled with more evaluation. The general idea behind their cycle is that design revolves around a set of predefined tasks that are important to potential users. You choose tasks, create a rough design, evaluate that design against your tasks, create a mock-up, test+iterate that mock-up until it fulfills all defined tasks, build the final design/product, and lastly iterate through that as changes are needed. The task-centered design cycle essentially has two cycles - one that iterates through the mock-up, and one that iterates through the final product. However, in general the stages are still design, prototype, and evaluate, similar to the cycle described in lecture.

The one thing I disagree with is that I don't like how this cycle makes it seem like programmers have to sit idly by until the designers get the design absolutely right to fit the user-defined tasks. I believe that while the front-end is iterating, the back-end should iterate (or at least be farther along in the process of being built) along with it. Lewis and Rieman say that when creating the prototype, system functionality can still be in development, but I disagree with that because I believe a good prototype should showcase both design and functionality. That way, the user can get a more complete feel to how the product will look and work and can give improved feedback. Therefore, I believe design and development should be done simultaneously.

This also ties in with the second question of how the design process differs from the past times to today. Lewis and Rieman probably felt that the mock-up iteration cycle before starting to build the product was necessary because unlike today, it was harder and costlier to get new versions out to the public. CDs cost money, packaging cost money, advertising cost money, etc. Therefore, companies would want to make sure they had a top-notch, user-friendly mock-up so they could avoid spending money on releasing a new version for something as small as a design change. However, now that there is little to no monetary cost in releasing software to the cloud, companies feel less pressure on creating a perfect design before release. Therefore, the mock-up iteration cycle becomes obsolete, and companies can simply create one mock-up, one prototype (such as an MVP), and refine both the design and functionality of the prototype based on user feedback without worrying about release costs. This leads to the design/prototype/evaluate cycle that we talked about in lecture.


Christina Guo - 1/22/2014 22:29:22

The Lewis & Rieman design cycle includes all the basic stages of the design cycle described in lecture, but with more detail in the extra steps. It includes steps such as analyzing who your audience will be, which is something that should be done in the "design" faze of the three stage cycle, as well as a step for thinking quantitatively about your interface (such as the number of steps need to complete a specific task), which would presumably also be including when thinking of a design and before prototyping.

The general gist of the article, which includes critically thinking about your interface before designing it and prototyping, and testing and iterating to improve your interface, holds equally today for mobile applications. Before creating an app, you still need to analyze your audience, test your interface etc. However, with current mobile apps, changes can be rolled out quickly and quietly, with no extra cost for the user. As a result, (though it may not always be the best option), the app creator may use actual users (rather than people similar to the intended user) to test their interface. For example, less iterations can be done before the app is released to the public and more testing can be done afterwards. One way this can be accomplished with less stress for the user would be to roll out a change to only a percentage of users and test which option is better.

One way in which I disagree with Lewis & Riemann is the order of the steps 1.4-1.7. In their cycle, a design is roughed out on paper, the designer then thinks about changes to make, and then a prototype is created and tested. I think that it is possible to test the pen and paper design on users even before a prototype is created, so that any major difficulties with the interface can be caught earlier. This way, time is saved and fewer prototypes may be created.


Sijia Li - 1/22/2014 22:39:59

The Lewis & Rieman design cycle shares a lot similarities with the three stage (design, prototype, evaluate) cycle described in lecture. In the Lewis & Rieman design cycle, step 4 ("Rough Out the Design") and step 5 ("Think About It") serves as the "Design Stage" (Task analysis & " contextual inquiry) described in lecture; step 6 ("Create a Mock-Up or Prototype") can be viewed as the "Prototype Stage" ("Rapid prototyping") described in lecture; step 7 ("Test the Design With Users") is the same as the "Evaluate Stage" ("Evaluation") described in lecture.

According to Lewis & Rieman design cycle, there are 11 steps to follow.

1. figure out who's going to use the system to do what: As designers, we need to have deep understanding of the users themselves, e.g. an awareness of the users' background knowledge. Contacts between designers and users in early stages are essential for a good and successful design.

2. choose representative tasks for task-centered design: As designers, we should pick up some representative tasks which the system we are going to develop will be able to accomplish. From these basic representative tasks, we can further expand the system into any level of details.

3. plagiarize: Usually, looking into the existing system/interfaces could be a good start. We can build ideas from existing programs/systems. Also, this step reminds the designers that deviating too much from the existing interaction paradigm may not be a good idea since the risk of failure is too high.

4. rough out a design: This step is like a "discussion section for designers". The designers should have a lot of discussion before formally making a prototype.

5. think about it: Right before developing a prototype, the designers should take several structured approaches to find out the strengths and weakness of an interface before building it.

6. create a mock-up or prototype: A prototype is needed to show to the users so that further information can be gleaned.

7. test it with users: There will be problems that only appear when the prototype is tested by users. Real-world testings will further improve the interface to fit into real-world applications.

8. iterate: It is crucial to repeat the testing steps, since a change to the current version of prototype may bring another problem! Iterations need to continue until the specific usability objectives are met.

9. build it: One key thing in building the interface is to build it for potential changes. Future modifications should be easily implemented. Modular design is strongly preferred.

10. track it: It is crucial that the designers need to get real feedback from their users.

11. change it: Be prepared for future updates so that the interfaces can be fit into current real-world application.

The arguments in this article are still mostly hold for today. However, there is a big difference between how products were sold 20 years ago and how software are sold today. Today, most mobile applications are downloaded through app stores. That means updates are very common, rapid, and easy to take place. Users do not have to travel to physical software shops to purchase newer version; instead, they can just click the "update" button. As a result, the design cycle can be shorten by a lot! The designers do not have to worry too much about modifications since if there are changes they can just post a update patch.

There is one thing I do not agree with Lewis & Rieman. I do not think their step 5 ("Think about it") should take place before step 6 ("Create a Mock-Up or Prototype"). Unlike building an airplane, developing a software does not involve actual physical manufacturing. When you are building a new airplane, it makes sense that you need to first model the airplane on computer using special industrial software to test it before we actually build a physical prototype because if there are problems, it is much easier to change things on computer or paper than change physical metals; also it saves a lot money and time. However, there is no physical manufacturing step for software development. When you are developing a interface/software system, you have to have a prototype to "think about it" after previous "design stage".

Thanks. Sijia Li


Sijia Li - 1/22/2014 22:41:47

The Lewis & Rieman design cycle shares a lot similarities with the three stage (design, prototype, evaluate) cycle described in lecture. In the Lewis & Rieman design cycle, step 4 ("Rough Out the Design") and step 5 ("Think About It") serves as the "Design Stage" (Task analysis & " contextual inquiry) described in lecture; step 6 ("Create a Mock-Up or Prototype") can be viewed as the "Prototype Stage" ("Rapid prototyping") described in lecture; step 7 ("Test the Design With Users") is the same as the "Evaluate Stage" ("Evaluation") described in lecture.

According to Lewis & Rieman design cycle, there are 11 steps to follow.

1. figure out who's going to use the system to do what: As designers, we need to have deep understanding of the users themselves, e.g. an awareness of the users' background knowledge. Contacts between designers and users in early stages are essential for a good and successful design.

2. choose representative tasks for task-centered design: As designers, we should pick up some representative tasks which the system we are going to develop will be able to accomplish. From these basic representative tasks, we can further expand the system into any level of details.

3. plagiarize: Usually, looking into the existing system/interfaces could be a good start. We can build ideas from existing programs/systems. Also, this step reminds the designers that deviating too much from the existing interaction paradigm may not be a good idea since the risk of failure is too high.

4. rough out a design: This step is like a "discussion section for designers". The designers should have a lot of discussion before formally making a prototype.

5. think about it: Right before developing a prototype, the designers should take several structured approaches to find out the strengths and weakness of an interface before building it.

6. create a mock-up or prototype: A prototype is needed to show to the users so that further information can be gleaned.

7. test it with users: There will be problems that only appear when the prototype is tested by users. Real-world testings will further improve the interface to fit into real-world applications.

8. iterate: It is crucial to repeat the testing steps, since a change to the current version of prototype may bring another problem! Iterations need to continue until the specific usability objectives are met.

9. build it: One key thing in building the interface is to build it for potential changes. Future modifications should be easily implemented. Modular design is strongly preferred.

10. track it: It is crucial that the designers need to get real feedback from their users.

11. change it: Be prepared for future updates so that the interfaces can be fit into current real-world application.

The arguments in this article are still mostly hold for today. However, there is a big difference between how products were sold 20 years ago and how software are sold today. Today, most mobile applications are downloaded through app stores. That means updates are very common, rapid, and easy to take place. Users do not have to travel to physical software shops to purchase newer version; instead, they can just click the "update" button. As a result, the design cycle can be shorten by a lot! The designers do not have to worry too much about modifications since if there are changes they can just post a update patch.

There is one thing I do not agree with Lewis & Rieman. I do not think their step 5 ("Think about it") should take place before step 6 ("Create a Mock-Up or Prototype"). Unlike building an airplane, developing a software does not involve actual physical manufacturing. When you are building a new airplane, it makes sense that you need to first model the airplane on computer using special industrial software to test it before we actually build a physical prototype because if there are problems, it is much easier to change things on computer or paper than change physical metals; also it saves a lot money and time. However, there is no physical manufacturing step for software development. When you are developing a interface/software system, you have to have a prototype to "think about it" after previous "design stage".

Thanks. Sijia Li


Allison Leong - 1/22/2014 22:55:24

The Lewis and Rieman design cycle seems to be very similar to the design, prototype, and evaluate cycle described in lecture. In both design cycles, the designer should begin with an idea, think over the idea, create a mock up of the idea, and then evaluate its efficacy at accomplishing the task required. However, Lewis and Rieman design cycle seems to put a much larger emphasis on keeping the users' habits and needs in mind throughout every single step of the cycle. In the initial design phase, the functionality of the application should be determined with a deep understanding of the users. Once an interface has been prototyped, the evaluation process should involve a "cognitive walk-through" by the designers, but more importantly, the prototype should be shown to users in order to catch any of the designers mistakes and misunderstandings.

To answer the second question, Lewis & Rieman's argument about the design process should hold even more so today than it did in the era of "shrink-wrapped" software. Because mobile applications are now downloaded through app stores, it is now easier for users to have access to oftentimes very similar versions of the same type of application, increasing the importance of a good user interface as a way to differentiate one app from another. Apps must also continuously make improvements on their features and designs in order to stay on the cutting edge. App development is a continuous process because updates are so readily available through app stores, and it is important to keep the user in mind with each new iteration.

I disagree with Lewis & Riemann that it is sufficient to test only the "representative tasks" in an application. Although it may be costly to test all features of the app, I think that it is important to do so in order to comprehensively test the usability of an application.


Kilim Choi - 1/22/2014 23:08:44

Lewis & Rieman design cycle is identical to the one described in the lecture which emphasizes in coming up with a design first, then prototyping based on the initial design, evaluating the prototype with users and repeating the above 3 steps again.

Even for mobile applications today, same design process(design, prototype and evaluate) hold. For instance, recently with the introduction of ios7, app designers had to come up with a new design fitting for the app in order to be compatible with the upgraded operating system, prototype the design, evaluate the prototype and repeat the whole process again. Although, there has been no changes in design process, I believe that the design cycle has expedited with the advancement of technologies. Nowadays, designers can get brutally honest feedbacks from users almost immediately just by looking the reviews for the softwares whereas in the past, designers had to seek out users' opinions. This can help save the cost, and allow faster developments than in the past.

I think that one thing missing in Lewis & Rieman's argument is that that designers should evaluate their designs with the interactive ui/ux. As opposed to the paper mockup, live and dynamic ones allow users to freely interact with the app. This can yield much more interesting behaviors like the ones not displayed through the static, paper mockups. We have to keep in mind that users are unpredictable beings that can act randomly. In my opinion, live apps capture such behavior the best and can be much more effective in improving the app.


Stephanie Rogers - 1/22/2014 23:22:08

Compare and Contrast: The task-centered design process explained in the book is remarkably similar to the three-step process explained during class. While it definitely focuses more on detailing specific tasks a user might perform, I feel like that's just a more specific way to design: the initial stage for the 3-step process. The task-centered design is a more-detailed and heavy on the planning approach, having the designer really consider who is using the system, how they are using it, how it has been done before, and then finally using the word "design." This could all be grouped under the one step of design, so I would argue the three-step design is simply a higher-level breakdown of a design cycle. While it's call task-centered, it's still very much focused on the users, encourages continued contact with users, and advocates awareness of user needs at all points in the process, just as described in class. Obviously they share the point of using iteration to improve upon a design in common. In both cases, the purpose is to define a process to help avoid design problems and build effective interfaces. The book's task-centered design process is simply a bit more spelled-out and formalized, detailing specific parts of each step from the class, and adding a few key points such as tracking the build afterwards.

How it's different today: Iteration at the implementation level, being able to rapidly update and upgrade software, has become more relevant today, especially in web applications, where the company controls when updates are pushed (AGILE). I would argue that implementation becomes an essential part of the design process: rather than testing with interactive prototypes in a user study, you can test an entire feature update with a huge chunk of your actual user base and compare results in A/B Testing. In general, your design cycle can be even more iterative, with new iterations of the product, application, or web service more readily available to the user in the mobile market than in a physical store.

Disagree: I understand their point of plagiarizing for intuition's sake, i.e. staying consistent with old paradigms so users can transfer prior knowledge to new contexts. However, I think this is extraordinarily limiting! If you have a design that is (even potentially) more effective, efficient, or easy to use it may be worth it to try it out. There is obviously a cost-benefit analysis, but in many cases, changing the smallest things, even if there is some overhead to learning, may be worth it. Users don't like change, this is true, but often complaints due solely to change are temporary and often lead to an overall better experience for the user down the road.


Christopher - 1/22/2014 23:33:53

The Lewis and Rieman design cycle is similar to the three stage cycle in that it puts a strong emphasis on planning out the design of the user interface. However it also emphasizes the importance of iterate in the user testing process to determine what the most optimal design for the user interface is before building. In addition, it mentions that the purpose of evaluation is “not to prove the interface, but improve it,” indicating that the job is not complete when the product launches; it must be revised to address changing user needs and potential errors found.

In today’s market, mobile applications can be downloaded and updated through online app stores. This makes the design process much more flexible with product launches in that it allows designers to obtain immediate feedback from users and makes it easier for them to introduce updates quickly in response. This is in contrast to the previous methods of in-store software purchases, where developers produced new user interface changes much less frequently due to the costs of manufacturing these products.

I disagree with their approach in regards to plagiarism. Where do you draw the line when copying elements from other user interfaces? I personally have faced this conflict in developing a mobile application for my capstone project. I'm not sure what elements and how many elements of the UI are safe to copy into my UI. The article doesn't doesn't explore this concept in further detail.


Steven Pham - 1/22/2014 23:52:45

Lewis and Rieman’s design cycle is very similar to design, prototype, and evaluate. The first three bullet points: figure out who the user is and what they want to do, choose representatives, and plagiarize are part of the design phase. Rough out a design and create a prototype are the prototype phase. Think about it, test with users and iterate is part of the evaluation phase. Lewis and Rieman’s cycle also has a development phase which is additional to the three stage process from class.

Lewis and Rieman’s design cycle is very relevant to today’s software. A lot of companies are adopting agile for web apps and mobile apps which is very close to their process. Their design and development process is executed with the notion that change is inevitable before, during, and after a cycle which is agile. App interfaces change constantly like the facebook app and thanks to the app store system users can update more often than the days of Microsoft Office. One difference is that app developers don’t really have personal contact with users as much since their release cycles are so rapid.

Given the time the article was written, the cycle seems to assume that most software companies are well established and have a lot of workers vs today’s start-up companies. In large corporations there are teams dedicated to design but in start-ups everyone contributes to design and time in between release cycles are shorter. Another point I disagree with, to some extent, is the sticking to what users already know from other programs. Apple destroyed its competition by investing its efforts into touch screen gesture for the iPhone while other companies stuck to the button phone paradigm. Now almost all phones are touch screen because users buy more of it.


Hongyi Li - 1/23/2014 0:21:41

1) The Lewis & Rieman design cycle is in essence similar to the design-prototype-evaluate cycle in lecture. The Lewis-Rieman cycle first involves design-related tasks such as identifying the overall direction the system is going to take, figuring out the representative tasks that the system will perform, comparing this preliminary design with existing similar designs, and thinking through this design using certain metrics. Then it similarly involves prototyping this design and evaluating it by testing it on real users.

2) With applications now interconnected, especially through the cloud, many of the testing and evaluation techniques mentioned in this article can be altered to better suit this greater connectedness. For instance, certain usage metrics can be embedded in the application itself, and sent to the developer automatically, eg mean time between use, number of times 'cancel' was pressed (as a measure of ease of making errors) etc. Also, feedback can be done through comments on the app store and through online surveys. Therefore, the main 'evaluate' steps in this design process are changed.

3) I agree with Lewis & Riemann for the most part in that since the main purpose of your application is the tasks it can complete, it is beneficial to make the completion of those tasks as easy as possible. Also, at times it is best to 'plagiarize' instead of coming up with a new system. However, this focus on only tasks is not enough sometimes in making a great application. Sometimes, other factors such as better aesthetics and enforcing better modularity etc may take precedence over strictly making tasks easier and simpler. Also, in terms of 'plagiarizing', when an existing system eg MS-DOS or early UNIX is dominating a sphere, it is sometimes beneficial not to go with the old design, but come up with what you feel is a better design eg Mac OS's GUI system supplanting the text-based earlier OSs.


Tiffany Ng - 1/23/2014 1:22:14

Lewis & Rieman's design cycle is fairly similar to the three stage cycle described in lecture. It has the general same ideas of designing, prototyping, and evaluating, but it breaks the cycle up into more in-depth stages. One of the main differences I spotted was that Lewis & Rieman's design cycle tells the programmers to "think about it" and do cognitive walkthroughs to find issues in a design before prototyping. However, in the cycle described in lecture, we list walkthroughs as part of the evaluation stage (after prototyping) where we use the walkthrough technique to "test" the design.

In general, I think Lewis & Rieman's design process is good. However, because these apps will be available for download through app stores instantly and because we live in a fast-paced, technologically-advanced society, design processes need to consider that testing and revising or improving a mobile application needs to be made quick after first releasing the app so that one can retain users. Mobile applications need to be constantly updated to fix bugs and improve design to satisfy users unlike the old days, where there was more time to improve before having to roll out a physical copy of an updated software.

I disagree with Lewis & Riemann in that one should "plagiarize". Although you may be re-inventing the wheel, I think that if someone creates a design from scratch and does not automatically give in to existing design norms or shortcuts, someone might come up with better, more efficient ideas in design that could revolutionize designs. Although this is highly unlikely, the point is that I think that instead of quickly defaulting to a trivial design norm, one should at least stop and think if that's what they really want, "is there a better design?" This helps to keep the creativity going.


Myron Chen - 1/23/2014 7:24:07

The Lewis & Rieman design cycle works similarly to the three stage cycle described in lecture. Steps 1.1, 1.2 and 1.4 seem to follow closely with the design portion, steps 1.6 and 1.9 follow the prototyping phase, and 1.7, 1.10, 1.11 follow the evaluation phase. What differs is that Lewis & Rieman that you should find an existing interface that works for users and build off it, something not found in the three stage cycle. Step 1.8 follows the cyclic portion from evaluation back to design.

I do not believe their argument about the design process holds equally for today. Because most mobile applications are downloaded through app stores, it can be very easily to make side-by-side comparisons to other products. Because of this, being creative can be a way to make you stand out instead of plagiarizing and building upon another's idea.

I disagree with Lewis & Riemann about having to "plagiarize" and build off a existing interface. While it can be useful in many scenarios, it does not necessarily have to hold true. Especially now that users can download software with a touch or a click of a button from the app store, being creative in your design can be a way to attract users to your application.


Shizhan Yuan - 1/23/2014 9:55:54

1) The Lewis & Rieman design cycle includes specific steps that almost perfectly match each stage in the three-stage cycle. 'Rough Out the Design' is the design stage in three-stage cycle, 'Create a Mock-Up or Prototype' for prototype stage, and 'Test the Design With Users' as well as 'Trach the Design' for evaluate stage.

2) The fact that most mobile applications are sold through online app stores currenly significantly changes the 'Track the Design' step because the designers do not have to struggle to contact customers. Instead of using customers hotlines or holding user group meetings, designers can read all the feedbacks posted online by the users. This features make it way easier and more convenient for designers to track the feedback, find and solve the problems, and imporve their applications.

3) In the 'Create a Mock-Up or Prototype' step, the author says 'The entire design doesn't need to be implemented at this stage. Initial efforts should concentrate on parts of the interface needed for the representative tasks.' I disagree with that because problems and issues might arise. If the initial efforts are only focused on the representative tasks, there might be some other subtle parts in the design that somehow works differently with the tasks. These potential functionality contradictions will take more effort to change and re-design. Therefore I think when you are initially designing the product, designers should think about the bigger picture instead of just focusing on the tasks.


Anju Thomas - 1/23/2014 11:33:55

Lewis and Riemann’s task centered design process is similar to the three stage process, but with additional steps. For instance, in the beginning of their design process they learn user backgrounds, associate the tasks to be performed by the Design, look at existing interfaces to create a familiar interface for users and then design, which includes the first stage of the cycle. Similarly before making a prototype - the second stage of the three cycle process - the task centered design process suggests that the designer performs an engineering analysis andn assesses the cost before making the concrete prototype. To evaluate the design, the process suggests testing with users. Like the three stages that continue to cycle around, Lewis and Riemann then propose iteration of the whole process until the specific usability objectives are reached and the desicion balances the cost and benefits of improvement against the need to get the product into the market.

The argument for the design process holds mostly today though with a few changes. It is similar to the shrink wrapped software in that designer would still have to go through the main steps such as research the user background and tasks, plagarize, think about it, create a prototype, test with users and build the design and make necessary changes. However, a change that would be needed is that the process can be cut down more for web applications as there are quick and easy softwares that can be used to prototype. Thus the designers would not need to necessarily create the whole design on paper, but instead might choose to directly create a rough prototype using software after thinking about it. Also once the design is fully build it can be continued to tested and updated much easily through web reviews and by simply uploading the new version online that can be accessed by all users and not just a select few.

I disagree with Lewis and Riemann in that the designer might want to research previous similar applications that successfully met the user’s needs and analyze it. Then the designer can find a user and assess how they currently perform their tasks with existing software and what changes they would like before roughing out a design. This can help minimize the number of iterations needed before creating the final design. Here the designer would be more aware of the user’s needs and tasks before they begin roughing out a design and creating a prototype. Another problem could also be with plagarizing as I think that there should be some distinctive feature that separates the new application from the previous ones though they possess similar interfaces. Otherwise, it would be like another social networking website that would possess almost the same features or interface as Facebook, in which case the users might stick to the one they have. I think this is similar to the continued popularity of Facebook despite similar social networking sites such as Google plus that have been introduced.


Wenxi Xu - 1/23/2014 12:44:57

The Lewis and Rieman design cycle is similar to the three-stage design cycle that we learned in lecture. There are series of steps that correspond to the design, prototyping, and evaluating steps in the three-stage cycle, and they share the same sort of intent. First, design must identify the crucial elements, such as users, actual real-world tasks, and necessary UI features. Secondly, prototyping must be rapid and low cost, and must be able to accomodate changes to the interface based on feedback. Finally, evaluation of the interface must occur with real users, and errors or surprises recorded to be used in the next iteration of the cycle.

In the modern world, this sort of design cycle becomes less relevant. As products are more readily available, the design process must become more efficient; the Lewis and Rieman cycle is longer and more complex than the three stage cycle, and it may not be economical to follow all the steps anymore. In particular, testing the design with users may have occupied more time and resources in the past, while it may not be wise to spend as much time now as quick patches and continuous, fast feedback from users provide the same sort (but maybe not quality) of information. It depends more on the target audience, however.

I disagree mostly with the third step, plagiarize. My thoughts are if a new feature is more efficient or intuitive than what is already implemented, it may be more valuable to implement it and educate users how to use the new feature rather than sticking to the status quo. The author of the article may be saying that overcomplicating by adding many new features may overwhelm the user, and I agree with that. However, by taking a risk, it is possible that the new feature/implementation would become more popular than what the users are familiar with.


Derrick Mar` - 1/23/2014 14:04:06

1. Personally, I believe Lewis & Rieman's design cycle almost parallels the three stage design cycle. While L & R's explanation is more detailed, the basis of the three stages are clearly apparent. L &R talk about identifying users and tasks which is the same as the design stage. L & R's explanation of creating mock-ups (first on paper then on UIMS) is the same as the prototyping stage. Lastly, testing the design and making improvements is the same as the evaluate stage. The only difference is that L &R include long-term design improvements when the product is already to market.

2. While L & R's design process still has much validity, many designers are taking a leaner approach to designing and iterating user interfaces with the capability to push often and quickly (e..g updating apps through the app store). Unlike what L & R states which is designing and iterating the UI several times until product launch, I believe most designers nowadays launch earlier and change the design often according the user feedback on the app stores.

3. First, I find it pleasantly amazing that many of the assertions in L & R's book 19 years ago still apply to the modern design process today. However, with the advancement in communication and prototyping technology, I disagree with some of their thoughts on prototyping. With tools like Balsamic and FluidUI combined with the likes of Facebook, you can push out multiple versions of possible UI's to potential users in rapid speed. There's no need to argue with designers endlessly on paper on which designer works the best. Instead, push out multiple versions to potential users and get their feedback.


Milkent Samsurya - 1/23/2014 14:13:47

On the surface, Lewis & Rieman design cycle is more detailed as compared to the three stage cycle. Lewis Rieman design cycle also tend to depend mostly on the feedback and options from potential users where the three stage cycle does not depend heavily on users' view as it is believed that users may not necessary know what they want.

Most of their augment still hold today however with the rise of technology comes the ease of communications between the users and the company. "Track Design" no longer has to hire people to talk on customer hotline with users instead users can now simply reviewed the app on the app store. "Change the Design" section might also change with the rise of apps in the app store. Most apps nowadays has 2 to 3 years life cycle and hence redesign the app does not necessary maintain the usability of the product. Most of the time companies have to venture into new opportunities and produce new apps and upload to the app store.

I disagree with Lewis & Riemann's "Build the Design" "Track the Design" and "Change the Design". Nowadays companies have more freedom to change or improve their product through user's reviews at cheap price or at most time no cost at all. These encourage companies to adopt the three stage (design, prototype, evaluate) cycle described in lecture.


Jelson Santos - 1/23/2014 14:50:34

The task centered design process describe by Lewis and Riemann takes the three stage cycle described in lecture (design, prototype, evaluate) but it takes extra steps during the process in order to enhance the overall process for the user and the designer. Plagiarizing was one of the steps described in class which it will save a lot of time for both users and designer since users will be familiar with the UI and the designer won't have to create a UI from scratch. Tracking and changing the design is also important because markets change quickly and what's good right now it may not be the same in a couple years. Lewis and Riemann seems to take care of issues sooner than later with extra steps that the design process covered in class may now be able to detect until final steps in the process which can be costly.

The current apps pretty much follow the same process as described by Lewis and Riemann, the process haven't change. Probably the only difference between shrink-wrapped in stores and app stores is the way it gets updated, through app stores developers can push changes in real time and the user can immediately update the UI version they have, whereas, the shrink-wrapped way can take more time.

I disagree with Lewis and Riemann in building after iteration. I think building the product should be done earlier and run the test and iteration based on the product we have. I believe the product should be built part by part with each part having its own user tests and iterations. This also can be easier for the user to interact with a fully working product rather than the designer helping the product work properly.



Dalton Stout - 1/23/2014 15:10:51

The Lewis & Rieman seems to have the same core structure of the three stage design cycle we saw in lecture, although with a few more detailed intermediate steps in between. Essentially, both cycles plan a design, build a model, and then test/improve the model. Something that is notable about the L&R cycle though is that it specifically includes a 'research' phase in which developers brainstorm ideas about who is using the system. Perhaps this is implied in the design phase of the three stage cycle, but it seems to be one of the most important parts of the whole design process. As the book says, a well designed app designed for the wrong purpose is likely to fail.

Much of design principles remain that same, even for mobile apps. It is still important to plan who your market base is and what they will use the app store. It is still important to plagiarize (i.e. follow conventions that users are used to). It's also still important to iterate and track your app. The main difference in the modern app environment comes from the ordering of some of the steps. When most software was sold in store, it was rather cumbersome to put out an update or a bug fix and even harder to get a lot of feedback prior to release. These days, people can update any app on their phone in a few strokes. Its probably more desirable for the app team to build the app and get it functional so that they can release it to the app store and start getting feedback immediately. Then they can start to iterate and track their app and get reviews through the app store which can help them bug track immensely, as well as get an idea of how people feel about the current features and new features they'd like to see.

Most all of the steps I was on board with. L&R have created a robust design process. The only points that did not sit quite right with me was the step about the "Representative Tasks". I understood the concept, but to me it seems like an odd and inefficient way to encapsulate the desired list of features. One important Task could be missing but go unnoticed, or maybe the Representative Tasks' coverage of the features could have a hole. I know they were trying to bring a concreteness to the feature design process, but it seems to me that their could be a better way, perhaps through testing of similar products or more research.


Daniel Kang - 1/23/2014 15:22:16

The Lewis & Rieman design cycle seems to be very similar to the three stages: design, prototype, and evaluate. It would seem that for the Lewis & Reiman design cycle, evaluation plays a role even in the prototyping phase. With constant evaluation and testing, iterations can be made before the product is released. This does not mean that the released product is not evaluated. The tracking of the product seems to be very closely tied to the evaluation of a product. I think its great that Lewis & Rieman believe in constant evaluation and iteration of a product but at the same time I disagree because I dont like that a lot of developers are focusing on pushing a product out to the public even if there are bugs in the code for the sake of getting the product out and getting feedback. This means that I will always be asked to update my software and multiply that by all the apps that I have on my phone and that means I have to update many different applications more than I would like to.


Ravi Punj - 1/23/2014 15:34:29

The Lewis & Rieman design cycle consists of the steps - task & user analysis, re-appropriating pre-existing designs, prototyping, analysis, testing, iteration and implementation. This is very similar to the "design, prototype, evaluate" cycle described in lecture in the sense that the latter is a more abstract version of the former. The "design" segment of the cycle includes task & user analysis, and research of pre-existing designs that can be re-used. Similarly, the "prototype" and "evalute" segments are essentially the same as later steps in the Lewis & Rieman cycle.

While a lot of the design cycle can still be valuable for current day apps on the mobile-store, it is important to understand the developers receive a much larger volume of feedback. In that respect, I anticipate that iterations are more frequent and incorporate more user feedback. Recently releasing software as a "beta" offering has also meant that apps can be published as long as there are no critical bugs and usability and user experience can be improved through crowd-sourced feedback after critical functionality and features have been established. A lot of apps also use hot code pushes (common in HTML5 apps) that don't even require an upgrade from the app store (just need an app restart), thereby reducing the interval of iterations, making it a virtually continuous process.

While I agree with Lewis & Riemann that a requirement analysis and strict specifications do not lead to the best design process, a task-centric process creates other logistical problems such as scoping work within a team. Sometimes features overlap multiple tasks and during the implementation stage this can cause a dilemma between assigning programmers to tasks or features. Therefore, I would suggest a two-pronged approach where development is undertaken on a feature-by-feature basis but the list of features and how they integrate are informed by a task-analysis. This does not necessarily change the design process put forward by L&R; however I felt this was important implementation detail was underspecified.


Nicholas Dueber - 1/23/2014 15:37:07

Question 1: There are a lot of similarities in the design cycles. The Lewis Rieman design cycle emphasizes finding out what the consumer is used to using and what they want it to do. The three stage design cycle gives the designer a bit more flexibility in the sense that it can be an untraditional approach as long as it is functional. Both design processes encourage evaluation. The metrics of the evaluations are ambiguous, but the gist is that the user is able to seamlessly use the program.

Question 2: For todays mobile market, their design process should be modified. It should be assumed that the product is able to be downloaded and opened. Past that, then nothing can be assumed. The product will have to go through the same evaluations steps that the described. The developer will have to decide how the app should look and what everything does. So in general, the design process can stay the same, only requiring a few modifications.

Question 3: I disagree with them when they say that the design and everything put into the program should help the representative task. There are plenty of applications that should have extra options. This allows the user to personalize that program, and potentially go beyond that of which the original purpose of the program was. The representative tasks should be clearly labeled, but there is something to be said for an application that gives more options and freedom to the user.


Andrew Dorsett - 1/23/2014 15:44:03

Essentially Lewis & Rieman design cycle is the same thing. The sections 1.4-1.8 is the act of designing, prototyping, and iterating. The biggest difference is more subtle due to the fact that the software was sold "shrink-wrapped". In this day and age software can be tested on the user, like how GMail was in beta for several years. Developers can put out a solid product and tweak the design after a significant amount of users have "tested" it in the wild. In Lewis & Rieman's example that was not the case. You would have to make sure what you released was as close to the final product as possible. This means more time evaluating, iterating, and prototyping. I disagreed with 1.3 portion on plagiarizing. It seemed too conservative in regards to exploring new designs.There might be an interaction that is new to a user but greatly improves their experience. Simply copying what everyone else does because people are familiar with it doesn't lead to revolutionary designs.


Maya Rosecrance - 1/23/2014 16:11:07

In essence the two design cycles are fairly similar in that they involve largely the same steps but The Lewis & Rieman cycle is much more linear. It starts with evaluation of users but then in 2 complete cycles of the design, prototype, evaluate wheel, the project is in essence finished unless more problems come to light or the project become out of date. It seems more suited to a software product where updates and fixes are difficult to do after release.

I believe that their argument on the value of a good design process continues to hold today because software or apps made without the user forefront in mind, invariably are less able to address the user’s pain points. With an app store however, the designers of an app get a lot of feedback even after the app is released and they are expected to update their app and fix any problems that users identify. Thus the product is not “done” when it is released but it continues on in the design, prototype, evaluate cycle. In essence, nowadays more iterative cycles are needed but the core idea of designing with the user in mind and then reacting to user feedback is still a very valid idea.

For the most part I agree with all the points mentioned in the article however I disagree with a few specific parts of Lewis & Riemanns first step. While I agree with all of it in reference to trying to extend or write an app for an existing system and in the general case, I believe that a slightly different approach is needed when doing something radically new. A substantially original product would also mean the plagiarization portion of the design process comes to be much less important. Implementing a bunch of familiar features may not be practical or useful when creating a new stand alone system such as the Mac evolution away from PC. When it was first implemented there was very little familiar about the UI and users had very little background on knowing how to navigate it. However it was a well designed UI so users were able to quickly figure it out.


Vinit Nayak - 1/23/2014 16:29:28

Lewis & Rieman design cycle (LR Cycle) is essentially the same as the three step cycle but they have broken down each of the three steps into very specific steps and even added steps in between the three step cycle. The LR cycle breaks the first step of "design" into determining the actual tasks the user want to do and choosing the appropriate system to do so. Then comes the actual designing part with the section entitled "Plagiarism". The LR cycle also seems to take more precautions against failure in between the design and prototype phase; it suggests user feedback and rough drafts before the computer version of the prototype is even begun. The traditional cycle does not place enough emphasis on the testing part of designing, and its need to be done after prototyping and after evaluating (done so by tracking the design in the LR cycle). Both emphasize the need to continually alter/change/update the design if necessary (hence a cycle).

I think the main gist of the process is the same, however the technology platform aspects change. They know that because it is mobile, whatever the application has to do it cannot be cumbersome, it has to be "quick" in a sense where it takes minimal clicks/swipes/etc to get the task done. That is a guideline that is set regardless of who the user is, simply due to it being a mobile platform. The limitation on the small variety of mobile devices (screen size/shape) also reduces the scope of the design. For example, anything that needs to be designed should look good in a rectangular screen (that is not too large), as opposed to a spherical or circular screen. These pre determined guidelines minimize the initial concept designing that would have otherwise been needed (also minimizing the creativity). Also, one level of design not needed at all is the physical (since there is none!) packaging that consumers must purchase. This also adds difficulty of being able to stand out as it prevents any physical creativity from showing.

I disagree with the plagiarize section of the Lewis & Rieman design cycle. Although it does make it easy to keep certain features standard and avoid the risk of having a design failure, it takes away the fun and creativeness from design at the same time. For example, on smart phone cameras, whenever the user took a picture, the camera stopped and the user was allowed to examine the picture taken, which was most likely adopted from standard point-and-click cameras. That was accepted and no one complained, but it was not the best. Nowadays, in cell phones, an indicator appears whenever a picture is taken and the camera is kept on so the user can continue to take fast sequential shots, allowing them to not miss any moments. This would never have happened if we had always "plagiarized" this standard feature that had been present early on in digital photography. In a similar fashion, simply because everyone knows what standard menu bars and buttons look like, does not mean they should be looked to first when designing. I believe it is essential to try to innovate and use common designs as a backup. True, it is a greater risk but it is a smaller price to pay to optimize a design that could end up saving time and/or resources.


Vincent Budrovich - 1/23/2014 16:32:33

The Lewis and Rieman design cycle is similar to the three stage cycle discussed in lecture, but they have their differences. They are similar in that both essentially ask you to design the core ideas of the interface using cheap methods, prototype that design with a more concrete apparatus, and then test with users to generate feedback and then start again. I believe they differ however in the focus on taking from software already released vs simply attempting to cater towards what the user will find most effective.

The current design process can occur with just one person who releases their creation into an app store, in contrast to the 'shrink wrapped' software that is general is output by larger companies making the software in teams. What Lewis & Rieman say about communication within teams and tracking the design are still important but the methods by which those goals are achieved has definitely changed with the proliferation of applications based in the cloud.

I disagree with them on the idea that you should attempt to copy things that are already out there. While it is true to an extent that the new product should be familiar, it does not necessarily need to be copied over.


Daniel Haas - 1/23/2014 18:12:29

The Lewis & Rieman design cycle, though it has more steps, is roughly analogous to the design, prototype, evaluate cycle described in lecture (1.1 - 1.5 = design, 1.7/1.9 = prototype, 1.8/1.10 = evaluate/iterate). The main difference seems to be that L&R wait until much later in the process to prototype/evaluate, putting more effort into the initial design. This makes perfect sense in a world where running user studies, iterating, and getting a new product to market is expensive: the better you do the first time around, the less frequently you need to release new products to market.

However, in the app-store model, releasing new versions and getting user feedback is incredibly cheap (actually, other than worker time, it's entirely free). This suggests a release-early, iterate frequently model more in line with the three-stage cycle proposed in class.

My main disagreement with L&R is their placement of "1.5: Think about it". It seems rather premature to be counting keystrokes with GOMS analysis before even having a prototype! Importantly, it constrains your thinking as a designer--you might be convinced by the "efficiency" of your interface approach before discovering that users think the high-level idea is silly or unintuitive.


Andrew Chen - 1/23/2014 19:28:42

I think the Lewis & Rieman design cycle is very similar to the three stage cycle described in lecture. In fact, the cycle outlined in lecture seems to be a compact version of the Lewis & Rieman cycle. For instance, the first five steps of the Lewis & Rieman cycle could be grouped under the design stage, step 1.6 could be associated with the prototyping stage, and the rest of the steps could be grouped under the evaluate stage.

Most of their design process, namely the general steps, still holds for today’s mobile applications. The fact that most applications are mobile today doesn’t change that there should be a clear design phase to flesh out the general functionalities, prospective users, and other general aspects of the application. The same can be said about a general prototyping and evaluation phase. However, what does change is the details of each step. Today, because of improvements in technology, the factors that need to be considered in each step changes. One big change is that apps cost a lot less to produce and distribute now than they did before.

I agree with Lewis & Rieman, not only with the general stages, but also with the centralized responsibilities of the Task-Oriented design cycle, because in this way, the users’ concerns are taken into account at every step of the way. Also, the iterative nature of the process promotes incremental changes, and thus the size of an iteration can be controlled, and also the users’ preferences always kept in mind. Furthermore, I agree with the concept of “plagiarism” described in the article, because while new ideas are welcome, many times convention is better, since people are generally more comfortable with it.


Ryan Yu - 1/23/2014 19:33:21

The Lewis & Rieman design cycle is quite similar to the three stage (design, prototype, evaluate) cycle described in lecture. In fact, it can, for the most part, be regarded as a more detailed and extended version of the three stage cycle. The two cycles can be analogized as follows: For the design stage, Lewis & Rieman detail three stages: (1) figure out who's going to use the system to do what; (2) choose representative tasks for task-centered design; (3) plagiarize. In other words, Lewis & Rieman recommend that the first thing that needs to happen is that the needs of the *users* must be recognized; this, in turn, can be achieved by things like "plagarism", where you look at other successful applications of the same nature, and use them as inspiration, extracting their good features out. The "prototype" stage of the three-stage cycle can be represented by Lewis & Rieman's stages: (1) rough out a design; (2) think about it; and (3) create a mock-up or prototype, which are all pretty self explanatory. Finally, the three-stage cycle's "evaluation" stage consists of Lewis & Rieman's (1) test it with users; (2) iterate; (3) build it; (4) track it; (5) change it, which essentially just consists of testing it with users, then noticing what things they approve of and do not approve of.

In today's world, when most mobile applications are downloaded through app stores, I think that the design cycle detailed in Lewis & Rieman's book is too detailed; the fact that applications are now primarily distributed through the web makes, in a sense, applications more flexible to risk taking. Developers, in this sense, can launch different releases more frequently, and can get feedback from users more quickly than if the software was "shrink-wrapped". (The feedback from users also primarily occurs through real-time feeds and data crunching, rather than surveys like in the "old days", so the aforementioned point is reinforced even more). In this sense, I think, for instance, that many of Lewis & Rieman's "evaluation" stages (detailed above) can be condensed into just "testing and making adjustments based on feedback and data". Essentially, the stages that Lewis & Riemann detail can be condensed and sped up.

The primary point in where I disagree with Lewis & Riemann is their placing of the "build it" phase in their workflow. I think that a designer should start building the initial phases of their application right after the prototyping, even if they build just a little bit. This way, they will have first hand knowledge of parts of their application that might be difficult to implement, and they can adjust their prototype/design accordingly. This would help to plan future iterations of the design cycle.


Gavin Chu - 1/23/2014 19:39:54

I think Lewis and Rieman’s design cycle is just a more detailed version of the three stages we discussed in lecture. Lewis and Rieman discussed the design stage in many steps. Designers must figure out the overall purpose of the app, consider the specific “tasks” that the app must have, compare ideas with similar existing apps, finalize a rough outline of the design, and reinact how the app is going to work in their minds. The prototype stage is simply creating a model of what the app actually looks look, which could start as a sketch. Lewis and Rieman points out that the actual implementation should be built to accept changes easily. The evaluation stage is very similar. Basically, you can speculate all you want, but you must test with real users to see actual results. The app then needs to be repeatedly changed for improvements.

I think Lewis and Rieman’s design cycle is still valid for applications downloaded through the app store. It’s clearly a very organized approach. It doesnt matter if the product is a software bought from the store or an app downloaded from the app store, the end goal for both is for the user to like and use the software/app, so focusing on user experience is extremely important. Downloaded apps can be accessed more easily. This only means developers must be extra careful designing their apps since more people will use it.

I agree that every steps that Lewis and Rieman mentioned are important things that a designer must do, however I believe the order doesn’t have to be followed so rigidly. From personal exprrience, many new ideas arise while building the prototype or testing the app. The cycle of planning, implementing, and testing should just be a very broad framework. For example a designer might go back and forth between the design and prototype stage many times before the evaluation stage.


Shana Hu - 1/23/2014 19:40:37

Whereas the three stage design cycle described in lecture consolidated the design process into generalized blocks of task analysis, rapid prototyping, and evaluation, Lewis & Rieman provide a more detailed approach which emphasizes focusing on specific tasks the interface should accomplish. These representative tasks should basically cover the entire system, and therefore provide a specific and realistic understanding of potential interaction with the product.

Now that mobile applications are easily released into the wild via app stores, the design process has become much more iterative than before. Whereas with "shrink-wrapped" software, which likely underwent many design cycles before being produced for the general public, modern mobile applications can quickly and easily integrate design iteration with production. It's now easy to release new features often and test them with real users (as Facebook often tests small features with select batches of users), rather than design behind closed doors for many moons before putting the product in stores. As a result, I think the modern technological climate makes it much easier for designers to communicate with users and address their needs, allowing design work to be more iterative and thus produce more useful and appropriate work.

I disagree that it is typically better to stick with what users know. I think if designers always follow existing trends in interface design, there is little room for improvement, which is problematic in an industry which thrives on innovation. Saving your users an extra keystroke or more is generally a good thing, and I think designers should strive to make the user experience as logical and efficient as possible. For example, Apple changed the way their computers' scroll directions were coordinated in order to create a cohesive interface between all of their products. Because mobile devices featured an upward motion to see more information below, Apple made their computers adapt the same motion, going so far as to even officially label it as "natural" scrolling. Although some users stumble a little when they aren't used to the command, most of the target demographic adapts quickly. By bucking the trend, Apple has successfully unified a simple but important interface interaction which threads across fundamentally different devices of mobile phones, tablets, laptops, and more.


Anthony Sutardja - 1/23/2014 20:52:09

The Lewis & Rieman design cycle really resembles the three stage cycle described in class. One could say that it's really the same thing. Although the Lewis & Rieman put a lot of focus on thinking about its users and developing mock-ups or prototypes to test with users, the three stage cycle described in lecture can begin with that as well. All-in-all they are the same process.

Even though the article was written in 1993, the design process definitely still applies even today. However, I would say that one change that one may consider is a heavier emphasis on the "testing" part of the cycle. The article notes how the people who create software should record how people use their devices for feedback. They have to get it right before it goes to market. Once the shrink-wrap software is sold, it's hard to update it.

That doesn't necessarily have to apply to mobile apps. I believe mobile applications allow developers to push out applications even faster. If an initial version has kinks and the developers receive feedback about it, they can easily make changes and distribute the changes instantly (unlike traditional software).

I don't agree with Lewis & Riemann on two things: they say that if some feature doesn't achieve any useful task, then it should be thrown out. The problem is that it's hard to define what a useful task is. I think cool but not-so-useful features can often add to the aesthetics of the software experience. It's also where a lot of experimentation for the new interfaces can happen. The second thing I don't completely agree about is plagiarizing UI's. I think copying other UI's is convenient, but if it narrows one's thinking to just that form of UI. Before the iPhone, all phones were similar and clunky. Sometimes it's nice to step out of the box and try something radically different. It might not always work out, but sometimes one can create an even better experience than what currently exists.


Lawrence Ng - 1/23/2014 21:18:12

The design cycle described by Lewis & Rieman is almost exactly the same as the three stage cycle described in lecture. I think it would be more accurate to say that both cycles actually start at the evaluate stage by characterizing the targeted tasks. It is clearly wiser to solve a problem that does exist than to solve one that may never exist. Following that, both cycles use the problem as a reference for designing the application, and then either making a mockup or prototyping the design. Both cycles place heavy emphasis on the evaluation stage; it is important to get user feedback to improve the product. Lewis & Rieman say to repeat this process until you're done or run out of time/money. In class, it seemed like we assumed the design would never be perfect.

If anything, Lewis & Rieman's argument is even more applicable in an age where apps are downloaded on a whim. If one feature irks the consumer, they'll toss the product. When most software were physically sold in stores, the barrier to entry into the industry was relatively high. Less competition means that products didn't have to be as targeted as they do today. Also, now that computing power is nearly ubiquitous, users have more expectations out of their devices. Application interfaces must not deviate from established paradigms lest they risk sacrificing usability. Overall however, there is not much change in the design process in applying it specifically to mobile applications.

I do not have disagreements that come immediately to mind at the time of writing.


Emily Reinhold - 1/23/2014 21:39:20

Ka Ho Lau - 1/23/2014 22:06:27

The three stages described in lecture is actually quite similar to Lewis & Rieman design cycle. The reading material is more specific and provides more detailed for each stage. For example, Lewis & Rieman introduced the idea of representative tasks which is the core of the design. Also the idea of "plagiarize" is introduced in the material.

Nowadays, since mobile apps are readily available to be downloaded on App stores, users will not have the patience to wait for a long time for an update. Developers have to change the design more frequently. Also, since the number of apps grows rapidly nowadays, developers have to introduce new features frequently. Lewis & Rieman talked about the time to be inadequate is a few years. However, a month will be considered a long time now. Therefore, I think nowadays the number of iterations has increased and the time for each iteration has decreased.

I think we might be able to set a reasonably higher usability objectives when it is reached if time and resource allows. The next iteration can be focused on tuning performance, eliminating more errors etc. Of course, this will be up to the management since we have to analyze the cost vs benefits of tuning the objectives.


Zachary Mayeda - 1/23/2014 22:13:35

The steps involved in each design cycle are very similar: both involve creating a list of requirements for the interface, observing existing interfaces, prototyping, user testing of prototypes, and testing the final product. However, the order in which these steps occur differs between the two cycles. The three stage cycle described in lecture implies that all three stages may occur many times before a successful first version of a product is made. The Lewis & Rieman cycle indicates that while certain stages may repeat until successful, the entire cycle doesn't repeat in the process of producing the first version of a product. For example, they describe creating new prototypes until user testing successfully meets all requirements, but at that point you would not go back and reevaluate the requirements.

Yes, I think the key ideas of their design process still hold today. Interface designers still need to evaluate the goals of the interface, observe other interfaces, prototype, and test interfaces. In the case of mobile apps, I think the design process may need to be more flexible in terms of requirements. Apps are released so quickly and can be updated so easily, that many times it is better to release features incrementally. Instead of meticulously designing the entire interface and releasing it, today it may be more advantageous to release features as you go.

I disagree with the authors on the Plagiarize section of the process. I don't think it is better to stick to the norm and continue bad interface habits because they are common. I think changes must be made if they have to potential to save time and energy.


Doug Cook - 1/23/2014 23:23:54

In their introduction to the Task-Centered Design Process, Lewis and Riemann provide an expanded description of the three-stage cycle shown in lecture. One might draw parallels between steps (1) through (5) and the “design” stage, between steps (6) through (10) and the “prototype” phase, and between step (11) and the “evaluate” phase. This simple mapping suggests most designers follow some cyclical process that allows improvement. However, the two cycles differ subtly in that the 3-stage version doesn’t provide a particular focus; it could potentially fit onto the “waterfall” model that Lewis and Riemann advise against. In this way the Task-Centered Design Process ensures that the designer guides the process whereas the 3-stage process permits but does not require this constraint.

Many of Lewis and Riemann’s steps are still applicable despite the age of their writing. A significant difference in today’s market is the shift to portable devices and rapid automatic updates. Such a difference fits nicely into the cyclical pattern because it allows more frequent repetition, which would likely help the overall design. If anything, the move away from “shrink-wrapped” software packages allows a more thorough testing framework due to the ease of deployment (no need to purchase physical packages anymore). This same advantage also suggests a change in the Lewis and Riemann process, as moving from “Track the Design” to “Change it” seems to overlook a critical opportunity to engage users. Perhaps if testing were included here the changes would be more effective since the interface is already deployed and no prototype needs to be constructed.

I have two disagreements with the Task-Centered Process. The first involves the ordering of “Rough out the Design” followed by “Think About It.” To me, this suggests a “shoot first, ask questions later” approach and while both steps are important, I would prefer the design be continually evaluated as it’s produced rather than afterward. The second disagreement involves the authors’ approach to “Plagiarizing.” I agree with Lewis and Riemann’s motivation in borrowing inspiration from successful interfaces, however I think this step is too superficial. It ignores many of the subtleties in how individual components contribute to the overall interface (their “spellcheck” example is interesting but makes many assumptions about similarities in how text is used between applications). I think this step could be altered to direct users toward educational design resources, especially since many textbooks and websites have become available since this introduction was written.


Myra Haqqi - 1/23/2014 22:33:40

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

The Lewis & Rieman design cycle compares to the three stage (design, prototype, evaluate) cycle described in lecture by containing similar tasks. However, in addition to the process demonstrated in lecture, the Lewis & Rieman design cycle has included even more steps in order to successfully design an interface.

Specifically, while the lecture describes the Design stage as innovating to create new design ideas, Lewis & Rieman also contains similar methods in making a design. The Design stage portrayed in lecture consists of task analysis and contextual inquiry, rapid prototyping, and evaluation. Similarly, the Lewis & Rieman begins with the step to “figure out who’s going to use the system to do what.” This corresponds to “task and user analysis,” in which designers gain a deep understanding of the user’s preferences and needs. This is absolutely crucial in the Lewis & Rieman cycle, because contact between the designer and the user ultimately facilitates great designing that solves problems and addresses the desires of the user. This closely resembles what we learned in lecture, in which we were taught that observation, communication, models, and experimentation helps designers acquire the information needed to serve their users.

The next step that the Lewis & Rieman cycle describes is to choose representative tasks for task-centered design. This entails writing tasks that users face in actuality. The Lewis & Rieman cycle goes on to explain the concept of plagiarism, in the sense that designers mimic existing designs currently used by users. One major benefit of this is that users will already have some experience interacting with these designs. In addition to that, it is helpful for designers to create a useful design. These tasks were not explicitly addressed in lecture.

The Lewis & Rieman cycle includes additional steps, beginning with roughing out the design rather than programming initially, and also thinking about the design. Both the lecture and the Lewis & Rieman cycle proceed to describe the process of rapid prototyping, including creating a mockup. This will be tested directly with users, which will help designers acquire a better understanding of how they can improve. Both encourage the use of initial paper drawings, and then using tools to develop prototypes.

In lecture, we learned that the prototype should first be evaluated analytically without users. Then, both the lecture and the Lewis & Rieman cycle proceed to address the need to test with real users, as this crucial step provides a lot of insight for designers. The lecture specifically addresses the tasks of using techniques, including expert evaluations and walkthroughs or controlled usability studies, in order to gain more valuable information. The use of walkthroughs was mentioned in the Lewis & Rieman cycle as well.

Both the Lewis & Rieman cycle and the lecture address the need to iterate and repeat all of the steps in order to make improvements. Both lecture and the Lewish & Rieman cycle essentially claim that designers should iterate until they run out of time, money, or some other resource or request. The Lewis & Rieman cycle then specifies the process to build the design, which entails the actual programming and implementation of the design. The Lewis & Rieman cycle also explains the concept of tracking the design by keeping designers in constant communication with users in order to address any issues that the users face. The Lewis & Rieman cycle concludes with the concept of changing the design, as upgrades are necessary in software at large due to constant changes through time.






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 today, when most mobile applications are downloaded through app stores? What changes in the design process for these apps?

No, their argument about the design process does not necessarily hold equally for today. Now that most mobile applications are downloaded through app stores as opposed to purchasing software “shrink-wrapped” in stores, the design process alters slightly in its necessary tasks. Changing the design is now much easier and expedited, because users simply update their mobile applications with the click of a button on the app store, as opposed to driving to a store to purchase new software. This allows designers to iteratively improve and upgrade their design while giving them the ability to disseminate their updates to all users simultaneously and easily online.

In addition to the simplification of upgrading the design, designers now have the ability to get more instant and thorough feedback from users online, as many app stores contain forums for users to post reviews and comments about mobile applications. Therefore, designers will be able to better track the design, as opposed to being forced to be put in contact with users through archaic methods mentioned in the Lewis & Rieman cycle such as making designers work temporarily on the customer hotline to speak with customers and hear their problems.

Also, the fact that mobile applications are downloaded through app stores instead of being purchased physically in stores implies that users will be more likely to have a myriad of different applications downloaded from the app store, because it is much easier for the user to download mobile applications as opposed to driving to a store and buying them. Therefore, designers will need to deal with a wide variety of different tasks, interfaces, and uses of the users, as users will be more likely to rely heavily on many different applications. Since users will be able to easily download multiple applications in a very short period of time, as opposed to manually going to a store to purchase software, which will definitely transpire less often than downloading applications online at home, users will have more applications and thus more tasks to accomplish using applications.






Where do you disagree with Lewis & Riemann? Why?

I disagree with Lewis & Rieman about the lack of focus on solving some pain-point of the end-users. I believe that designers should focus more on understanding the adversities that users are forced to endeavor to circumvent. Rather than simply focusing on users’ tasks, designers should covet to solve some problem in order to improve the living conditions of users. Designers should make an effort to solve a specific pain endured by users.

I disagree with the focus of the designers outlined by Lewis & Rieman because I believe that users’ lives should be improved, not just supplemented with additional features that help their accomplish their tasks. Specifically, designers should focus on understanding what specific details about user interfaces cause users suffering and hardship. Designers should focus on solving the problem because with the problem in mind, designers will be able to focus on specific aspects of user interface design that will truly have a great impact and immense improvement for users.

In addition to this, I disagree with Lewis & Riemann regarding the need to plagiarize in some instances, because although users are used to doing things in a certain way, it is not difficult for users to adjust and get used to doing things in an improved manner. If designers thought in innovate and new ways, as opposed to mimicking existing designers, then they can create designs that will greatly improve users’ experiences. If designers can innovate in such a way as to provide immense benefit and improvement to users’ lives, then users will be happy and willing to adjust and get used to the new, easier, and improved design.


Emily Sheng - 1/23/2014 22:43:05

The Lewis & Rieman design cycle depicts the same basic phases as those in the three stage cycle. However, the former breaks the "design" phase into many pre-prototyping steps. It is first necessary to figure out the user and purpose of the system and choose representative tasks to represent the system design. After determining the user and purpose, Lewis & Rieman propose that designers "plagiarize" good designs from existing systems to avoid reinventing the wheel for various base functionalities of the system, design a rough draft, and think more about it. Next comes the prototype/mock-up stage, and afterwards, testing it with users. Then many iterations follow, until it is finally ready (or forced) to be built and distributed to users. The main difference between the Lewis & Rieman design cycle and the three stage cycle is that the former has many iterations of designing and testing before anything is released to users, whereas the latter iteratively builds, releases to users, and improves along the way.

It makes more sense for "shrink-wrapped" software to go through many iterations of design and testing before anything is delivered to users. These software probably cost more than the ones downloaded from app stores (in terms of producing, shipping), and new versions of these software came out less frequently--people would own the same version for many years. However, for mobile applications that are quickly and easily downloaded, it makes more sense for prototypes to be released quickly so that real users can test them out, give feedback to developers, and have developers redesign and release new versions. Because downloading from the internet and getting feedback quickly is possible, it would be a better use of time for mobile application developers to have something to let users interact with early on, and then iterate from there.

Although I do agree with Lewis & Riemann that we have to "think about it" before creating a mock-up or prototype, I think their analogy of designing a plane is inaccurate for the design of mobile applications today. Of course there are many apps that need to guarantee their users' privacy/safety and must be meticulously planned (ex: apps of monetary transactions), but there are also many more apps that can be less strict with their design (ex: games, where it is not a big deal if there is a minor bug in a release). In the latter case, it may be more beneficial for the developers to release the application even with bugs, and get more feedback on other aspects of the application.


Armando Mota - 1/23/2014 22:54:48

1) The Lewis & Rieman design cycle can be thought of as an elaboration on the design cycle we learned in lecture. Each of L & R’s eleven elements of design can fit into one of the three lecture design processes (some, like “track it”and “change it” could be thought of as having slightly different connotations, but still fit), and both emphasize the iterative nature of the process. “Track it” and “change it” are considered in the lecture cycle - the product is designed, prototyped, evaluated, and this process is continued. However, during lecture, Bjoern’s statement that you iterate "until you run out of time or money” had an immediate feel to it - as in, this iterative process continues until the product is pushed to market and ends there. The Lewis & Rieman cycle makes it clear that this cycle is never over - when a product goes to market, a vital part of the product's (and its successors, which are inevitable) success is the continued work of the designers to gather data on their product and use that data to revise and redesign future iterations and upgrades. One thing the Lewis & Rieman cycle emphasizes, which was not in the lecture cycle, is the choosing of representative tasks and the adherence of many of the following steps to those tasks. The lecture cycle does advocate gathering tasks and experiences from users, but the Lewis & Rieman cycle adds a bit of detail, for example when discussing the process of roughing out a design, in which it is made clear that any features that don’t address one of the representative tasks should be forgotten about. Both advocate evaluating rough designs without users first as a way of discovering weaknesses without having to build a working model of the actual interface, which seems valuable.

2) I don’t believe this framework is effected by the fact that most mobile apps are downloaded through app stores now - every element of this design process is still applicable. Many might be considered even easier/more essential, like plagiarism - themes have arisen given the dominance of platforms like iOS and Android, so not only are commonalities among interfaces abundant, you also know that when plagiarizing something, it was almost certainly already part of a long process of plagiarism fueled by mountains and mountains of data gathered and analyzed by companies with budgets much larger than yours. Some specific elements mentioned might be different. For example, instead of a customer hotline you might have a support email’s inbox, and instead of “watching the workplace in which their products are installed”, you might be gathering data on the online ecosystem in which users are positioned, or where they’ve visited, but overall the processes remain the same. Something that is important to mention is that this process, because of the rapid rate at which technology now advances, has become much faster. The turnaround time for an iteration of your product has gone from years to weeks/months in some cases, so the emphasis on cost and keeping this cycle as efficient as possible is now more important than ever.

3) Gathering tasks from users can be quite costly and time-hogging. Lewis & Rieman suggest providing reasonably complete coverage of the functionality of the system, and while the word “reasonably” allows for some play, this may not always be possible given time and cost constraints, and the more general route when initially moving forward with the design of the interface might be more appropriate. Their statement that “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” might be true, however I think in many cases compromise can be successful, as in creating something that is very close to what people know. In that respect, I think something along the lines of using what users know to inform your decision would allow you to select the known option if it is optimal, but would also allow you to consider morphing it a bit to retain that known factor but still provide innovation (just a small innovation can make millions and make an app that more friendly to users).


Ian Birnam - 1/23/2014 23:50:02

1) I believe that Lewis & Rieman's design cycle is like a the more detailed version of the three stage cycle we learned in lecture. Steps 1.1 through 1.5 represent the "design" phase. These steps involve the work that must be done before anything else. This includes user research, needs assessments, and hashing out initial concepts before they become more stable as a prototype. Step 1.6 is exactly the "prototype" phase, where a more concrete version of the product is realized, and is ready to be tested on. Finally, steps 1.7 through 1.11 represent the "evaluate" process. These steps focus on testing with users, recording their feedback, and iterating through new designs before releasing a final product. Steps 1.10 and 1.11 are what complete the cycle, as they say that even if you build and release your design, you should be prepared to make changes for problems or opportunities that arise.

2) I believe their design process can still be used today. Though some of the technologies and tools they mention are archaic, the core concepts and ideas are still the same or are similar to modern design processes/cycles. Lewis & Rieman's cycle can be broken down into the broad categories of user research, prototyping, and testing/evaluating. These categories are ones that designers today still practice, and are still relevant regardless of how the technology has changed. Designing an app still requires that you understand your users and their needs, create prototypes for your users to test, and then collecting feedback from users to improve the app. Whether shrink-wrap is involved or not doesn't make a difference.

3) I disagree with them on their somewhat vague description of 1.4 and 1.5. "Roughing Out" the design and "Thinking About It" are incredibly high-level, and much more should be going on before they actually build and design the prototype. Designers should be sketching, revising, sketching again, and at least going through a few wireframe iterations before prototyping. All of this should be done with discussion and debates going on throughout each sketch or wireframe. A lot more needs to go into the design process besides "roughing out" and "thinking," which seem more like mini-steps that you need to do throughout the initial design process while you sketch and wireframe.


Yang Xiang - 1/23/2014 23:59:17

1. Lewis & Rieman design cycle focuses more premeditative thought than design, prototype, evaluate. The cycle described in class has the designer continuously improving on their prototypes though evaluation and testing, they run out of time and resources. However, the task-centered design process focuses a lot more planning. Though Lewis & Rieman does repeatedly test and refine their code they stop their cycle when they have met succeeding in completing tasks they have set for themselves. Then they move from prototyping while the cycle described in class is constantly improving on its prototype. While Lewis & Rieman design cycle can be more efficient, since there is a definite set goal, the design, prototype, evaluate cycle can be more thorough and cover more potential problems.

2. Lewis & Rieman’s design process may not hold equally today as before. With app stores, designers can wirelessly provide updates to their products without further interaction with the users, making upgrading apps cheaper and easier. This means the designer does not have to worry so much about getting everything completely right the first time, instead they can focus more on improved features of the app. Since companies are being more and more competitive, creating the most appealing user friendly app is becoming more and more important. Thus designers can at times overlook quality for functionality. As the app is being tracked, changes will need to be continuously applied to the app in short time (weeks) intervals in response to user feedbacks as oppose to longer periods (years).

3. I believe step 1.9 “Build the Design” should be before 1.8 “Iterate.” Since in this day and age, application can be updated through wirelessly and distribution application is easier than ever, jumping straight into designing can allow more time to optimize the product. Also problems can still arise even after extensive iteration; if building the final design is held to later, transitions like environment changes can produce unforeseen errors.


Andrea Campos - 1/24/2014 0:21:37

The Lewis & Reiman cycle goes into a lot more detail and fleshes out specific steps that would fall under "design," "prototype" and "evaluate" stages. For example, they create specific recommendations to "choose representative tasks", "plagiarize," and "rough out a design" before prototyping, which more clearly defines their vision of the design stage. In addition, the Lewis & Reiman cycle seems to emphasize a bit more preparation even before the prototyping stage. Before even creating the prototype, it recommends a "thinking" stage which actually includes keystroke/time analysis and even doing cognitive walkthroughs, whereas the model presented in lecture emphasized doing these things after prototyping in the evaluation stage.

It seems that since the software sold in stores needed to be completed to a point where upgrades would not be needed for awhile because of production time and money constraints (packaging, production of the software CDS, etc) there needed to be a lot more detailed steps and a lot of preparation between them. Upgrades could not be readily provided, which also meant there was more time between them, and so more room for detailed steps and even over-preparation. Meanwhile, selling apps in app stores pretty much necessitates frequent updates because they are so quick for users to obtain, and thus to critique and even demand changes. This calls for a shorter, less detailed design cycle that only has so much time to be iterated through--the shorter or less detailed, the more iterations are possible.

While I do think the idea is highly important, I don't think their conception of "plagiarize" should be a step so much as something to keep in mind throughout the entire design cycle. The decision of whether to stick with what users would know and are familiar with, or whether to go with something unique and new could be thought about everywhere--when making design choices, when implementing them in the prototype, or when seeing the way users interact with the product. Plus, a stage uniquely devoted to "plagiarize" doesn't entirely make sense if, for example, someone is trying to design something with the express purpose of making it new and unfamiliar, yet still usable. Basically, they seem to favor "plagiarizing" in most cases, which is why the stage is titled so, but I don't think that should necessarily be the default bias going into the cycle.


Andrew Fang - 1/24/2014 0:34:03

The Lewis and Rieman design cycle follows the principles of our three stage cycle described in class, but they further break down each stage into multiple stages. Lewis and Rieman decompose the "design stage" into parts 1.1 to 1.4 (figuring out who's going to use the system to do what, choosing representative tasks for task-centered design, 'plagiarizing', and roughing out a design). Then, their design cycle jumps between prototyping and evaluating. 1.5 - Thinking about it, is part of the evaluation phase, while 1.6 - creating a mock-up, is the prototyping phase. 1.7 - Testing the design with users, jumps backs to the evaluating phase, but then 1.8 - Iterating, and 1.9-Building, goes back to building more prototypes. 1.10 Tracking the design involves evaluation, and 1.11-changing the design, starts the cycle all over again.

Yes, their argument still holds today. We still need to figure out what the user wants to do, and mobile apps try to address that problem by catering to a specific task. What they call 'plagiarizing' is even simpler these days with all these open source projects and abundant number of apps on the market. We can continue through their design cycle without having to change much of their language: we still need to rough out a design of the various screens of the mobile app, and we need to think, prototype, test, iterate, and build. Tracking the design though, becomes slightly different in the sense that designers can directly get user feedback via the ratings and comments sections on the app stores. Instead of sitting in on a customer hotline (users of mobile apps will not likely call in to get help), they can gauge the feelings that their users have towards their app directly through the reviews. Lastly, changing the design becomes ever more simple, and new versions of software are released to the public in shorter and shorter time-frames. Designers work to make small changes and fixes quickly, and plan for new releases in a much shorter timeframe than a shrink-wrapped software product.

I disagree with the way they title the process of learning from other existing interfaces as "plagiarizing". This word has a certain negative connotation to it, especially in undergraduate academia. I don't like the way they phrase the concept -- a designer should not be "copying existing paradigms," rather, they should be learning from existing practices and improving on them in a novel way. A designer should have the integrity to not copy another product, but gain inspiration from it and use the existing product to understand the market. Then, using his or her own ideas, they should fashion a design that fits the model, but with a interface that is different and better than existing solutions. Users often don't know what they want until we give it to them, so we should be creative in coming up with new ways to approach traditional tasks.


Haley Rowland - 1/24/2014 0:48:50

There are many elements of the Lewis and Rieman design that are quite similar to the three stage cycle. In a sense, we can consider the Lewis and Rieman design to be an unrolling of the three stage cycle. Stages 1-5 of the Lewis and Rieman design fit under the umbrella of the three stage cycle’s design phase. The prototype and test stages (6 and 7) of the Lewis and Rieman design clearly correspond with their matching stages in the three stage cycle: prototype and evaluate. The three stage cycle’s inherently iterative nature echoes Lewis and Rieman’s stress on the importance of iteration. The Lewis and Rieman design’s last 3 stages again reenter the three stage cycle: “Build the Design”=prototype, “Track the Design”=evaluate, “Change the Design”=design. The two cycles are functionally very similar, but Lewis and Rieman provide more exhaustive instructions for the front-end of the process. Lewis and Rieman’s argument is still relevant to today’s applications, however there are aspects that cannot hold equally today. I believe Lewis and Rieman’s point about plagiarism is still appropriate because interfaces must be familiar and intuitive for users, but I disagree that a novel interaction paradigm has a high risk of failure. Because the mobile application industry is still very much in its infancy, there is more flexibility in the generation of new paradigms than Lewis and Rieman afforded. Additionally, because the app store allows for users to download updated versions of an app, designers can more easily make and issue changes to their product. This allows for the iterative design cycle to continue more fluidly than was possible during the more rigid software releases of the “shrink-wrapped” era of Lewis and Rieman. An app can be released to market, but this doesn’t suspend designers from evaluating and redesigning the app. Revisions don’t involve a whole production line as they did in Lewis and Rieman’s time; instead, changes can be make subtly and continuously. Despite these distinctions, it is remarkable that a design process developed with technology that seems archaic by today’s standards can still be so useful.


Jimmy Bao - 1/24/2014 2:27:11

1) In my opinion, the L&R design cycle is just a more detailed version of the three stages cycle. The three stages cycle states to design, whereas the L&R design cycle provides more detailed procedures to think about while designing. It would be helpful to maybe those UI developers who are just starting off and need more of a detailed check-list as they're developing. The "design" step by itself is pretty open-ended, so having concrete steps, like the ones the L&R design cycle provides, is extremely helpful.

2) Yes, their argument (specifically 1.11) says to change the design. Due to the technological limitations of the past, software were shrink-wrapped in physical packaging and sold that way because it was at the time the best method to distribute software. But as technology got better, developers were able to make software more accessible to the consumer. Having it available on an app-store, which is only one-click away, is surely way more convenient than having the consumer drive to the store, purchase the software, and end up having a bunch of boxes that contained the software lying around their home.

3) I disagree mainly with the part where they claimed that it is generally better to stick with what the user already knows, which in turn, means to stick with existing features on an existing system. I do agree that certain users may be turned off on the idea of having to learn something new just to be able to do something they were able to previously before. However, I feel that if the new system is able to offer users perhaps better functionality, aesthetics, efficiency, it is worth learning. A quick example that I could think of is making that switch from Yahoo Mail to GMail. GMail did have all the standard features that Yahoo Mail, and any other mail clients, should have. However, their UI was different compared to Yahoo's (deleting messages in bulk, accessing the account settings, etc. were different). But GMail allowed more capacity to store more emails, several Google services integration, and so on, which ultimately made it worth it for a Yahoo user to learn how to operate and use a new system.


Nahush Bhanage - 1/24/2014 2:40:41

Though the Lewis & Rieman design cycle is mainly built upon the tasks that the user would perform, it is more or less aligned with the three stage cycle described in class. Both strategies highlight the importance of an iterative process in the development of a user interface. Both emphasize on revisiting and making changes in the system design based on the prototype evaluation by real users (unlike the traditional waterfall model). This ensures validation of the user requirements/expected functionality and helps make the system robust by catching and fixing most bugs prior to its release.

I think the task-centered design process is applicable even today. It mostly touches upon the conception, requirement gathering, design, prototyping, evaluating stages in an iterative manner. So the underlying principles would hold irrespective of how the software gets channelized in the market. Nevertheless, I think there are numerous advantages of making the software available online - firstly, the designers can easily take a look at other softwares to get a better idea of what already exists; secondly, the online channel is a much better platform to attract beta testers; thirdly, it's easier to ship app updates to the users; and finally, it is an effective medium of getting user reviews and improvement suggestions.

I like the task-centered approach in general, though I (mildly) disagree with the "plagiarize" stage. It is definitely helpful to carefully review existing applications, but I think creating a different interface would help an application stand apart from the competition. For instance, there are numerous TV series guide applications on the app store; most of them are very similar-looking but there's an app called 'SeriesGuide' that stands apart due to its strikingly different interface. And this is evident from the fact that it has been downloaded by 1,000,000+ users (as compared to other apps that have been downloaded by only 5,000-10,000 users). Also, users are tech-savvy enough to try out new designs, as long as the interface is not counter-intuitive.


Muinm Ali - 1/24/2014 5:02:55

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

A: The three stage cycle (design, prototype, evaluate) an the Lewis & Reiman design cycle seem very similar: in fact, the Lewis & Reiman design seems like a more "in-depth" version of the 3 stage cycle. The Lewis & Reiman design process , however, seems to enlist more user feedback as seen in the very beginning of the design process where "task and user analysis" is carried out, whereby a target audience is decided upon and the designers heavily emphasize the tasks that this target audience want the product to be able to complete.

Another difference between the two design cycles is the task of product/design tracking that features in the Lewis & Reiman cycle but seems absent in the 3-stage cycle. I also like the fact that the designers in the Lewis & Reiman process are in close contact with the customers as witnessed in the customer hotline example in the reading.

Q: 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 today, when most mobile applications are downloaded through app stores? What changes in the design process for these apps?

A: Although the Lewis & Reiman process could, for the most part, be used for both web based as well as "shrink-wrapped" products, the Lewis & Reiman process seems too time intensive (especially in the quest of perfecting the product). In this day and age patches to these products could be made available easily through online updates, which would enable the designers to ship out products at a faster rate.

Q: Where do you disagree with Lewis & Rieman? Why?

A: For the most part the Lewis & Rieman process seems pretty reasonable to me. However, if I had to nitpick, I would say that it places too much emphasis on the "plagiarize" step which according to me stifles great ideas just because the user hasn't seen it before. I feel that the user should be given the opportunity to try out both the unfamiliar as well as familiar designs before the decision to adapt either one of the two is made.


Andrew Lee - 1/24/2014 7:18:48

The L&R design cycle is pretty similar to the 3-stage cycle described in lecture. They expand on some steps, such as the "Plagiarize" section, which would probably be incorporated into our "design" stage, as it talks about embracing conventions instead of breaking them.

For the most part, the main structure of their design process is still pretty valid today. The main difference is that now, the cycles happen far more frequently, since it's significantly easier and faster to redeploy and update apps. Additionally, lots of services are moving to the cloud, where the user doesn't exactly download/install anything, and the experience takes place completely in the browser. In this case, iteration and giving the users the latest and greatest experience requires no action on the users' part.

The part about putting the designers in contact with users by rotating them on a hotline sounded pretty strange to me at first, but I guess historically, during that "shrink-wrapped" era, that would make sense. Nowadays, it's common for apps/services to log and record diagnostics liberally, which can also paint a picture of how users use the product. I imagine this was still possible back then, though.


Jeffrey DeFond - 1/24/2014 8:52:45

The Task Oriented design structure described by Lewis and Rieman is very similar to the three step design process described in class, with a few key differences. The Task Oriented design process’s early stages, like the three stage cycle, involve coming up with a design and prototyping it. The difference being that the three stage cycle places a greater emphasis on identifying and observing users to come up with a task while the Task Oriented approach places greater emphasis on creating a list of Tasks (albeit based on knowledge of users). Fairly similar, but somewhat different in that is the three stage process tries to find problems certain users have before a project starts, whereas the Task Oriented approach would to come up with a list of tasks that users are believed to be doing. The primary difference being that in the three stage design cycle each step has some user feedback, usually at the beginning, whereas the Task Oriented approach is focused on getting feedback at key steps, usually at the end before iterating. The fact that they are both iterative design cycles, and that they both recommend as much user feedback as possible (albeit at different times in their respective cycles) make them close cousins, and obviously both superior to the waterfall method described at the bottom of the Lewis and Rieman reading. The emphasis that Lewis and Rieman placed on getting user feedback, and the cost of tracking the design certainly spoke to the time the article was written. It is far easier to get user feedback on software, both qualitative (download reviews by users, or beta-testing) and quantitative using the internet. It is also far easier to patch, monitor and repair bugs as they are found. I believe that this might change the last step in the Task Oriented process from change design to upgrade and patch. Mostly it is hard to find direct issue with anything that Lewis and Rieman say, they have many good design tips, however, they are very focused on maintaining paradigms. The plagiarize step, while accurate in many ways, and certainly good advice, (don’t fix what isn’t broken, don’t reinvent the wheel, etc.) it doesn’t seem to take many risks. This may be because they were from the “shrink-wrap” era when it was a lot harder to update software after it left the store. I think today with our new found fascination with touch screens, new paradigms are being established, and some risks can be taken, and if they don’t catch on, fix them in the next patch. Again, it is good to look at other designs out there before creating your own, however it seemed a little stagnant to me. This is a minor critique ultimately however.


Jason Chen - 1/24/2014 9:59:21

The Lewis & Riemann design cycle is quite similar to the three state (design, prototype, evaluate) cycle described in lecture. More specifically, the design cycle described in the reading involves first thinking about the tasks that the application will accomplish and how it will accomplish these tasks, namely through a redesign of UI or following a convention, then prototyping, or as the reading puts it, "roughing out" the design on paper and perhaps, in a modern sense, in a prototyping program, and then lastly testing the design with users and iterating on the interface based on feedback.

Although most modern mobile applications are downloaded through the app stores, much of what Lewis & Riemann propose in their design cycle still holds. For example, the application will still benefit from research about the tasks it will accomplish through being used by the users. It is also still the case that this research and the following stage of prototyping and mock-ups is important in avoiding unnecessary software costs that may result from a change in design midway through the development process.

Nevertheless, there are still more than a few changes in the design process for these mobile apps. One such change can be seen in testing process, as in the past a designer might have had to take a more proactive approach to finding target users to test the application on, whereas now, because mobile applications are accessible to the masses via the app store, a designer can reach out to a larger group of test subjects at a much lesser cost.

One statement by Lewis & Riemann that I disagree with is that task-oriented design is necessarily better than the waterfall design, even when there is a heavy user interface component. I believe that there are situations in which a plan & document design style such as waterfall may suit a software application much better than an iterative process like the one described in the reading. This can be seen in NASA projects, which use plan & document but undoubtedly still have significant user interface considerations.


Seyedshahin Ashrafzadeh - 1/24/2014 10:16:12

Lewis & Rieman design cycle explains that we need to first define our users and figure out the task that they want to achieve. Based on this task-centered design, we then need to "plagiarize" and rough out a design and think about the weaknesses and strengths of the interface that we come up with. Afterward, we prototype our design, test it with our intended users, get feedback, make adjustments, and iterate until we balance the cost and benefits. Then we build the design and track it and we might want to change it for next versions. I think that this cycle is pretty similar to the three stage cycle (design, prototype, and evaluate). The first five steps in Lewis & Rieman design cycle explains how we need to approach our design stage. Then they explain how we need to prototype. And for evaluation, they explain how we need to test our prototype with the users or do cognitive walkthrough. Then they discuss how we need to iterate so we get the interface right. After that they discuss how a designer needs to track and change his/her software after the development. These two steps are not evident in the three stage cycle though. Now comparing their design cycle with today, I think that most of the steps would remain the same. I feel this process is in a faster pace, and the methods that users obtain the software have changed. In the past most software was sold "shrink-wrapped" and therefore, they might have had guideline brochure with them. But, now these guidelines have to be provided in a different method. Therefore, the designer has to consider these limitations. Also, in today's world, where every user can post his/her review, the methods that designers get user feedback have changed. I do not agree with the fifth step of Lewis & Reimann design cycle. After having a rough design, I think we should just create a prototype and let the users experience with the prototype. I think that in the fifth step, the designer might actually develop some assumptions about how users interact with the interface that might not actually be true. Therefore, I believe observing the user on how he/she might use the interface is more powerful that building some assumptions that might be incorrect. The reason I'm saying this is that I have been to a design process and I saw that some of the assumptions that are made during prototyping from the designers are actually incorrect.


Sangeetha Alagappan - 1/24/2014 10:46:38

The Lewis and Riemann design cycle is quite similar to the three stage cycle described in lecture in terms of how a design problem is approached. The L&R cycle however is more comprehensive and structured in its approach (especially in the design stage) and outlines a procedure past the design cycle to improve on the design even after it has been built. Due to its thoroughness (and its preference for holding users’ previous experience and knowledge very important, as well as techniques like cognitive walkthrough and tracking the design), it would seem that a cycle of the L&R approach would take longer than the three stage cycle.

During the age of “shrink-wrapped software”, software that was put on shelves had to be a polished final product; something that doesn’t hold true for mobile applications. Most apps these days are available for download in their beta stage to gauge interest and elicit feedback before changes to the design are made and shipped as a final version. Therefore while the L&R design cycle is still applicable to mobile applications, it needs to be adapted. The cost of construction and risk of failure isn’t as high and it’s easier to track the design; so the time span on each design cycle should be shorter though the design should be improved more often to keep up with trends, competitors in the app store and rapid mobile phone development. After the design is built, it should be tested on a limited number of users and accordingly improved based on their feedback. The final product should also be improved based on online reviews and user rating and feedback.

While I like the task-centred approach to the design process, I disagree with Lewis & Riemann on the level of importance given to what users know how to use. L&R discuss “plagiarizing” to make interfaces comfortable to use as users can utilise their previous experience to navigate through the interface. They however maintain that it’s best often times to stick to existing convention rather than implement your own efficient solution. I disagree with this sentiment as I think interfaces would scarcely evolve if we strongly favoured traditional layouts in all our decisions. One of the examples mentioned - accepting spelling changes with pressing the Return key - seems a better option than retaining the old spelling with the Return key as it would require no additional work if you would like to keep your original spelling; this change could easily be introduced with hover text before it starts becoming the norm and help avoid autocorrect mishaps. Users can always be gently introduced to such changes so that their experience isn’t compromised. Design should account for efficiency and ease in addition to user experience.


Michael Chuang - 1/24/2014 11:03:39

First off, there are many more steps in Lewis & Rieman design cycle. Also, the LR(Lewis and Rieman) cycle starts off with a targeted group of users and tries to figure out their needs and how it can be done smoothly while the 3 stage cycle starts by observing existing ones

The article still holds true today since I know most of my apps need consistent updates for a better user experience. Apps never premiere perfect so designers continue to work to polish them. Users change over time because they gain new skills and knowledge.

I only agree changing the design to a certain point. Yes, it is important to help existing users improve their experience, but new users cannot be forgotten. Designers should create their apps so that both existing and new users can play with their product.


Zhiyuan Xu - 1/24/2014 11:58:39

The Lewis & Rieman design cycle and the three stage cycle are very similar. In addition to the design, prototype and evaluate steps described in lecture, Lewis & Rieman describes in detail some of the techniques needed to design a finished product (for example, listing the tasks that the product will be used to accomplish, and designing such a product through a task centered method).

With the increasing popularity of mobile applications, the design cycle has changed from the Lewis & Rieman description. While the Lewis & Reimann cycle iterates through creating a prototype and testing with users before ever building the actual product, in today's market, it is easier and more practical to build the application, deploy it into the app store, gain instantaneous user feedback via reviews in order to improve the product. However, Lewis & Riemann highlight the "think aloud" technique for gaining insight into the design's problems. This is more difficult to accomplish in modern mobile application development, as reviewers will most often provide an aspect of the application which they do not like, but do not elaborate further.

Although Lewis & Riemann's design cycle is very comprehensive, I believe that it may be helpful to deviate from the task-centered approach described in their design cycle. For example, a user may have gotten accustomed to a certain method of performing a task, but it is not the most efficient way. If by changing the task or by removing it, the final product will be more efficient (ie. as observed from user feedback), it may be worth the gamble to alter the task list.


Hao-Wei Lin - 1/24/2014 12:07:49

The Lewis & Rieman design cycle, although written at a time when most software was sold shrink-wrapped, is very similar to the three-stage cycle we discussed in lecture. The part from determining the scope of the users and the representative tasks to cognitively thinking through the design (e.g. how many steps it takes to get from point A to point B inside the application's architecture) is similar to how we would approach the design process of a mobile app. One difference, though, is that mobile apps nowadays often don't limit themselves to only catering to the representative tasks that the audiences provide. Because of the higher accessibility and the less cost to put an app up in the app store (versus a traditional electronic store with shrink-wrapped products), mobile app development takes more risk to develop side features that the audience may like (ones that they might know they like themselves).¬ Asides from this, the designing, prototyping, and evaluating (i.e. tracking user feedback after launching applications) processes are pretty much identical. I especially concord when it mentioned that the “responsibility for the entire interface effort should be centralized”, and that everyone that is involved in part of the creation of an application need to coordinate with one another. I can testify this because as a graphic designer at Cal Dining marketing department, I need to be involved in not just the process of graphic design, but also that of web design, and marketing so that I can be informed by the entire process and produce a desired product (i.e. a web page).

One part that I disagree (or rather, not fully agree with) with Lewis & Rieman design cycle is when they talk about plagiarism, or preventing reinventing the wheel. They might be true at their time (before we have mobile apps like today’s) to say that reinventing the wheel is bad since the cost of failing might have meant unnecessarily losing a lot of money, and resulting in the users’ unfamiliarity of the product. However, I think in today’s mobile app centered market, it is crucial to “reinvent the wheel”, or rather, to innovate existing feature that users are used to. There is a possibility that the users may hate the app because the interface is different from what they are used to. However, there is often the possibility that the users would love the new, redesigned features that they are not used to, IF the features are in fact better than the ones they are used to. One example I can think of is the iPhone video taping and editing app “Spark Camera”. It is essentially a regular video taping app; however, the creators reinvented the recording function, so instead of pressing on a red button (which we are used to) to record, you simply tap on and hold the screen to start recording. Along with other cool added features, this innovation does not use plagiarism, but at the same time achieves a better result, as it is one of the most popular video recording apps in the app store. The bottom line is, plagiarism is safe, but it doesn’t spur innovations and improvements.


Allison Hall - 1/24/2014 12:28:54

In many ways the Lewis & Rieman design cycle and the three stage (design, prototype, evaluate) are very similar. At first the Lewis & Rieman cycle merely appears to be a more detailed and laid out version of the 3 step cycle. They both involve creating an initial design, creating some type of example of this design, testing the result, and iterating back to the beginning to get a quality product. The biggest difference is that in the Lewis & Rieman model, you don't build the actual product until these iteration are finished and you believe you have the desired design. In the 3 stage cycle from class, you would actually develop the app (or whatever the product is) as you iterate through each phase. Their is no “final product” that you build, it is always being updated. The high demand of mobile application very much affect this process. Since constant updates are needed, it is much more valuable to be developing the app during the design process. Of course, initially drawings and mockups will be used, but the evaluation and revisiting design should still be included when coding. This helps keep everything current with the everychanging world of apps. Even once an app is created you need to continues reevaluating it. Never adding new features or updates will lead to people becoming bored more quickly and leaving space for a new product to replace yours. My main disagreement with them is just not including app development in the iterative stages. I believe brainstorming and having a clear idea of what you want to make ahead of time is very helpful. User testing and mock-up are very valuable as well. However, you never stop evaluating a program. It can keep changing and the testing or design tweaks may never stop.


Kaleong Kong - 1/24/2014 12:37:12

The design cycle that is suggested by Lewis and Rieman is very similar to the three stages that mentioned in the lecture, but it has more details. For 1.1 to 1.3 of the chapter are equivalent to the design stage in the lecture. For 1.4 to 1.6 of the chapter are related to the prototype stage. And, 1.7 and 1.8 would be the Evaluation and Iteration stage. Yes, I think their argument still holds for today, since their argument is not technological specific. Although most software is moving from desktop base to smart phone base, software is still designed for people to use. Whatever technology you use, the general approach would be still the same. One change I can think about is there can be more iteration than before. In the reading it says “When should the iterations stop? If you’ve defined specific usability objectives, then iteration should be stopped when they are met.” In the past, there might be no more iteration after the products are deployed or ready to be sold. But nowadays, since we mostly download apps from app store/google play, the producers can gather more feedback after the app deployed and use that information to improve the current interface. In this way, the producers can easily maintain the quality of their product and users can simply download the new version online. I do not totally agree with the author about section 1.3 Plagiarize. I agree with the part that using a paradigm is a way to understand a general user behavior, but it may also constraint our creativity. Nowadays, we can have more ways to interact with the software using touchscreen rather than using keyboard and mouse, so being innovative is also important to a UI design.


Charles Park - 1/24/2014 13:03:53

A major difference between the Lewis & Riemann design cycle and the three stage cycle from lecture is the perspectives on the users. The three stage cycle from lecture clearly notes the unreliability of user research whereas Lewis & Riemann never stop to access the idea in which the users may not know what they want or may not fully comprehend what they really desire. Lewis & Riemann takes the stance that once the developer selects a target demographic, the target users should know what they desire. The lecture takes a different stance where the developers are warned to not give the users full authority when it comes to the designs for the very aforementioned reasons. For the majority of the content, however, the general idea is more or less the same. The eleven steps mentioned in the reading can be roughly summarized in the three stages, but contains much more detail.

I believe the majority of the design cycle holds true today, especially steps 1.1 through 1.6. Perhaps some of the steps need to be tailored to better suit the current system but understanding the users, analyzing current products of similar usages, quick mock-ups and so on are still necessary and relevant to the new “download-era”. Steps 1.7 through 1.11 are due for some major changes. The current market is now predominantly based on a “regular update” basis in which the developers can quickly correct the flaws in the program as well as add new features or take out obsolete ones. Regular user reports, if not crash reports are sent to the developers and they can react with haste while keeping tabs on their users. Since customer reviews can be found readily through the internet, the whole idea of adapting the constructs to better meet the needs of the users has become much easier. Finally, testing can be done more readily through alpha and beta testing as well as trial-versions which allow for the developers to test their products more efficiently.

One of the arguments made by Lewis & Riemann stated that when designing a product, the developers should, for the most part, “plagiarize” even the flaws of competitor programs that are already in use. The provided example was pressing the Return key in order to keep the wrong spelling rather than to change it to a more intuitive design. While I understand that many of the users may feel accustomed to a means of doing something, even if the procedure is counter-intuitive, the developers should not necessarily continue to use that flaw in future products. During our discussion, Eric mentioned how Mailbox coined the idea of swiping to archive a mail and that simple touch is what brought the app success. All the users before Mailbox were accustomed to pressing multiple buttons in order to archive their mail but through a simple, intuitive and innovative idea, Mailbox revolutionized human interaction with their phones. Much like Mailbox, I don’t think it’s the developers’ job to continue a flaw but rather find a more intuitive yet innovative means of advancing the user experience.


Matthew Deng - 1/24/2014 13:25:26

I thought that the Lewis & Rieman design cycle was very similar to the three stage cycle we learned about in class. Figuring out what to do, choosing tasks, and plagiarizing are similar to the design step. Roughing out a design, thinking about it, and creating a prototype are similar to the prototype step. Testing it is similar to the evaluate step. Then, as the cycle repeats, the Lewis & Reiman cycle iterates, and the final steps are build, track, and change, which are once again similar to prototype, evaluate, and design.

The Lewis & Rieman design cycle, however, seems much lengthier than the three stage cycle, which seems to mostly be because the software was sold at stores and could not be downloaded during its popularity. This in turn causes a lot of extra steps needed to be taken for the Lewis & Rieman cycle which are no longer necessary nowadays. For example, the “think about it” and “test the design with users” stages of the Lewis & Rieman cycle are not as stressed in the three stage cycle in the sense that rather than having to recreate a prototype or replacing the current software in the stores if an error comes up, you could instead just edit the software and update it on the app store.

I thought that the Lewis & Reiman cycle is a very strategic way for a design process that both gets the job done and does so without costing too much thanks to its lengthy prototype testing process. However, I do not particularly agree with their plagiarizing step. Sure, copying another program that the users are already using makes it a lot easier for users to understand your interface, but in my opinion a good interface is one that people would prefer over another. I would instead find the flaws that users see in other programs, and adjust those flaws when designing the system.


Pierce McEntagart - 1/24/2014 13:37:05

It seems like the three stage design cycle from lecture is more flexible version of the one described in the reading, meaning that the terms "design," "prototype," and "evaluate" can be redefined to suit different needs on the fly. The design process from the reading outlined more concrete steps to designing user interfaces for software.

I feel like the current most popular distribution methods turn design into an ongoing process, continuing past the roll-out stage. Today, developers collect data and push updates (both big and small) over the internet, so users don't need to go to the store or buy a new version in order to get an update. It seems like updates are more often released in small increments rather than in big official releases.

I agree with some parts of the reading, but most I just don't feel like I have the authority to judge. I agree that user interfaces should strive to be familiar rather than clever, and that even annoying aspects of the familiar should be kept until it is safe to make a change.


Albert Luo - 1/24/2014 13:44:09

The Lewis & Riemann design cycle consists of iterations of design and prototype before finally building the product, whereas the cycle described in lecture also included building the product for evaluation for each iteration. In most other aspects, the idea remains the same. Lewis and Riemann advise multiple iterations of designing and redesigning the product based on user feedback, so that the product can best fit what the user wants (or at least what he thinks he wants). The key difference is that their product is final - that is, no major changes can be made to it once released, even if users absolutely hate it. The product would just fail. However, the cycle described in class provides opportunity for the product to be drastically changed, if users react badly to part of it.

Given the "shrink-wrapped" software, the difference between these two cycles makes sense, because no changes could be made after the product was finally built. However, today, because we can push updates through the app stores, we can more readily test our product. So, we are able to build a product after creating a good prototype and see how users respond to it, ultimately so that we don't have to design based on limited use cases from prototypes, but from a holistic picture of actual user experiences. Ultimately, this philosophy of constantly tweaking based on user feedback still applies today, just to the final product itself rather than unsubstantial prototypes.

I disagree with Lewis & Riemann on their description of how to test the design with users. I think that nothing replaces users interacting with the product in real scenarios. If presented with a sketch of the product, the interaction with that fake interface would hardly come close to a real use scenario. Even if presented with a somewhat complete prototype, the users could still "think aloud" the thoughts that they think they ought to think, and small things that could impact the user's experience could be looked over because the user doesn't want to be overly critical. Only when users have a working product can they give truly valuable feedback.


Emily Reinhold - 1/24/2014 14:07:57

The task-centered design cycle introduced by Lewis and Rieman spells out steps in much more detail than the three stage design cycle from lecture. For example, the design phase in the three stage cycle is very open-ended. It may incorporate research, user studies, and many other sub-stages that ultimately influence the "design" for that particular iteration. The Lewis and Rieman cycle, however, spells out several stages that would be incorporated in the design phase of the three cycle process: task and user analysis, task specification, plagiarize, "rough out the design", and "think about it".

Most of the design cycle holds for any application, be it mobile or shrink-wrapped. A few suggestions they mention, though, must be modified to be appropriate for mobile applications. For example, mobile applications and touch interface allow for a substantially higher variety of gestures that can be performed to execute different tasks. Thus, certain stages need to be cautious of the fact that some gestures may be unfamiliar to a group of users. Further, in the "track the design" phase, it suggests that designers get in contact with users by sitting on the "customer hotline" for a temporary period. Nowadays, someone who downloads a mobile application is unlikely to call the customer hotline to report a problem. It is more likely that he or she will write a review on the respective page for this application in the App Store. Thus, designers should perhaps take some time to read through these reviews to get a sense for what users like and don't like once their application has been released.

I slightly disagree with Lewis & Rieman when they urge the designer to "stick with what the user knows". This mentality does not breed creativity and advancement in technology. If all application designers simply stick with what the user knows, no application will feel innovative to the user! For example, if Apple stuck with what users know, the "pinch to zoom" feature that is widely accepted as the method of zooming would have never been invented. I think simple tasks that are already as simple as they need to be can remain the same, but I don't think throwing such a blanket statement out there to UI designers is a good way to encourage originality.


Zhirong Gong - 1/24/2014 14:10:43

The Lewis & Rieman design cycle is similar in many ways to the three stage cycle in that the same basic phases exist in both cycles, such as brainstorming, creating a prototype, and testing the prototype with real users. Both cycles agree that testing is essential since there are bound to be problems in the design that are not obvious until a user is allowed to interact with it. However, the design process described in lecture differs in that I think it emphasizes the iteration aspect of the process so that new versions of the prototype are exposed to users and tested even sooner than in the Lewis & Rieman design cycle.

I think their argument still holds today, since a new interface still needs to be throughly tested by users and their feedback evaluated. In today's mobile application process, I think the things that might change are the speed at which new iterations are released to the public, and so the evaluation portion of the design process needs to be done faster. Also, the designers are also able to quickly see the flaws in their design by possibly looking at comments about the app made by users. If users are not pleased with the design, the flaws will be quickly exposed by angry users who comment on the app.

I disagree with Lewis & Riemann on the aspect of plagiarism in that I don't think it should be emphasized as much. While it's true that many designs would be easier for users who are familiar with an older or more mainstream design, I think it is worth it to first create a new design that isn't like older versions, and then test it with users. If the new design does not work out, then it would be okay to switch to an older version, but the important thing is to take a risk and first give the new idea a run through with users.



Peter Wysinski - 1/24/2014 14:14:24

The Lewis & Rieman design cycle is very similar to the design, prototype and evaluate cycle we studied in class. First one must think hard about what the system is attempting to do, how similar systems perform the actions and who is going to use it; this is analogous to the the design phase which involves meticulous research and planing. Once thought is put into what one is going to build, it is time to execute and build a prototype. According to L&R this prototype does not have to be fully functional, a mock-up will suffice. Lastly one must analyze user’s interactions with the conceived design and make changes based these observations and feedback. One place L&R differs is that it only devotes one section to the prototype phase whereas the model in class devotes equal attention to each of the there stages.

For the most part the process described by L&R holds in today’s day. For example, section 1.1 describes how systems designed for Macs should include features and commands that are prevalent in the Apple OS. Indeed, users expect a different UI/UX on Android and iOS. However, what is different in todays design process is that one would not “videotape the tests.” Current infrastructure allows for real time A/B testing where half of the users can be push one version of the app and the other half get another. This is all done on production where user interaction is carefully analyzed based on user demographic. While the general ideas described in L&R hold, the methods for carrying them out are different due to quick remote distribution and instant user feedback.

I disagree with using a less efficient convention if it is one that users already know and use day-to-day compared to a new more efficient convention. Prior to the iPhone, users preferred small physical keyboards to touchscreen as it was something that was used since the age of typewriters; when the iPhone first launched critics believed that it would not succeed due to this. However, it took off and other cellphone makers followed Apple my making screens the dominant part of the smartphone. Before the twenty-first century cellphone companies believed that smartphones would be primarily media creation devices which would benefit from a large keyboard while in fact they were truly media consumption devices which would have more utility from a larger screen.


Kevin Johnson - 1/24/2014 14:27:23

The Lewis and Rieman design cycle shares strong similarities with the stages described in class. Both focus on using customer feedback to generate quick, low-fidelity designs, seeking immediate feedback, and iterating the process until the design goals are met. One key difference that relates to the age of the article is that the Lewis and Reiman structure relies on testing the design on users other than the intended users of the product, while the structure from class - and the modern state of mobile apps - encourage deploying design interfaces for feedback from real users and improving the design "live".

The main problem with the Lewis and Reiman article from my perspective is simply that they regard the design process as having a defined end, after which the project is shipped. Though they emphasize the importance of keeping some contact with users (such as through the questionably useful means of assigning designers to handle the customer hotline), it still treats design as having a end point. For many modern applications which allow easy updating, the design cycle never actually ends; it continues throughout the product's lifecycle.


Will Tang - 1/24/2014 14:28:54

The Lewis & Rieman design cycle is very similar to the three stage cycle described in lecture. The design phase described in lecture is expanded in L&R's cycle to include the rough draft of the design (on paper), as well as the initial evaluation of the design's performance, cost of construction, and risk of failure. The prototype phase I feel is essentially the same, emphasizing the idea that the entire system need not be developed at this stage. The evaluation stage is also the same, with L&R focusing on testing the prototype with users. L&R's cycle does differ in that outside of the initial design iterations, it is also important to track the design after distribution to users, and to perform updates when the design becomes outdated.

Even though software distribution is very different today, I think that the design process remains very much the same. In fact, the tracking of the design is probably easier now since mobile applications are so widely distributed and feedback easier to obtain. The revision cycle is also much more accelerated, with revisions occurring much more frequently. Because most people have smartphones now, the entire cycle is probably much more streamlined. I can imagine it being much easier to distribute prototypes to testers, and to maintain close contact with users.

I mostly agree with Lewis & Riemann, but I don't designers taking shifts on costumer hotlines is the solution anymore. In this day and age, every designer involved in the project can have access to customer feedback through forums, etc. There's no need for one designer to relay the feedback to the rest of the team every time some problem arises on the user side.


Sol Han - 1/24/2014 14:39:41

Lewis & Rieman's design cycle overall follows the same general structure as the three-stage cycle described in lecture. The lecture's DESIGN phase corresponds the process of gathering representative tasks and thinking about how these tasks will be achieved; L&R emphasizes the importance of inquiring and understanding the target users, as well as designing with change in mind. The PROTOTYPE phase is briefly discussed by L&R, who suggest using both simple methods (e.g., pen-and-paper) as well as more complex tools (e.g., the UIMS to be used for the final product). The EVALUATE phase, according to L&R, includes both methods that can be done early in the design cycle (e.g., GOMS analysis and cognitive walkthrough) and methods that require user feedback.

The general principles behind L&R's design process hold. Regardless of whether the software is shrink-wrapped or mobile, having iterations of designing, prototyping, and evaluation is a good way to ensure that the software is usable by the target audience and achieves its purpose. In fact, with more and more people acquiring smartphones, L&R's design process may be even more applicable. Because mobile apps tend to be used on-the-go, UIs for the apps need to be especially tailored to the user. Also, since mobile apps tend to be simpler and lightweight, the developers can afford to make rapid changes to their software.

I am skeptical about L&R's criticism regarding the Waterfall approach to software design. While iterative processes like the task-oriented approach have many advantages, it could be argued that the Waterfall model may be more appropriate when there is a need for stable and secure final product. An aspect of task-centered design process that is important to know is that constantly making changes to the product can introduce new bugs and issues.


Jeffrey Deng - 1/24/2014 14:44:28

I think the Lewis & Rieman design cycle is comparable to the three stage cycle because the 3 steps are about designing and figuring what type of problem, and the design cycle also looks at preexisting practices, which is very similar with the three stage cycle.

Lewis & Reiman also have a similar prototype phase of their cycle. They too rough out the design and test it and see how well it works as well as have outside users deal with it too. After the prototyping process, their evaluation includes a phase where they fix their design based on user feedback.

It is slightly different in that the Lewis & Rieman model ensures that their are multiple iterations and that technology is always changing so that the design would have to adapt, and change.

I disagree with Lewis & Rieman in that the design may always be changing because people and needs will change. I believe that it might not be the design that needs to be changed but the overall product. Sometimes products just become outdated and may just need a revamp (with new features and a new interface/design) rather than multiple iterations of changing the currently existing design.


Alexander Chen - 1/24/2014 14:45:58

The Lewis and Rieman design cycle follows very closely with the three state cycle described in lecture. They focused heavily on the design phase, where they mentioned that design of the UI at the conception of a new system was closely intertwined. Because we are focusing on the task-centered design process, it is vital for UI programmers to have a thorough understand of what functions are to be implemented. They need to understand the type of information that a user might use to input into the system, i.e a music file, receipts from the store, or photographs. Only when they step into the shoes of the user can they design an appropriate UI for the task at hand. I also liked the consideration of the hardware. Because there might be size limitations on the HCI, it is important for the UI designers to know about the constraint early on. To get ideas for the design, it is important to "plagiarize" from other UIs that users have grown used to. For example, we use "pull down to refresh", it is almost ubiquitous to any application with a list view which requires updating of the contents over the web. Following design, the prototyping phase, as described by Lewis&Rieman emphasize avoiding creating the mock ups in a more relaxed environment than that of the final application. That is, don't build the user interface yet as part of the application, because there are constraints that you impose on yourself for building a close to finalized version of the UI this early. When a mock UI is ready, users are encouraged to engage with it, for a successful UI is determined by the simplicity and ease of use by the end user. This cycle is repeated through multiple iterations to fine tune the interface, to add more functionality, and to remove bugs.

Today, when software is easily updated over-the-air, it is even more imperative that companies follow the design, prototype, evaluate cycle. The simplicity of pushing an app update over a computer network allows for quick revisions to improve the UI and UX. Additionally, the user base for applications has grown immensely due to the widespread use of mobile devices as well as population growth. This means it is increasingly easy to get a large test base.

I disagree with L&R in the change the design phase. I believe that when an application's core UI no longer meets the needs of people, then perhaps a new application is required, rather than a logic and view overhaul of old legacy code.


Chandler Azling - 1/24/2014 15:33:18

I think the Lewis & Rieman design is a more detailed version of the three stage cycle. I think stages 1.1-1.5 would correspond to design, 1.6 is prototype, and 1.7-1.11 is evaluate. I do think the last steps, however, could correspond to going through several cycles of the three stage cycle. I think they are mainly concerned with evaluation the product, though, so I believe they would still fall under the evaluation stage. Basically, I think the L&R cycle would be the result of taking the three stage cycle and breaking those stages down even further.

I think a lot of the Lewis & Rieman cycle still holds for even today, but maybe the manner in which things are handled is different. For instance, in 1.10 Track the Design, designers can simply look at app reviews as opposed to relying on a customer hotline. I think gathering data for tracking the design and it’s usability would be actually be a lot simpler today. I think also the concept of plagiarizing could be a little different since there are so many different controls being used today. For some actions, there is definitely certain controls that should be chosen, but I feel like there is probably more freedom in choosing how to manage different controls. I think the one part I don’t completely agree with is changing the design. I definitely believe that a design should be updated, especially to address issues, but changing the design too much or changing it just to be fresh could be harmful. I think that the huge changes in an interface (where it basically becomes a whole new interface) can have a lot of backlash, and I don’t think it is necessary to update just for the sake of updating. I do, however, believe that making smaller changes (like many apps changing to a much more flat design, while still holding the same interface) is good.



Ernest Patrick Trillo - 1/24/2014 15:52:54

The Lewis & Rieman design cycle is very similar to the three stage cycle, but is more specific in terms of its steps - steps 1 through 5 fall into the design stage, step 6 is the prototype, and steps 7 through 11 are the evaluation stage. However, one big difference is that the Lewis & Rieman design cycle does not account for the new and emerging technologies of today. Most apps today are constantly getting updated and the Lewis & Rieman design cycle is more geared towards the "shrink-wrapped" products, which are basically done and set once there in the store. To accommodate to modern mobile applications, we need to be able to go through the cycle again and again since there are always new needs apps need to address and so the three stage cycle fits this more as we need to reevaluate and go through many iterations as the times change. I disagree with Lewis & Riemann when they talk about building the product as they fail to test the built product and only test on the iterations of prototypes. I feel that yes they will get a lot of information to help build the product from those tests but not being able to test a more or less finished product before releasing it and going through even more iterations will ultimately bring down the product.


Max Dougherty - 1/24/2014 16:01:20

The task-centered design process maintains many similar principles to the three stage design cycle, but does not emphasize consistent and repeated iteration. Since this design process was established, many of the tools and practices of software production have changed. When software was being sold in stores, UI designers had fewer prototyping tools and without thorough and costly testing, the usability of the finished product was far less reliable.The ability to push software updates to the entire user base has altered the focus of the design process and allow for far more extensive product testing and as a result, more effective user-based implementation changes. Thereby tightening the design cycle and allowing for faster and arguably more effective design, prototyping, and evaluation. This is fundamentally where I disagree with Lewis & Riemann, who downplay the need for extensive and continuous alpha and beta testing. However, the steps of the proposed process as well as that task-oriented approach are crucially important even today. So given the context of the time in which this piece was written, the cost of such product evaluation efforts may have been prohibitively expensive, and their design process decisions should therefore be considered with a grain of salt.


Dylan McCapes - 1/24/2014 16:12:04

I found the design, prototype, evaluate design cycle discussed in class to be similar to the Lewis & Reiman Task-Centered design process. Both begin with by looking at current designs (plagiarize might have been a misnomer) then developing a mock up and design intermittent


Ziran Shang - 1/24/2014 16:15:56

It seems that the Lewis & Rieman design cycle is fairly similar to the three stage cycle from lecture. Both cycles look at the user's background and create tasks that represent real usage scenarios. Both cycles use prototypes/mock ups before building the design. And, both cycles analyze without users as well as testing with users. However, it seems that one primary difference is that Lewis & Rieman analyze the design without users before building or prototyping, whereas the three stage cycle does its analyzing and testing with real users together, after prototyping.

I think one of the biggest differences in applying the Lewis & Reiman cycle to mobile applications is in tracking the design. It is rarer for mobile applications to have a customer service hotline, or to have meetings with users. Instead, tracking the design might rely more on user reviews or feedback through various forums and online sources.

I agree with most of what Lewis & Rieman said. However, I do not fully agree with their point on plagiarizing. Although it is important to create familiar interfaces for users (and perhaps this is even more crucial for enterprise software), if everyone just made familiar user interfaces there would be no innovation. Sometimes a new and completely different interface can greatly help usability. While there may be a learning curve, the end result could be much easier to use, and could end up setting a new industry standard.


Aatash Parikh - 1/24/2014 16:17:34

The Lewis and Rieman cycle is very similar in philosophy to the 3-stage cycle from lectures. Lewis and Rieman basically expand on what each of those stages means. For example, design means: learning more about the user, enumerating their goals and requirements, coming up with a rough design doc, and measuring basic attributes of the design. Prototype: Turn the design into something tangible and usable. Evaluate: Get it in the hands of users, have them test it out, and then use that to further iterate on the design.

Their argument holds even more so today. Now that apps are downloaded, the cycle for collecting feedback, testing, and then iterating on the feedback can go even faster because of how easy it is to push out updates to users.

I somewhat disagree with the topic of plagiarizing. While I often find myself pulling elements from other designs very often when making websites, etc., I feel that looking at existing design solutions can prevent designers from deeply evaluating what are the unique needs of their particular target and whether there is an out-of-the-box solution that hasn't quite been done yet.


Brian Yin - 1/24/2014 16:19:06

The Lewis & Rieman design cycle is a specific implementation of the general three stage process described during lecture. There is however a large emphasis on the 'Design' portion of the process. They go into much detail about the importance of designing appropriate tasks, analyzing existing practices, methods to evaluate designs, and how to make it flexible to change.

The emphasis on the design of the product before user testing could be a result of the state of software distribution at the time. The article was written in the 1990s when software was distributed on CD-ROMs or floppy disks. This made it difficult for designers to distribute their application for user testing and get feedback. However today, where mobile applications can downloaded and updated almost instantaneously, it makes it easier for developers to distribute and update the software as well as responding to feedback. Because of this, designers could potentially spend less time on creating the 'perfect' design, and more time prototyping and testing it on users. In other words, designers have the liberty to use a fail-fast approach to design.

I have some issues with point 1.4 of the reading, where Lewis & Riemann argue that potential features must be reflected in the list of officially supported tasks. While I can see the merit in this (it ensures that time isn't diverted from tasks that users specifically want), I would argue that users sometimes may not even know what they want. As a result, new features that aren't initially represented in the task list could drastically improve a user's experience with a product.


Seth Anderson - 1/24/2014 16:22:08

1) Lewis & Rieman's cycle is very similar to the three stage cycle described in class. If broken in to three sections, their 11 stage process could be seen as a more specific version of the class' 3 stage cycle:

Design: -Figure Out Who's Going to Use the System to Do What -Choose Representative Tasks for Task-Centered Design -Plagiarize -Rough Out the Design -Think About It -Build the Design

Prototype: -Create a Mock-Up or Prototype -Iterate

Evaluate: -Test the Design With Users -Track the Design -Change the Design

Though these are out of the order that they are given in the article, they still roughly describe the three stages seen in class.

2)This argument still holds very true today, if not more than it did when it was originally written. Because of the rapid development cycles that come with app updates, apps are commonly updated at least on a monthly basis. This means the user testing and iteration cycles need to be accelerated from what they are described as in the article, and the designers should be constantly in the process of updating. The biggest change in the design process for apps is to accelerate the Iterate step, and make sure it occurs far more often.

3)I most disagree with what is said in the Plagiarize portion: that if you are choosing between a familiar interface or a new one, the familiar one should be chosen. With the speed technology moves today, users are used to having to learn new user interfaces all the time, and the UI's that are most successful are the ones that change things in ways they wouldn't have anticipated. This could perhaps best be exemplified with the introduction of the iPhone: when it was released, it was a radical new experience, eschewing physical buttons for a tactical touch screen. However rather than reviling this unfamiliar device, users loved it, and it went on to revolutionize technology as we now know it.


Dylan McCapes - 1/24/2014 16:24:40

I found the design, prototype, evaluate design cycle discussed in class to be similar to the Lewis & Rieman Task-Centered design process. Both begin with by looking at current designs (plagiarize might have been a misnomer) then developing a mock up and design intermittent user testing. However, I found the Lewis & Rieman cycle's focus on representative tasks and thinking through specifics such as how many clicks it would take to accomplish those tasks to be a good idea.

I think that their design process is still valid today. Focussing on accomplishing a task while thinking of you design is clearly still a good idea, and I think that most of the initial steps in the design process would be taken today as well, including mock ups and such. If anything it's easier with apps to track the product after initial sale with the use of user ratings. Changing the design is also much easier with updates.

I disagree with Lewis & Rieman's plagiarism section. While I think that it is obviously a good idea to use whatever is out there open source and legal to speed design, I think that to much focus on existing products could limit your view of the problem. If anything, other products should be taken into consideration after at least one possible interface design has been thought of.


Lauren Speers - 1/24/2014 16:31:58

The Lewis & Rieman design cycle has the same structure as the three stage cycle described in lecture. Both cycles emphasize user-centered design, rapid and then more concrete prototyping, and user-driven evaluation and design iteration. However, while the three stage cycle suggests, but does not meticulously specify, the methods that should be used to ensure user-centered design and iteration, the Lewis & Rieman design cycle proposes the selection of “representative tasks” to capture the user profile and to use as a baseline to evaluate design decisions and prototypes. The Lewis & Rieman design cycle is, therefore, a more specified version of the three stage cycle.

Many of the points Lewis and Rieman make about the early stages of their design cycle are still applicable, despite the move away from “shrink-wrapped” store purchases and towards app store downloads. For instance, the importance of rapid prototyping before more labor- or cost-intensive prototyping remains unchanged by this switch because the designers experience the benefits of this design process (i.e. fewer wasted resources) before the product is sent to market, whether that market is a physical store or an app store. Furthermore, reliance on manuals when using software has decreased with the move away from “shrink-wrapped” store purchases. As a result, Lewis and Rieman’s directions to include familiar features, such as copy and paste or traditional naming procedures, in new products are even more relevant since users are less likely to read a manual.

However, some details of Lewis & Rieman's design cycle are slightly less significant now because of the shift towards app store downloads. Consider their argument that “a novel interaction paradigm that’s better suited to your application” has a higher risk of failure and should likely be avoided. While some truth in this statement certainly remains, app stores have made it easier for people to try out new applications, and as a result, people are more accustomed to learning how to use new products than they were during the time of “shrink-wrapped” purchases. In this case, I disagree with the strength of their warning against new interfaces.


Daphne Hsu - 1/24/2014 16:37:15

Both cycles are very similar in that they both stress thinking about the product from the user's perspective, and basing the entire cycle upon this relationship. The cycles are structured a little differently; the Lewis & Rieman cycle wants the designer to create a rough design of the product, think about the design from the user's standpoint, then create a mockup, whereas the cycle described in class can jump right into the mockup after the designers understand the user's needs. The cycle from lecture doesn't say anything about iterations, which the L&R cycle does before the design is even completed. The L&R cycle talks about the life of the product after the design is completed, such as the designers keeping track of their product, and making changes to it as time goes on, while the cycle from class does not.

I think the last step in the L&R cycle, "Change the Design", will have a much bigger impact in today's industry than it might have had back when the article was written. Since mobile applications are easily downloaded through app stores, designers making updates to applications and pushing out these updates to users can happen very quickly. Many app users write reviews in the app store and through other outlets, so app designers can easily keep track of how their application is met by the market, and have access to features their users are happy or unhappy with. They then have a lot of information they can use to make new iterations of their design, and can easily push their updated product out through the app store. For the most part, I think the initial design, testing, and iterations of the design cycle is similar, but that there should be a new section at the end for making iterations after the product is released to the market.

I somewhat disagree with Lewis & Riemann when it comes to their section about plagiarism. I can see how copying existing interfaces can be useful. For example, if I were to make a new music playing app, I would copy over the symbols for turning up and turning down sound, because they are intuitive and most users will immediately recognize them. However, I believe that sometimes what the target user is familiar with may not be the best approach. For example, imagine that an email application's menu icon was three vertical lines -- something completely unintuitive, but users have gotten familiar with this symbol. If I were to copy over their menu interface, I would want to make my menu icon three vertical lines, because I think it makes more sense to the user if a menu was represented as a list of items. I think if a designer truly believes that a feature can be improved upon to help the user better utilize their product, he or she should change that feature, even if the user is familiar with the existing feature.


Opal Kale - 1/24/2014 16:54:35

The Lewis & Rieman (L&R) design cycle is similar to the 3-stage cycle described in lecture, but more detailed. The L&R design cycle states to first figure out who's going to use the system to do what, choose representative tasks for task-centered design, and then plagiarize. This is a detailed version of the first step in the 3-stage cycle (“coming up with design ideas”) as L&R emphasizes looking at other models and thinking a lot about the task-design before making a prototype. The next step in the L&R design cycle is to rough out a design, think about it and then create a mock-up or prototype. This is similar to the next stage in the 3 stage cycle, rapid prototyping. Finally, the last steps in the L&R cycle are to test the prototype with users, iterate until the prototype is perfect, and then build, track and change the design. This differs from the last stage in the 3-stage cycle in that although both evaluate the prototype with users and iterate through the cycle again, the 3-stage cycle never gives insight into actually building the design of the prototype.

Although this article was written at a time when most software was sold “shrink-wrapped” in stores, this argument does hold equally for today when most mobile applications are downloaded through the app stores. This is because it is still important to figure out the user, plagiarize (which is made easier since you can look at other similar mobile apps in the app store), and rough out a design. A prototype should still be created before the app is deployed because it’s important to have a clear plan on what the design is going to look like. Finally, testing it with users is important, and even made easier since people can rate apps that are downloaded—thus, you get immediate feedback from your users! I think that the process might even be easier today because you can easily get feedback and change it and send it out to real users immediately.

I disagree with Lewis & Rieman in that I think that in modern day, you should build the application first and then test it on users and iterate through the cycle after you get their feedback. I don’t think you should test a prototype and then iterate and then build the design in the last stage because a prototype might be a detailed sketch of what the application is, and is not as interactive and real as the actual application will be. Also, this is particularly aimed at modern day mobile applications where if you deploy a finished app, it’s easy to change it, whereas before mobile apps, it would have been hard to change some type of software if it was already deployed.


Sang Ho Lee - 1/24/2014 17:16:52

The Lewis and Reiman design cycle is very similar to the three stage cycle described in lecture. Much like the three stage process, Lewis and Rieman actually begin the design process by thinking about what the task is about and all the necessary parts before prototyping begins. And when prototyping is done, they recommend to do it by hand (pen and paper), comparable to "low fidelity techniques" because programming can lead to a subconscious commitment to not-yet-ready design ideas. User testing is greatly encouraged (comparable to evaluate) and iteration is important for both design cycles as well.

I believe that their argument about the design process holds equally true for the software of today. It is especially true in the "plagiarize" section where a lot of design aspects of mobile apps are almost universally used because users simply are used to certain gestures. However, because the mobile hardware is changing so rapidly and the hardware is not as stagnant as PCs, designers may actually have something to gain from not plagiarizing and searching for innovative uses of mobile hardware (such as the camera, new touch gestures, etc.) Tracking and updating the design is easier and more accessible than ever because our apps are often connected to the Internet, and developers can get analytics data from users that directly quantify how the interface is being used. And because hardware changes and software platforms changes, it is ever important for developers and designers to remain aware of the constantly changing design paradigms and user demands.

I believe that there should be more emphasis on how designers interact with other engineers (front-end to backend) from the beginning of the process. I believe it's important to consider the technical viability of a design project from the beginning, and while Lewis and Rieman emphasize such a relationship between the designers and the users, there should be the same between the designer and the non UI engineer.


conan cai - 1/24/2014 17:19:18

I think that the Lewis & Rieman design cycle does agree with the three stage cycle. In the cycle described in reading, the first few steps (figuring out users, seeing whats already there and creating a rough design) are all intuitive. A person will naturally follow these steps when designing something even if they don't know they are following a specific design principle. Similarly, the rest of the steps - design and evaluate have their equivalent steps in the Lewis and Rieman cycle. I feel like the steps described are steps that a person would naturally take while trying to design something. So both design cycles are describing the same thing, just with different words.

I don' think that their argument for the design cycle necessarily applies to today's software. The Lewis & Rieman cycle stresses the importance of testing and making multiple iterations of a product before release. However this was at a time when software was packaged as a physical product. Any mistake would result in a very costly recall and updating any bugs in the software would be a nightmare. However with today's apps, the importance of testing is still important, but not as important. Any bug fixes and be easily pushed out as an update that can be instantly downloaded over the internet. As a result the design cycle is shortened. Companies can now quickly develop software and push it out as quickly as possible to start earning money as soon as possible. The users become beta testers because after all, in today's internet connected world, a bug fix is just one update from the app store away.


Daniel Koohmarey - 1/24/2014 17:23:29

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

  Lewis & Rieman’s design cycle is a similar and more detailed task-oriented version of the three stage cycle described in lecture. The design stage of the cycle from lecture is reflected by figuring out who’s going to use the system to do what, choosing tasks for task centered-design, using relevant pre-existing interfaces to inspire design, creating a rough paper design, and then thinking about the amount of effort required to use the UI. This entire process is a more specific task-oriented design process than the more general design stage from lecture. The next two steps in Lewis & Rieman’s design cycle are the same as the next two stages from lecture, in that a mock-up or prototype of the design is built, and then tested with users. This corresponds to the prototyping and evaluation stages of the design cycle, and the next steps in Lewis & Rieman’s design cycle (iterate, build, track and chance the design) reiterate the cyclic nature of the three stage cycle from lecture. 

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 today, when most mobile applications are downloaded through app stores?

Their argument about the design process does hold equally for today as all of the steps in the design process focused on the design and not the technology being designed for. The final point “Change the Design” of the design process holds true and is evident in mobile applications. After downloading an app in the app store, developers can push updates and changes directly to user’s phones. A good example of an app that changes its design to adapt to user concerns is the Facebook app, which made significant UI changes from its first to current version. Parts of the process slightly change with current technology, as the app can be evaluated by users remotely, who can opt in to have their use logs sent to the developers.

What changes in the design process for these apps? Where do you disagree with Lewis & Riemann? Why?

Users’ keystrokes are translated into button presses, so the GOMS analysis from the “Think About It” section of the design process will have to be updated to analyze user touch and gestures. The “Iterate” portion of the design process will also change to be more lenient, as its easier to update apps/make changes after initial release then it was in the shrink-wrap days. Also in “Track the Design” they suggest designers temporarily man the customer hotline, which has now changed to support email or suggestions. The entire task-centered design approach seems to be skewed towards productivity apps which actually have a task/purpose/goal. A large number of apps are games, whose task is to waste time in a fun way. Therefore choosing representative tasks may be a problem. This is the only place I disagree with Lewis & Riemann, in designing an app towards certain tasks. This could limit designers creativity, and a more general design approach may be more suitable for todays varied app market. The rest of Lewis & Riemann’s design process is like the three stage process we learned in lecture, which stays the same and is a good basis for designing mobile apps. I also agree with the HyperTopic content’s assertions that a single design team that handles all aspects of development is better than splitting design and development.


Justin Chan - 1/24/2014 17:25:04

The Lewis & Rieman design cycle is pretty similar to the one discussed in lecture. Both involve a “high-level” planning of the product, a mock-up stage, and an evaluation phase where possible changes are made. However, the cycle discussed in lecture is more clearly presented as a cycle, which implies constant, rapid iterations. The way I interpreted the Lewis & Rieman design cycle was that it was more of a “slow-churning,” linear process, where “breaks” between cycles were more apparent.

Lewis & Rieman’s argument about the design process is more important today given the limited real estate that mobile applications require. You are essentially trying to boil down a full-fledged website or program into 4-5 inches of space while keeping everything easy and intuitive – much easier said than done. Given those constraints, there’s understandably a MUCH bigger emphasis on UI now. For example, the Facebook Messenger app was getting complaints for a while on not adopting iOS7 “themes” fast enough. Nothing wrong with functionality, speed, or anything like that – users just wanted the app to look different!

The whole concept of “versions” has become a bit muddled with the advent of mobile applications – “updates” is probably a more appropriate term these days. I think their argument becomes a bit less relevant and more “compressed” given this change. Today, updates don’t necessarily need to be UI based – half of all my app updates simply just say “bug fixes.” Obviously some do, and in those cases, the process they go through is much quicker given that users are expecting updates at faster intervals than let’s say, Word 2007 and Word 2010.

I thought the whole plagiarism thing was a bit of cheap ploy to gain attention and entire sound advice. It’s definitely good to borrow ideas, but not at the expense of stifling your creativity. Progress requires change, and you won’t get any if you always stick to the script. Facebook has changed its UI a ton, each time pioneering something new. Obviously, there were some people who hated it, but eventually we’ve always eventually accepted these new rules as de facto standards for UI.


Jaesang Kim - 1/24/2014 17:34:38

The Lewis & Rieman design cycle as a whole seems very similar to the three stage cycle described in lecture. Steps 1.1 to 1.3 would be the design stage, 1.4 to 1.6 would be the prototype stage, and the rest would the evaluate stage and the iteration afterwards. Both cycles are efficient because they seek to bring satisfaction to the users while also reducing the cost and time of development, and continue to improve in performance or usability by iteration.

Although this article was written during the time period when most software was sold "shrink-wrapped" I believe that Lewis & Rieman's argument still hold equally today, because according to the hypertopic section where it discusses the weaknesses of Waterfall designing, I thought that it doesn't matter whether the applications are downloaded through app stores or not when it comes to the quality of the application and the cost and time to develop the software. Personally, the three stage cycle and Lewis & Rieman design cycle both seemed close to the agile development, which is efficient. However, regarding the applications downloaded through app stores, the main difference in the design process that I thought of would be the fact that downloadable mobile applications are usually updated ever so frequently; thus the Iteration, 1.8, would occur more often than how Lewis & Rieman describe it. I believe this is the reason why there are more frequent updates for mobile applications compared to software on computers.

I agree with most of Lewis & Rieman arguments, except the second paragraph in 1.7 Test the Design with Users. I don't think videotaping the tests is required. I believe that surveys, reports or feedback from users are good enough. That is my opinion though.


Robin Sylvan - 1/24/2014 17:42:53

The Lewis and Rieman design cycle appears to be similar in a lot of ways to the three stage design cycle we learned about in class, but it delves deeper into the actual steps, especially in designing. Task centered design focuses a lot on taking tasks that people are currently doing, and creating tools to make them easier. They even put special focus on "plagiarizing" - looking at what other people are doing to help put a design together. Prototyping seemed very similar in both cases, though Lewis and Rieman focused a lot on user testing, and placing developers in close contact with testing / customer support to get new ideas for improvements. While much of the article still holds with modern day, developers are able to get away with more in the modern day of updating applications. Users nowadays expect a few bugs when a product is first placed out in alpha or beta stages, and nearly all applications we have receive regular updates and bug fixes. It was much harder in the past for developers to fix these sorts of bugs, so there needed to be stronger emphasis on thorough testing. I believe Lewis and Rieman's ideas are fairly on point, but they focus a lot on doing tasks that already exist in ways that we currently do them. Something beautiful about the design process and innovation is creating new things for users. I felt the tone of Lewis and Rieman's ideas were very much trying to box in a method of designing. Three stage design is nice in that way as it didn't go into specific details of the design process, as it was more general about the actual methods for designing and coming up with ideas. Part of new innovation is creating new things that people are able to do, not necessarily based upon a current task.


Shaina Krevat - 1/24/2014 17:51:53

The Lewis Rieman design cycle has a few more steps than the three-stage cycle described in class, and ultimately fits into the three stages, though it adds an extra loop between prototype and evaluate. In the “design” stage, we have: figure out who's going to use the system to do what, choose representative tasks for task-centered design, plagiarize, rough out a design, think about it. In prototype: create a mock-up or prototype and test it with users. Then there is Lewis and Rieman’s iterate, which is an extra loop that involves taking feedback from users testing the prototype, redesigning parts, and prototyping and testing it again. After this, the process goes into evaluate, where the application is built, tracked, and assessed. After that, Lewis and Rieman’s next step is “change it,” which feeds back into the “design” stage.

Yes, this argument still holds today when it comes to downloaded applications. If anything, certain steps make even more sense. The “plagiarize” step is essential, going by Lewis and Rieman’s definition of making sure to keep certain UI actions consistent between a new UI design and a leading application that has similar functions. On most smart phone applications, one can get to the “next page” by “swiping” left on their phone. If an app didn’t have that feature, but instead required a user to shake their phone left to get to the next page, that would be very confusing, especially when users had to switch between the two methods when using two different apps. Furthermore, it is now much easier to get data regarding users’ response to a UI. On app stores there is the option to rate, comment, like, recommend, etc., which all of the designers would have access to and be able to “track” and evaluate as per Lewis and Rieman’s cycle.

The step that changes in the Lewis and Rieman cycle is the last one, “change it”. In this section of the reading, they describe “a next revision of the design,” which they imply will come out every couple of years. With the downloadable content, changes can be made to the app instantly after it’s released, responding immediately to any changes in the market, as opposed to waiting for a new release. Because of the instant feedback provided by users, the cycle never truly ends until the design team decides to stop working on the product.


Brian Sherman - 1/24/2014 17:54:12

The design cycle described in the reading follows the three stage cycle completely, and simply breaks each stage down into multiple steps, though it does discuss some pre-design elements not mentioned in the three stage cycle. Steps 2-5 are analogous to the "design" stage, Step 6 perfectly mirrors the "prototype" stage, Step 7 mirrors "evaluate", and Step 8 reflects the fact that this is a cycle that involves many different prototypes and evaluations.

Lewis and Riemann's argument still generally holds today. However, since users now download mobile applications through app stores, it becomes much easier to roll out updates and bug fixes for these applications. As a result, this would change the nature of the steps of tracking and changing the design after the app is released, a cycle in and of itself of actively responding to consumer feedback.

I can't say that I outright disagree with Lewis and Riemann anywhere, but I am skeptical of their implication that user familiarity is almost always preferable to a more efficient solution. It just seems inimical to progress if good changes are abandoned so as to not force users to learn something new, especially when they might realize that the new was is, in fact, superior. Certainly, user familiarity is important, but it seems that Lewis and Riemann advocate coddling users too much.


Seung Kwon Jung - 1/24/2014 17:56:57

The Lewis & Rieman (LR) design cycle is essentially the same as the three stage cycle. However, the LR cycle goes extra lengths to flesh out much of thought processes that should occur for each of the three stages. The first three sections of the LR cycle all deal with what you should be thinking about in terms of your product's functionality and your target audience. Sections 4 and 5 have you net out how the audience may use and misuse the product. The next section creates the functional prototype. Section 7 is evaluating the product through user testing. Section 8 simply tells you to cycle back as needed through the previous design steps, and the last three sections are factors that you should consider throughout the entire process.

Some of the LR design process does not hold equally today. Much of the thought processes stay the same (sections 1-3) since they are universal for any user interface design. However, some of the design factors (such as those in section 5) are not as pivotal considering that the cost of downloadable apps is much lower than shrink-wrapped software. An app designer today can rely on user testing much more since it is so readily available to him, costs less for possible mistakes, and is easier to update downloaded versions.

I disagree with the LR design cycle on section 2 and 3. It is restricting brand new innovation since it encourages you to rely on what users are used to. It makes sense to it that way and it's certainly more error-proof, but it inhibits entirely revolutionary interfaces.


Romi Phadte - 1/24/2014 18:00:02

The Lewis & Rieman design cycle are composed of many more steps than the three steps we learned in class. These steps are: figure out who's going to use the system to do what,choose representative tasks for task-centered design, plagiarize, rough out a design, think about it,create a mock-up or prototype,test it with users, iterate, build it, track it, and change it. This cycle seems to be a double loop of the cycle we learned in class. We evaluate the problem first, then design on paper, prototype with people, then evaluate what needs to be changed, then design again, build it, and evauate/change it. These cycles are similar; however, the one we have in class implies a much more brute force approach than the methodical one suggested by Lewis and Rieman.

Surprisingly, a lot of the advice is presented by Lewis and Rieman are still relevant today. App developers still have to figure out the design principles of the environment (Apple/Android) and design the app to encompass such principles and trends. Even today we still plagiarize (infinite scroll, pop out sidebar, ect), gain feed back from users (app reviews), and release updates. However, today, since apps are so cheap and easy to download, the fidelity of the users are much lower and the updates are more frequent. Today, this cycle hasn't changed, but rather has sped up significantly.

I disagree on the idea that it is always a good idea to stick with a paradigm that users are already familiar with. I feel like this decision needs to be made on a case by case basis. One example is Apple's desire to maintain familiarity in iOS design through skeumorphism. The result was an extremely cheesy design that contrasted heavily from their futuristic hardware. This year, apple made a switch to give up what users were familiar with for a more flat and modern approach. I believe this was done in good taste and is a good example of how breaking existing convention may be beneficial.


Christopher Chiang - 1/24/2014 18:10:46

The two cycles are quite similar. It is just that the Lewis & Rieman cycle has extra details involving a task center design process and also has more details of actually building the product. But is still follows the 3 stages, even though each stage is split up into smaller parts. The main difference for software today, i think is the ability to instantly reiterate your product. Updates on the app store could be instantly deployed to make drastic changes. I think the evaluate and iterate part of the design process is much easier and could be done live without a prototyping phase. Instead one could just utilize a limited beta release. I feel like there is definite answer on how to develop software. It all depends on the software you want to build. Different specifications would different design processes. So I like many point in the Lewis & Rieman cycle but it might not always be the optimal choice.


Jiahao Li - 1/24/2014 18:15:55

The Lewis & Rieman design cycle is a more detailed version of the three stage cycle described in lecture. They are basically the same thing, but the L&R design cycle breaks down the cycle we talked about in lecture into more steps.

Their argument about the design process does not hold equally for today. In the iteration part, they stop when specific usability object is met. However, we are not supposed to stop at that point right now. We should try our best to keep updating our product to fix bugs and improve usability. As a user, not getting an update for an app for a while makes me feel the development team does not care about this app any more.

Except the point I talked in the previous paragraph, I basically agree with what L&R talks about.


Jeffrey Butterfield - 1/24/2014 18:18:45

Q1: Both the lecture and Lewis & Rieman follow similar steps when discussing the design cycle, though the reading goes into greater detail and adds a few extra considerations. Both acknowledge the importance of beginning with user task analysis and understanding the user’s high-level needs and literal tasks being performed, as opposed to a waterfall design approach centered on system specifications. Both suggest the different ways to approach prototyping, with the reading insisting on a “paper first” approach before any interactive/computerized approaches. The evaluation step is also covered by both, again with the reading including more insights like the fact that new problems can be created by fixing old problems discovered during the testing phase.

Q2: While parts of the design process need modification, most do not. Consider Google Docs, which is continuously improved and updated due to its nature as a cloud service. Much of the thought behind the design cycle transcends the details of the software’s distribution. For instance, the advice from the “Plagiarize” section still holds true for Google Docs: Google would do well to mimic the most salient and widely used word processing software (i.e. Microsoft Word) to reduce confusion of users coming from that platform. Of course, the iterations described no longer need to come as packaged upgrades sold separately but instead can be deployed instantly on a server or perhaps through an app store. Testing can now also continue after a product is released by sending usage information from endpoints back to designers.

Q3: I am somewhat skeptical about how effective the “thinking aloud” step works when the prototype being tested is not interactive or computerized at all. I can envision basic feedback about the design being helpful, but certain UI elements like menus and views really can only be validated or rejected by actual interaction with them. The sentence “the purpose of testing: not to prove the interface, but to improve it,” is reassuring. I am interested to see how much improvement such testing with prototypes can inspire.


Erik Bartlett - 1/24/2014 18:19:15

The L&R process is very similar to the three step process from lecture. While they seem to focus a bit more on being "Task-Centered", L&R have the same general process : Create a crude design out of anything once you've come up with an idea, use that design to find bugs and improve the design, create a prototype to show the client or to further explore the experience for flaws/bugs, and finally start building the design. L&R also focus more on iterating before release, which I assume comes from the older background.

I think for the initial phases of design their process holds true. When initially designing an application - you do not want to waste time implementing the application in code or committing to a design decision too soon, and clearly having beta testers for your design is something that still happens today with limited releases and games. The one difference is in the iterating of the app. Developers have to be able to iterate on their "final" design and track its popularity to continually improve on it, while before app store downloads you just had huge releases every year or two without being able to fix huge bugs.

I agree with L&R. The idea of Task-Centered Design and making sure every component is used for one of these tasks is great for design. By keeping the task at the forefront of the design it helps to keep the interface from becoming packed and difficult to navigate. It allows the designer to make the design as simple as possible. I also agree with the "Plagiarize" portion of their design process - there is no reason to redesign the wheel. If a type of design or action has already been ingrained into the users' heads then there is no reason to make them have to learn a different action.


Sanchita Shandilya - 1/24/2014 18:23:09

I believe that the Lewis & Rieman design cycle is quite similar to the three stage cycle--however it is a more elaborate version of it. The first three steps of L&R focus on coming up with the design, taking a very task centric approach. Plagiarize extends into prototyping and building on existing interfaces. Thereafter we go back into designing theoretically, and finally building the prototype. It appears that the L&R process moves significantly between design and prototyping. The final stage is testing which is analogous to evaluation. And then based on the evaluation we make changes to the design again.

I think the cycle is still applicable to a certain extent. Mobile applications still have to create interfaces that fit into the tasks their users need them for and the environment that the user is familiar with. However, in terms of testing and evaluation, the cycle isn't applicable. First level testing and improvement is important, but further iterations can happen even after the app is released based on feedback from the users. Also, such an elaborate process before creating the first design is probably not needed as there is greater ability to get reviews quickly and from more people. I believe the shorter three stage design cycle taught in lecture might be more applicable today.

The idea that I disagree with is that the iterations should stop when usability objectives (presumably set by the designer based on user's feedback) have been met. However, I think these objectives should be flexible and iterations should continue until resources are available. Also, not merely usability, but aesthetics, creativity, convenience etc should also be incorporated in the objectives.


Cory McDowell - 1/24/2014 18:24:14

The Lewis & Rieman style had similar underlying principles. With L&R, we still design with “choose representative tasks for task-centered design“ and “rough out a design”, then we prototype with “create a mock-up or prototype”, and then we evaluate with “test it with users” and “change it”. One difference is with the “plagiarize” step with L&R. I like using existing products as an inspiration to establish familiarity with your product.

I think this argument about the design process does hold equally for today. With the mock-up and iterate principles, customers get what they want, which is essential to today’s design principles. Similarly with outlining all of the tasks an app will have, the features of an app are key to selling an app today. Not much changes for applications downloaded in app stores, as people still want to know the features of their app before they download it. Also, app stores have reviews of the product, so it’s even more important to launch with a working product.

I do agree with Lewis & Riemann with their overall design principles, but there were a few points I did not agree with. They said that for Mac users, an app should have a copy and paste feature because other Mac apps had that. I don’t agree you should have a feature that is not benefiting the app simply to familiarize the user with the app. Also, they said, “the best answer is to stick with what the users know, even if it does require an extra keystroke or two.” I think the simplest user experience is necessary, so extra keystrokes shouldn’t be required to create familiarity.


Meghna Chatterjee - 1/24/2014 18:37:09

The steps in the Lewis & Rieman design cycle are (1) figuring out how the users will use the system, (2) choosing the representative tasks for the task-centered design, (3) finding existing interfaces and building ideas from those, (4) making a rough description of the design on paper, (5) creating a prototype, (6) testing with users, (7) analyze and try to incorporate (if possible) fixes to any issues brought up after testing, (8) building the interface, (9) tracking how the system is doing after release, and, finally, (10) changing and updating the interface every few years. Though there are only three stages in the cycle discussed in lecture, the several stages in the Lewis & Rieman cycle can be grouped into these three categories. Steps (1)-(4) can be grouped into the 'design' group. Step (5) is the same as the 'prototype' stage. Lastly, steps (6) - (10) all fall under the 'evaluate' category. Thus, though different in number of stages, both cycles are essentially the same.

The argument about the design process, for the most part, still holds for today. It would be easier, with simulation software, for instance, to build a prototype and fix potential bugs and issues before release. However, applications for the mobile apps, for the most part, will have to be updated more often than just every few years. Even if no bugs show up, users can get bored, for example, with a game with only a certain number of levels. The designers of the application, then, would have to add updates to the game (maybe new characters or levels) every now and then to keep active public interest. However, all other steps in the process are still important. It is still necessary to plan out the design process and obtain information from the intended user audience to determine how the application should be made and what features should be added. It is also still important to track the application after release and update it when necessary or applicable.

For the most part, I agree with Lewis and Rieman. The only part where I would disagree is in the 'change' step, for reasons mentioned previously regarding mobile applications. Since much software currently is released online, it may be cheaper to not do an extensive check for bugs and issues ahead of time and instead add patches and updates periodically for users. However, even if all bugs are somehow resolved prior to first release, user feedback is obtained much faster these days. Thus, it is important to constantly observe user feedback and, for many applications, to keep updating their products to satisfy (or maintain the interest of) their users.


Meena Vempaty - 1/24/2014 18:42:36

The Lewis & Rieman design cycle is a more detailed and specific instance of the three stage cycle described in lecture. It starts from evaluation (finding users and the tasks they need to accomplish) and details a process for designing and prototyping, followed by continued iteration the same cycle. The article's argument for task-centered design becomes even more relevant in the current age of app stores, because most mobile applications are meant to assist with very specific tasks, whereas older software was more general. Because of this, many applications are better designed as linear flows through a task's process than as generalized tools for multiple tasks. I think that Lewis & Riemann should have included a testing stage at the very beginning of the process to find the tasks that should be focused on. Misjudging people's needs is an easy mistake to make, and one that can be eliminated by testing assumptions before even deciding what task or tasks to focus on.


Henry Wu - 1/24/2014 18:43:50

From a high level, the Lewis and Rieman design cycle matches the three stage cycle described in lecture pretty closely. We can identify in the Lewis and Rieman cycle the same key components of design, prototyping, and evaluation. In the Lewis and Rieman cycle, they stress components like defining tasks to be at the center of design, plagiarizing, and roughing out the design, which closely mirrors the practices of task analysis and contextual inquiry found in the three stage cycle (namely, observing existing practices, creating models to gain insight, etc.). The prototyping phases are also similar and both cycles emphasize building a mock-up of the design, either on paper, or using slightly more advanced tools. And finally, the evaluation phases of both cycles is equally important to gain feedback from users, in an effort to make improvements to the existing design. Both cycles also emphasize rapid iteration in order to build the best design, so overall, both cycles are quite similar.

Most of the arguments about the design process still hold today, even though most mobile applications can be downloaded through the internet/app stores instead of bought in person. Nowadays, though, iteration has become an even more important factor, since it is that much easier to get your changes out into the public and have people test / provide feedback on your design. I think some parts of the design process like the research, and the "thinking about it" phase can be less emphasized, and more favor can be given towards prototyping and evaluation, since it is much easier to mass market and gain feedback since the world is so much more digitally connected these days. It is a lot easier to gain feedback in today's world, so that should be taken advantage of and used in the design process.

Some areas that I disagree with Lewis and Rieman are in putting the description of a rough design on paper. I think there are a lot of tools out there nowadays that can more effectively communicate a rough design instead of an attempt on paper, and I think we should employ those tools if possible. Another area in which I disagree with Lewis and Rieman's cycle model is in the way they propose carrying out the testing. They propose actually videotaping the tests, and then observing these for analysis, but I don't think that is too practical in the modern world.


Sol Park - 1/24/2014 18:45:29

The three stage cycle described in the lecture are similar to Lewis & Rieman design cycle. The design stage from the lecture includes figuring out who's going to use the system to do what, choosing representative tasks for task-centered design, plagiarizing, roughing out a design and thinking about it stages from Lewis&Rieman. The prototype stage from lecture includes creating a mock-up or prototyping stage from Lewis&Rieman. The evaluate stage from lecture includes testing it with users stage from Lewis&Rieman. These stages goes in cycle(iterate from Lewis&Rieman) to make better software.

Their argument about the design process does not hold equally for today. For mobile applications, Rather than videotaping the tests, we need to find the intended users as many as possible and get a feedback from them. I think videotaping the tests doesn't help since we don't know what they are thinking by watching people using the app. I think well commented feedback will do better.

Lewis & Rieman argues that to track the design, rotate the designers into temporary duty on the customer hotline. I think this is not necessary these days. With mobile applications, anyone can be a customer by just downloading it through app stores. Users rate them and designers can take a look at the comments.These days people like to comment about the softwares. Also, I think there are plenty of other ways to track the design instead of rotating the designers to customer hotline.


Patrick Lin - 1/24/2014 18:52:50

Many of the steps in the Lewis & Rieman design cycle are the same as those described in lecture. Although broken down into smaller, more detailed points, many of the details can be grouped into designing (1.1-1.4), prototyping (1.5, 1.6), and evaluating (1.7-1.8) as in the three stage method. The main difference is, however, that there is a discrete step for building a "final" product and tracking/preparing to change it in the L&R cycle, whereas the three stage method is an endless loop.

This most likely is because of the different dynamics users have come to expect when purchasing and using software. Instead of buying physical CDs of finished products from a brick and mortar store, the prevalence of the internet and the modern app store in today's society has given consumers the expectation of constant patches, updates, and features added in continuously after the initial download. This correlates with the widespread adoption of the Agile methodology and its quick, constant iterating of an existing product over a more traditional, linear waterfall method. Most software developers no longer accrue large amounts of changes and fixes to save for a sequel to their product a few years after its release, as described in step 1.11 (though some, like Microsoft Office do), and the same applies to designers.

Most of the points I agree with, except of course the disjoint between "finishing" a product and building up to create a successor, which is mostly an outdated principle. There could also be arguments against the "plagiarism" step, especially as so many apps on the market today are merely inferior copies of already existing, popular apps that do not even innovate in UI design. Sometimes a better interface can Still, the point about familiarity still makes sense, especially as interface trends constantly change.


test - 1/24/2014 19:10:29

test


Everardo Barriga - 1/24/2014 19:15:49

The task-centered design process described in the reading bears a lot of similarity to the design cycle discussed in class. They both start off with getting an understanding of the user and how the interface fits in the scope of the user’s life. There is a strong emphasis on creating tasks or scenarios that are completable and that should be the litmus test for all of your functionality. The next step involves actually prototyping and both design paradigms include using paper to sketch out an implementation for the interface. Both processes also call for you to actually start building the interface or a mock-up of it on the computer using some sort of software like UIMS. Then you start to test the interface with real target-users. Both design processes stress the importance of testing and making changes accordingly. I think the design cycle has essentially taken the task-centered design pattern and simplified it putting less emphasis on tasks and more emphasis on iterations.

I think this argument definitely holds for a lot of the apps being built today and put on the different online stores. The authors in the article seem to be a lot more cautious though regarding money and resources simply because once their products are out and shipped it’s difficult to make large changes without having to recall the product you made. In other words, the app store provides instant feedback from your customer and target-user. You can tell how popular your product is in an instant whereas if you were to physically ship your product that feedback would be communicated more slowly.


I didn’t particularly agree with section 1.5 and some of the methods they used for testing whether the system worked well. For example they noted that counting keystrokes and the number of mental operations were useful for measuring the tasks the design is meant to support. I think that those examples are too case-specific and think that it all depends really on the system you are trying to build. I also didn’t particularly agree with the immense emphasis on tasks. I understand how they can be useful but there are certain features on some of the software I use that don’t accomplish any particular task but are fun to use nonetheless.


Prashan Dharmasena - 1/24/2014 19:17:47

1) The Lewis & Rieman cycle is actually quite similar to the three stage cycle, except a bit more detailed. For example, 1.1 - 1.5 make up the "design" stage, 1.6 is the "prototype" stage, and 1.7 - 1.11 is the "evaluate" stage.

2) I actually don't think much has changed in the design process. Apps can be released earlier and more easily updated. They also have lots of the framework (the low-level plagiarism) built for them, so they can skip that step. I believe that most iteration nowadays occurs after the app has already been published. I'm currently working at a startup that is building an iOS app, and the current philosophy in the app-dev world seems to be "publish something that works and has the general design in place, and keep iterating on it." For example, Snapchat has gone through several iterations of their interface, going through many different styles, but the general layout and interface of the app has persisted.

3) I disagree on the plagiarism section. While I do agree that copying low-level design is good and sets uniformity across apps for users, I don't believe that copying high-level designs is always the best way to proceed. It is always good to try and find a better way to do things, especially if you are trying to differentiate your product from the competition. Though, as Lewis and Rieman point out, if your application is complex, familiarity is your friend.


Anthony Sun - 1/24/2014 19:23:37

The L&R design cycle is fairly similar to the three stage cycle. 1.4 covers designing, 1.6 the prototyping step, 1.7 the evaluation, and 1.8 iteration.

The difference is the small focus on "usability objectives", which L&R describes as "target values for things such as speed to perform representative tasks and number of errors allowable", which seems more targeted toward the enterprise market, rather than the consumer market.

This can be attributed to the "shrink-wrap" mentioned in the prompt, where software was sold to fulfill a specific need, where the end user provided the income and was the customer.

Today, a lot of software is developed for consumer users, and I think is mainly designed to drive user engagement, which can then be used to sell advertising presence and collect user data (e.g. Google). The goal is to have the user spend as much time as possible, whereas the previous goal was to perform tasks as efficiently as possible. This requires a different focus during the design cycle, but the basic structure of the design cycle remains similar.

I don't fundamentally disagree much with Lewis and Riemann. They have the same basic process and structure, with a different focus and goal. The focus isn't "wrong", it is just targeted toward a different market than most of today's software. However, I think there is still a use for that focus in some niche enterprise software.


EunSeon Son - 1/24/2014 19:26:36

Lewis & Rieman design cycle includes a stage gets users test the design and improve based on their responses. Nowadays, most mobile apps are downloaded through app stores, and designing process period needs to be shorten. It's better to have users test the design and let design process be user-test driven.


Dhruv Garg - 1/24/2014 19:27:47

The three stage design-prototype-evaluate cycle is very similar to the L&R design cycle. At a first glance, the L&R cycle seems to provide a more detailed version of the three stage cycle. The first three sections seem to encompass the Design section, the second three sections seem to encompass the prototype section, and the section after consider evaluation and repeating the cycle.

Upon closer inspection we realize that the L&R cycle is more in tune with designing full fledged (almost enterprise level) apps from the start rather than starting with a small feature set and expanding as the iteration occurs. We can see, especially in the later sections that there is a serious emphasis of getting it as right as possible before deploying, rather than the quicker cycles prevalent in apps today. This is primarily obvious with the wording in the iterate steps as it seems somewhat isolated from the full user base. With rich featured release control in apps today, you can easily track changes in design and deploy different designs to fractions of your full user base to get a much better and thorough understanding of the user preference and needs as well as full feedback from beta users.

I tend to slightly disagree with the plagiarize section of the design cycle. To just copy the design of an existing app seems wrong as every app falls into it's own niche area and requires its own particular design. Taking influence from other apps and melding several of these influences togehr seems to make more sense

All in all, this cycle in the K&R seems to be better formatted for enterprise level products that are more focused behind workflow and functionality rather than designed inspired development.


Brenton Dano - 1/24/2014 19:45:25

The Lewis and Reiman task-centered design cycle is similar to the three stage cycle we learned in lecture except it goes into more detail since it has 11 steps instead of 3. The first five steps of the L&R process could be lumped into the "Design" step of the three stage cycle. The L&R process seems to focus more on figuring out what the task is that needs to be accomplished and then accomplishing that task quickly. It even mentions that its a good idea to use past products that had good UIs as a framework that can be adjusted to current task. The 3 step model recommends to create scenarios of actual use while the reading mentions something similar which is the GOMS analysis. The 6th step of the L&R model of creating a prototype is similar to the prototyping phase of the 3 stage cycle, while the 7th step of testing the design with users is similar to the evaluate stage of the 3 step model. The main difference between the two models is that the L&R task centered process has a more rigid structure with the main goal being accomplishing the task whatever it may be. The 3 stage cycle in lecture is more flexible. With many iterations the 3 stage cycle can iterate quicker through the design cycle and can quickly adjust and add features or even new tasks that the product could benefit from on the fly.

The L&R model doesn't hold equally for today because it's a lot easier to update an app on the app store than update a brick and mortar device that is deployed to stores. Because of this, it was more important for the L&R design process to put a lot of weight into making sure the UI accomplishes all the necessary tasks that the product needs to accomplish. The thing that changes in the design process for these mobile apps is that due to the ease of deployment its okay for the app to change and adjust overtime. Also, because of the Comments section below apps in the app store the designers can get instant user feedback and rapidly change their product and push an update to satisfy the user. With the "shrink-wrapped" software that was sold to stores it might be more difficult to implement such rapid change back in the early 90s.

I don't disagree with Lewis and Reimann's idea for the task-centered design process. Perhaps its a bit outdated since it was invented 20 years ago, but they covered good ground for building good user interfaces. I guess if I had to choose one point that I slightly disagreed with it would be the part where they claim the iterations should stop once the usability objectives are met (bottom of 1.8). I argue that iterations should never stop, because new usability objectives can always arise and so if they do one would want to update the product. Going back to the 2nd question, this is why mobile apps today are so well done is that they can rapidly change and respond to user feedback. We've come a long ways since the 90s!


Tien Chang - 1/24/2014 19:57:16

The Lewis & Riemann design cycle is similar to the three stage cycle in that there is also a cycle of design, prototype, and evaluate. However, the Lewis & Riemann task-centered design cycle is separated into more detailed steps. The design stage in the three stage cycle described in lecture includes GOMS analysis and cognitive walkthrough. The prototype stage includes paper mock-ups or prototyping systems. The evaluate stage includes testing the design with users and analyzing their responses to a product. The cycle comes full circle with iterations.

Some arguments made about their design process would not be as applicable to modern day technology, as numerous applications today are "in the cloud." Therefore, there wouldn't be as much worry about hardware requirements. However, their points about iterations are extremely on par with current design processes today. With iterations, we can continuously improve.

Lewis & Riemann do have solid points - however, they focus on whether users will be willing to make extra effort in learning some new, as in going through a tutorial or using a help menu. They fail to mention that users may implicitly learn just by intuition (as in a game) or through trends (as in the hamburger menu and pulldown menu refresh as discussed in discussion). I also do not believe that "the cost of building a complete user interface and testing it with enough users to reveal all its major problems are unacceptably high," in fact, I believe that releasing a beta product to a selective group of users to test is a smart move. Multiple businesses nowadays test new features of a group of users rather than all users to catch errors in a smaller batch.


Aayush Dawra - 1/24/2014 20:10:28

The Lewis & Rieman design cycle closely aligns with the design, prototype, evaluate cycle discussed in class and comes across as a more detailed version of it. Apart from the 'plagiarize' step, which seems to be an important step considering it discourages redundancy, the first five steps roughly coincide with the design phase, the prototype step corresponds to the prototype phase and the last five steps correspond to the evaluate phase of the DPE cycle discussed in class.

With software design moving away from 'shrink-wrapped software' to software such as mobile phone applications, I think the emphasis on the evaluation phase is considerably more. In today's age, software very quickly reaches the evaluate phase which allows users to give feedback and in turn allows developers to incorporate that feedback in software, like the AGILE software development process. Getting to a working prototype earlier in the design cycle, without compromising task-centric design, is the norm with key features being added in the 'Change it' phase of the Lewis & Rieman design cycle. This is not to say that the L&R design process is completely out of date, just that the emphasis that earlier lay on the first five steps has moved to the last five steps.

I disagree with Lewis & Rieman in that the representative tasks that form the core of the design process should not be limited to the user sample, since it is very difficult to garner all representative tasks in this manner. User described tasks should certainly be incorporated but it is important to not let that become a barrier while prototyping since the user may sometimes not realize what they want, as was the case when the Apple iPhone was first announced and the concept of a touch screen smartphone was completely alien to the existing user base.


Christopher Schechter - 1/24/2014 20:40:11

The Lewis & Rieman design cycle is very similar to the design-prototype-evaluate cycle, but it also seems to place more emphasis on a few details left out of the design-prototype-evaluate cycle. Its focus on a few representative tasks, for example, is a focused approach that I like which the three stage cycle might lack, as well as the extra "plagiarize" and "rough out a design" steps. However, considering how similar the two cycles are, I'd be less inclined to say they're different cycles than to say that the Lewis & Rieman design cycle is just a specific interpretation of the three stage design cycle focusing on representative tasks. Where the L&R cycle does things in a certain 11-step process, the three stage design cycle does essentially the same things in a much more freeform style.

The Lewis & Rieman cycle certainly loses some relevance in regards to modern day apps. Whereas L&R suggests simply launching the product and watching how the users react to it, in today's reality many companies aren't even close to being done with their apps by launch time. There's a pervasive trend of the three-stage design cycle continuing on even after an app launches, like the many iterations of the Facebook mobile app we looked at in discussion. Besides this point, though, the basic ideas behind L&R's process of delivering to the user have hardly changed.

The only place I'd honestly disagree with Lewis & Riemann is on the above-stated point about continuing to improve the UI after releasing the product. I actually really like a lot of the methods they share, like using existing UI's as a starting point for designing their own. I especially like the line that states "a successful system has to merge smoothly into the user's existing world and work."


Calvin Woo - 1/24/2014 21:14:27

Lewis & Riemans' design cycle is fairly similar to the three stage cycle used in class in that there is designing, prototyping, and evaluation. However, the process in class emphasizes the cyclical nature of constant iteration whereas the readings are adapted for a corporate environment and talk about iteration in terms of usability objectives.

The shrink-wrapped nature of older programs limited the potential for constant iteration. Developers had very little control over versioning. Once a customer installed a program, it tended to stay at that particular version. Releasing iterations on the same product meant that only a small percentage of users would update their systems so the benefits to expanding on the same product were lower.

Nowadays, developers have a much more fine grain control over versioning. Mobile stores make updating apps a much easier process. That way a product can be released and unbiased user feedback can be iterated upon. Web applications can even enforce specific versions on different subsets of users so that new features can be tested by some portion of ordinary customers before being released to the public. So, these days iterating is much more profitable and getting user feedback easier than ever.


Jessika Wu - 1/24/2014 21:19:33

1.

The two cycles are quite similar in that they both specify designing, prototyping, and evaluation. The L&R cycle appears to be longer and have less full cycles than the three stage cycle. This is because there are more steps and each one is very detailed with a structured way of carrying it out. It appears that this more careful planning is intended to result in less repetitions of the entire cycle. One noticeable feature is the "representative tasks" that the L&R cycle focuses on and the three stage cycle does not.

2.

No, the design process should be different for the past and the present. When mobile applications are downloaded on a whim from an app store, users want features fast and they can give feedback fast. Furthermore, apps can be quickly and easily updated. The L&R design process is structured, detailed, and long. I think the cycle can be shortened in the case of certain mobile applications because real feedback can be given and incorporated in such a short amount of time.

3.

I disagree somewhat with the section about plagiarizing. While it is important to look at existing designs, and it is important that users are comfortable with the design, we shouldn't rely too heavily on sticking with traditional models. Society is growing a lot more tech-savvy, and a lot of people can easily adapt to innovative and unconventional designs. I think younger users especially would be more open to designs that are outside the box.


Jay Kong - 1/24/2014 21:19:53

The design cycle Lewis & Riemann discusses essentially boils down to the three stage cycle mentioned in class. First and foremost, designers must find out what users need and how to satisfy those needs. Task-centered design goes a step further by creating specific task lists the UI must take care of; it also utilizes “plagiarism”, where designers should consider building off previous designs. Next, with a good idea of the users and their use cases, designers should prototype a simple working model to test it with real users. Finally, in the evaluation step of task-centered design, designers should track how their users are using the product to discover opportunities for change, which then leads back to the start of the cycle.

As the design process in the article essentially boils down to the three stage cycled mentioned in lecture, their argument about the design process should hold equally for today with a few nuances. Software today is easily downloaded and updated (often automatically). However, back then, every update of a software must be printed and distributed. Today’s atmosphere allows for a lot more opportunities in creating minor revisions without incurring significant costs. Another nuance is that software today is more widely used than software back then, so it will be impossible to satisfy every user.

I agree with Lewis & Riemann, especially with their emphasis on interacting with real users. Often times, designers think they fully understand the needs of users without actually interacting with them. However, as Lewis and Riemann mentions, many problems will only arise after user testing. Therefore, it is extremely important to consider the needs and desires of your users.


Calvin Yau - 1/24/2014 21:21:11

The Lewis & Rieman design cycle is similar to the three stage cycle except it goes into more detail, taking the time to break the cycle up into specific phases. Each of the 11 steps in their cycle can be categorized into one of the three stages. For example, the stages "figuring out who's going to use the system to do what," "choose representative tasks for task-centered design," and "plagiarize" can be directly compared to "observe existing practices," "create scenarios of actual use," and "create models to gain insight into work processes" of the three-stage cycle. The time Lewis and Reiman spend describing the planning and initial testing process before anything concrete is built is essential to the process towards an effective user interface.

The Lewis & Riemann does differ from the three-step in that it does not cycle back through all of it's phases such as the three-stage does. Instead, Lewis & Rieman encapsulate the constant evaluation and improvement of the product in the last two phases: tracking the design and changing the design. Additionally, due to the fact that Lewis & Rieman break the whole process into numerous partitions, they are able to put more emphasis on the planning. Not until phase 6 of their 11 do they advise creating a prototype.

Their design process still holds for applications today but with the mass adoption of distributing through app stores, designers are allowed more opportunities to test with users as well as send out upgrades and fixes. The rating system for mobile applications has become an integral part of purchasing applications which gives important feedback and because many mobile applications can be downloaded for free, users have a bigger incentive to try out applications that they know are constantly being improved.

All that Lewis and Rieman describe is definitely useful towards the design process. However, in regards to "plagiarizing," it can be very important for some products but for some applications, I believe that it can actually be better to break from the general mold in order to introduce a new way of approaching the user experience. Devices such as the iPhone have undoubtedly set a standard that has been shown to be very successful but at the same time, its competitor, Android, has also gained much popularity with their unique design.


Quinn Z Shen - 1/24/2014 21:24:01

The process cycle described by Lewis & Rieman is rather similar to the three stage cycle described in lecture when looking at the big picture. The idea is to design something with the user in mind, build it or prototype it, determine if users enjoy the experience, and refine. However, the deviation in the design process described by Lewis and Rieman and modern design processes arise around the idea itself. Since the article was written during a time when software was "shrink-wrapped" into models of computers; it seems like most of the ideas are focused around the question "what would a user want to do on this system"? Whereas the creation of the app store pushes developers to instead focus and challenge what already exists on the system; the new question is "what else can this system do for the user"? The subtle difference shifts the focus even more to the user experience because often times the application are 'simplifying' an already existing process - if it was more difficult or even equal in difficulty users would simply remain using the existing process.


Sergio Macias - 1/24/2014 21:34:32

There are many similarities to be found within the process described by Lewis and Rieman’s design cycle and the three stage design cycle described in lecture. The first 5 parts to the Lewis and Rieman design process is the design itself. Just like cycle described in lecture, they go on to say that you need to move on to creating a prototype, test it out, then iterate through the process again and again, until a deliverable product is ready.

The argument about the design process still holds since this design process would work well for a myriad of products. First you must find out what the consumers need, create a sample design for the product, test the product, and then re-design based on the test results. Whether this practice is applied to software, mobile apps, or TV shows – the premise is still the same. My disagreement with the Lewis and Rieman design cycle is that users only come into the picture near the end, when in reality they should be part of the process from the very beginning. Not just about creating the idea, but seeing what problems these users have, what are there preferences, because if there is a common preference you can find within a niche community that you are targeting for your mobile app, then it would be great to incorporate that preference.


Emon Motamedi - 1/24/2014 21:36:08

The Lewis & Rieman design cycle is a similar yet more in-depth version of the three stage cycle described in lecture, with a few exceptions. The majority of the Lewis & Rieman steps can be placed into and occur in the same order as the design, prototype, evaluate steps of the three stage cycle. Figure out who's going to use the system to do what, choose representative tasks for task-centered design, and plagiarize can all be placed within the design phase of the three stage cycle. Rough out the design and create a mock-up or prototype would be placed in the prototype section of the three stage cycle. Finally, test the design with users and track the design represent the evaluate stage of the three stage cycle. The one outlier from the three stage cycle is the think about it step, as this would likely be placed in the evaluate stage of the three stage cycle rather than wedged within the prototype steps of the Lewis & Rieman design cycle.

Secondly, the Lewis & Rieman is meant to repeat to some degree in the same matter that the design, prototype, evaluate cycle is meant to continuously repeat throughout the generation of the product. While the three stage cycle continuously repeats the same exact stages, the Lewis & Rieman cycle represents this repetition through the iterate and change the design stages. Both of these steps leave room to repeat most of the steps of the process, and as such are in essence a repetition of the entire cycle.

While the majority of the argument about the design process holds equally for today, their are certain changes in the design process for the apps of today that are downloaded through app stores. The most notable examples of the changes come from the iterate and the change the design steps of the Lewis & Rieman cycle. The iterate step outlines a clear point when iterations should stop (when specific usability objectives are met). This made sense when management felt pressure to get the product on the shelves of stores and knew that iterations once this occurred would be tremendously expensive. However, in today's world, the iterations can continue indefinitely since users can just update their applications easily whenever a new version is released. These revisions are very inexpensive for the app designers and hence management does not have to worry about the high cost of future revisions or feel pressured to finish iterations at a certain point and get the product on the shelf. This creates the situation in today's world that allows iterations to continue indefinitely. Similarly, this reduces the prominence of the change the design step of the Lewis and Rieman cycle, as the design will consistently be changing and hence this step does not need to be a huge and consuming event.

While I agree with the majority of Lewis & Riemann's cycle, there are certain aspects I disagree with. Aside from the changes for the downloaded apps of today noted above, I firstly disagree with the notion that users and designers should constantly be in continued contact. While user research is crucial to good design, users oftentimes do not know what they want or what is best for them and hence constant contact can lead to the ideal product for a user being shot down by that same user and taken in a different direction because the user does not realize that that product is best for him or her. Secondly, I take issue with the plagiarize step. While looking at other interfaces can be useful, I believe it anchors the designer's vision to certain existing ideas and does not allow his or her creativity to fully flourish as it would if he or she were approaching it with a blank canvas. Perhaps first coming up with one's own idea and then looking at other interfaces could be useful. Finally, I do not think the interface should necessarily be built around all of the visuals and commands the user is used to. Like my previous objection, I feel this could prevent the designer from creating an even better interface for the user that may take some time to get used to but eventually is much more useful.


Meghana Seshadri - 1/24/2014 21:38:00

1) The Lewis & Riemann design cycle is very similar to the three stage cycle described in lecture, however, the three stage cycle seems to be more of a general encapsulation of the design process, while the Lewis & Riemann design cycle dives in deeper and presents more parts of the pipeline. The differences lie in the Lewis & Riemann design cycle where they emphasize on first figuring out the target audience or main user of the system. Then by understanding the user, the product can be more successfully merged into their world. Then, both design processes go into Task Analysis and focus on identifying the important tasks and functions that the product needs to accomplish. Both design processes also expand upon creating prototypes and having it tested with users, as well as revising prototypes in order to incorporate new user research data.

2) Lewis & Riemann’s argument about the design process still holds for today, even for mobile applications. It is still necessary to understand your target users and be able to define tasks that the application should accomplish. It is still important to build prototypes of the application and to rigorously test it with users so that the design can be updated to efficiently accomplish its goal. However, there are a few changes that should be incorporated into the design process for mobile applications. Mobile applications must work with a smaller interface rather than a regular desktop or laptop. Hence, UI designers might face the problem that there is limited amount of space to incorporate all the important tasks and functionalities. You don’t want to risk overcrowding the interface with too many functionalities that could easily fit onto a desktop, but not on a mobile phone.

3) Under the section “1.7: Test Design With Users” Lewis & Riemann mention that “The testing should be done with people whose background knowledge and expectations approximate those of the system's real users”. While it is true that it’s important to test with people whose background knowledge level to those of the system’s real users, I think it is also imperative go deeper into testing by observing people who are at extremes with the system. Meaning, either people who have strong reasons to either not want to use the system at all or people who heavily use the system.


Rico Ardisyah - 1/24/2014 21:38:55

Lewis & Rieman design cycle and the three stages cycle are two design cycle are totally different. Each of them has their own positive and negative aspect. As a matter of fact, Lewis & Rieman cycle has 11 stages to go. On the other hand, the cycle that is described in lecture only involve 3 stages.

Even though Lewis & Reiman has more stages to do compared to the cycle from lecture, Lewis & Reiman offers a thorough cycle. Hence, the interface that is resulted from this cycle will be less buggy. However, the process of building the interface will take long time since it has a lot of stages. Moreover, the iterate stage will take long time since every iteration will create new problems. In contrary, the cycle from lecture offers less time to build, it only involves 3 stages. Obviously, it is a simpler cycle. However, since the process is shorter, it is inevitable that the interface created by this cycle has more bug than the other method. As a matter of fact, today mobile applications are downloaded through app stores, the Lewis & Rieman cycle does not really hold equally for today because in Lewis & Rieman process requires long time to be built. When bugs are found in a application, users nowadays, demand a fast updated version of the application. Hence, it is not really effective to use Lewis & Rieman cycle.

Personally, since today most mobile applications are not sold “shrink-wrapped” anymore, I disagree with the slow pace of Lewis & Rieman. When a bug is found, this cycle will repeat all the 11 stages to update the application. While, the users wants to get the updated version fast.


Insuk Lee - 1/24/2014 21:38:55

The overall workflow of the Lewis & Rieman design cycle is similar to the three stage cycle described in lecture. The former takes more care and steps in the design step, however, which is reasonable since a extended brainstorm solid foundation is needed before we get to starting anything. I however disagree on the task-centered design itself. It will be less bug-prone and more coherent through the whole system to focus on object-oriented design instead of focusing on specific tasks that we expect the users will want to complete.

Also, these exact steps of the cycle described in the article is no longer relevant in today's software development cycles as releases need to be frequent and iterations are shorter, leading to the naming of agile development, and users are getting more impatient as ever. We can no longer sit back - we have to take charge to identify all problems, sort them into relevant and cost-economic partitions and change/modify the code in an already cleanly abstracted away source code. Perhaps this evolution of the design cycle led to the rapid growth of the role of "Product Managers" whose sole purposes are to identify what the users need, want, and complain about, and prioritize them for the developers so that there is constant development workflow that is parallel to their own.


Namkyu Chang - 1/24/2014 21:41:24

Lewis & Rieman’s design cycle is much more detailed compared to the 3-stage cycle in lecture. In the reading, we not only design, prototype and evaluate, but determine user base, choose representative tasks for task-centered design, plagiarize, rough out a design (same as the 3-stage cycle!), think, choose mock-up, etc. The cycle in the lecture includes components of the cycle in the reading. Even with the paradigm shift in the supply channel of apps when the article was written and now, most of the processes still seem applicable. However, one big process that diverges between then and now is the “Track the Design” part. Back then, according to Lewis & Rieman, “One way to put designers in contact with users is to rotate them into temporary duty on the customer hotline. Another important point of contact for large systems is user group meetings.” However, now since most apps are delivered on the app store, developers don’t need to stay on duty at the customer hotline. Rather, they could track the users’ usage, or if people opt out of this option, then ask for feedback in the app store comments. In addition, because apps can be updated almost instantly, the “change it” process can also be sped up from a few years to a few days. Depending on the app’s purpose, some of these processes seem very applicable. For example, if Google wants to create the Gmail app, it makes perfect sense to go through all these processes to ensure a perfectly working app catering towards millions of users. However, I think some of the processes are a little redundant for an independent app developer that wishes to create an app for a few thousand users. There is a lot of extra overhead that may not be necessary for such a small project in Lewis & Rieman’s design cycle, and it may be even better to skip a few processes and go on a trial-and-error basis, then rolling out any changes in subsequent updates.


Peng Xue - 1/24/2014 21:43:49

I think The Lewis & Rieman design cycle is a more detailed version of the three stage cycle. Steps 1,2,3,4 and 5 are mainly the design stage in the three stages design cycle, step 6 is the prototype stage, and the last two steps are the evaluation stage. Thus we can find out that The the Lewis & Rieman design cycle seems to focus more on the earlier development stages of the product. The later steps of the two cycles are nearly the same. Unlike the Lewis & Rieman design cycle, The three stage cycle described in lecture is straight froward and easier to follow.

Today, people download applications from app stores. Unlike the old days, now, if an application is changed, then users only needs to update the current applications. Thus applications now can be frequently changed to better meet the users need. While in the Lewis & Rieman design cycle, they seem to assume that applications are not changed frequently.

I disagree with Lewis & Riemann when they articulate that applications should be released only after going through the iterations. We can actually release application before the complete iteration is completed. Also, I think Lewis & Riemann design cycle emphasis too much on the first few steps. In today's world, it will cost the company too much money if the designers spend too much time on the initial stage.


Justin MacMillin - 1/24/2014 21:44:53

I believe the Lewis & Rieman design cycle follows the three stage cycle described in lecture, but with more detail. The first five sections of the chapter all have to do with the design aspect of a UI (figure out who's going to use the system to do what, use representative tasks for task-centered design, plagiarize, rough out the design, think about it). Section 6 (create a mock-up or prototype) is exactly the same as the second stage in the cycle. Finally sections 7 through 11 (test the design with users, iterate, build the design, track the design, change the design) all deal with evaluating how well the team did designing the UI and seeing where they can improve for their next product through their evaluation. Lewis & Rieman have great things to say about designing the UI initially and making sure what goes to production is dependable and something the team should be proud of. However we have the luxury of releasing updates when bugs are found. While it isn't ideal for users to find bugs, it is the most efficient way to find bugs because of the sheer amount of people testing the UI will be larger than the QA team. I think the design process then should change to include a phase of fixing after evaluation. First you must evaluate how your users respond to the product, then fixing the bugs is a necessary part to making a great product. At a certain point however, if bugs continue to persist, then a whole new product might be the way to go (or redoing a major portion of the code). I disagree with Lewis & Rieman when they said in section 8 that iterations should stop when usability objectives have been met. I think that it makes sense to stop at this point, on condition that bugs in the product have been completely fixed. It depends on the situation and I think Lewis & Rieman could have expanded a bit more on this situation, giving more thought to the point that there still could be bugs even if you have met the goals of usability.


Melissa Pangilinan - 1/24/2014 21:50:10

To be absolutely honest, I thought the Lewis & Rieman design cycle was pretty similar to the three stage cycle we discussed in lecture. L&R definitely consult the users and put the representative task at the focus of the project along with how users will interact. After throwing a design together and prototyping, L&R test it with users, or “evaluate” as we’ve learned in lecture, and build the design. I noticed a few subtleties such as iterating or improving the design before building it and changing the design (without prototyping) as needed. While the philosophies behind L&R are similar to the three stage cycle, I think the way L&R carry out subsequent changes after their first prototype differs from the more circular process we learned in class.

After learning this article was written int eh “shrink-wrapped software era”, I can see why they did not follow a more circular cycle as we’ve learned in class. Implementing several changes or making new updates readily available for the market was much harder, so I feel it would have been more difficult to constantly ship new prototypes and products without the ease of downloading from the cloud. There is much less redundancy in the design process of L&R, and I think that’s attributed to how easily (or difficult) it was for users to participate in several usability tests of the same software.

While I think it’s great that L&R spend a good deal of time figuring out what the product is going to do, designing the product, and conducting usability tests, I think they don’t allocate their design process as evenly. I think it might be more beneficial to perhaps cut back on the initial time invested in the first stage of research in order to add more stages of research & development between iteration. Personally, what I like about design-prototype-evaluate is having several cycles. That way if one bug falls through the first round of testing, it’s likely to be found in the next round or so. However, with L&R’s method, it seems that small details are likely to fall through the cracks because they don’t spend as much time testing between iterations and building.


Meiqi Yang - 1/24/2014 21:55:41

1. The three stage is a summery of first 8 steps of the Lewis & Rieman design cycle. Designing is the 1st to 5th steps in L&R design cycle, prototyping is the 6th step, and evaluation is the 7th step. And we noticed that there is a circle in the three stage model, the circle is a vivid presentation of the 8th step of L&R design cycle – iterating. The L&R design cycle is more detailed, it is easy to follow the steps to complete the whole designing process, but sometimes it is a little too fixed, not flexible enough. It is not necessary that every application should follow the same process. The three stage design model is more general but you have to know clearly what you should do in every step.

2. I think there are two differences I’d like to point out. First, the L&R design cycle needs quite a long time to produce one application. But nowadays the time limit of creating a new applications is much shorter. When you developed an application using six month, the need of users may have changed dramatically. We may have to simplify several steps to make us more productive. Second, the cost of the traditional design process is too high. In the old days when people bought the applications from stores, the profit was huge. But now many of the applications can be downloaded free or sells very cheap. The capital restriction is also a big problem that we cannot waste that much time and labor on a single application.

3. The steps are too detailed and lack of flexibility. Sometimes we don’t need to finish all the steps for one particular application. Additionally, a paper description of the design or a simple mock-up may not be able to illustrate the real function of the software. The feeling of looking at a piece of paper would be very different from using the real software.


Liliana Chavez - 1/24/2014 22:08:09

The design cycle described in lecture is a good way of describing the basic principles of design in a quick memorable manner. Lewis & Reiman's cycle of 11 steps takes it a step further by actually describing in greater detail what you have to do throughout the entire cycle. Each step in Lewis & Reiman's cycle can map out to the design, prototype, or evaluate step in the class lecture cycle.

I believe that the reason this cycle is so fleshed out and detailed is due to the finality of the final product (shrink-wrapped hard copy in stores). Nowadays, a simple software update is available to most users now at the instant it is available, so while there is equivalent overall concern for design (between then and now) there is less of a cost if the cycle is repeated more often and is shorter (although of the Lewis and Reiman's steps are still executed within the 3 stage design cycle).

Personally, I don't think that in this time where software can be readily downloaded from the internet it is necessary to flesh out so many of the details of the cycle. I agree that each step in Lewis and Riemann are very important points to the design, but in terms of remembering the design concepts while actually designing, it becomes tricky to recall all 11 steps all of the time (and they're not all integral to the success of the application). Some steps seem to simply be important points to remember when the design isn't being well-received by the users (i.e. like the plagiarize step), and should therefore be in a separate list of reminders for the design cycle.


Nitya Anthony - 1/24/2014 22:13:47

The Lewis & Rieman(L&R) design cycle is similar to the three stage cycle described in the lecture. The L&R design cycle elaborates on the three stage cycle such that each stage is further broken down into specific steps that can be undertaken. For instance, the idea of iterating by using user feedback to modify the design fits into the evaluation stage of the three stage cycle.

Unlike the three stage cycle, the L&R cycle gives much more detail about the design part of the three stage cycle. For instance, I found the idea of "plagiarizing" in the L&R design cycle, getting ideas from interfaces that customers are already familiar with, particularly interesting. In contrast, the three stage cycle does not provide you with specific ways or means to design the product.

L&R's argument still holds today in terms of the way in which the overall design process for the application works in terms of designing the product especially before releasing it into the market. With today's mobile applications, designers can gather feedback from customers as well as perform testing on customers more efficiently and effectively. Hence, I believe that there is therefore a greater emphasis on the "Change the Design" portion of the design process. As a customer uses the product, immediate feedback can be acquired from them and designers can work on changes/upgrades. Moreover, any changes to the mobile application is easily accessible to the customer via application update downloads unlike before. This makes the customer more open to more frequent iterative improvement of the product.

I believe that the L&R design cycle is slightly rigid in the sense that it states the step by step process through which the product needs to be designed. Today's fast paced environment might necessitate a more agile development/process of design. Moreover, the L&R design cycle's task centered approach might mean that other aspects of the design such as the overall user experience might be neglected due to the heavy emphasis on specific tasks.


Cheng-yu Hong - 1/24/2014 22:18:00

The Lewis & Rieman design cycle separates the three stage cycle (design, prototype, evaluate) into 11 more detailed stages. The design stage is split into figure out who and what, choose representative tasks, plagiarize, rough out design, and think about it. The prototype stage stays the same. The evaluate stage is split into test with users, iterate, build it, track it, and change it.

Most of Lewis & Rieman's arguments about the design process hold equally for "shrink-wrapped" software and mobile applications. The prototype and evaluate processes stay relatively the same. However, several steps in the design stage can be cut out and mobile app developers can put their applications in online app stores and gain user feedback earlier in the process, since it costs less than putting packaged software in stores. The part where Lewis & Rieman notes that "the costs of building a complete user interface and testing it with enough users to reveal all its major problems are unacceptably high" is a bit outdated for the mobile application era, when any developer can just develop an app on their personal laptop and upload it into a huge database such as the Google App Store. I do agree that it is more efficient to choose representative tasks and only target features that improve the user experience of those tasks, but I do not think that this is the only approach. In modern times, you can also have shorter feature cycles and have user feedback guide the application development.


Bryan Sieber - 1/24/2014 22:22:26

In class we discussed the three stage cycle (design, prototype, evaluate), each stage in the cycle correlated with different tasks that would need to be accomplished. In the design stage designers observe the current practices to gain insight into the processes; in the prototyping stage designers build different level mock-ups starting with paper and eventually getting up to an interactive program; and, in evaluate designers test the prototypes with actual users. The design cycle of Lewis & Rieman is very similar to that of the three stage cycle. Designers following the Lewis & Rieman cycle require “an awareness of the users' background knowledge [to help] answer questions such as what names to use for menu items, what to include in training packages and help files, and even what features the system should provide” (1.1). In the Lewis & Rieman cycle, sticking and maintaining with the old way of things is important, even if the new way would say make more sense or reduce the overall number of keystrokes. Both the design cycle we went over in lecture and the Lewis & Rieman cycle say to start prototyping with a low budget of solely paper to uncover issues with the design. Lewis & Rieman state that programming shouldn't even be started (unless you use a UIMS) until you’ve hit enough of the tasks that you set out to accomplish. When programming has been started for the product, the code must be “built for change” (1.9). Code must also be modularized, clean, and without any hardcoded numbers. The ability to quickly change code to fix an issue or make a change in the overall design is extremely important. One of the points of disagreement I have with the Lewis & Rieman design process is the following: “You should look at the controls for spelling checkers in the word processing packages used by people who will use your system. That's almost certainly how the controls for your spelling checker interface should work as well” (1.3). I feel like this statement is truer when the product you are designing is supposed to be a product that in meant to be used by individuals professionally. Looking at other highly used applications and looking at their control schemes would be more beneficial to also help draw other users possibly interested. Even though this design cycle by Lewis & Rieman was written at a different time, this design process still holds to the current day application markets. Nowadays, time is of the essence. Sometimes individuals release a programmed application earlier than they should, depending on the issues this could either cost the creator credibility and user base or get the creator a beta user base that could provide feedback about the applications workings. For applications that have beta releases, this creates a unique design process. The beginning of the process should be the same, but the prototype released for the beta testers would need to be an almost fully functional programmed application. Based on the feedback from the beta users the applications would either move forward in the design process or go back and see where to fix the majority of the errors before advancing.


Chirag Mahapatra - 1/24/2014 22:24:35

At its essence, the the Lewis & Rieman cycle is similar to the three stage cycle described in the lecture, albeit a longer process. The differences lie in the different types of prototypes. Lewis and Rieman first suggest a paper design, then a slightly advanced mockup which is iterated and finally build the product. This makes sense because in 1993-1994 the number of software mock up tools were very few in number. This process commits as little time and effort to the actual product building till the design is finalised. This is because product building took a lot of effort, time and money and it was hard to revert changes. In today's world it is much easier to prototype and build which much less time and effort. Hence the cycles are much shorter.

Yes, their argument does hold for today's world. They are advocating a task based design process which is important today. When building a product only those features should be included which perform some intended task for the user.

I disagree with the last paragraph in the 'Plagiarize' section where the author is recommending the designer to stick with what the user knows ans is used to rather than changing the process to something simpler. This is because companies like Apple, Ideo have made existing products obsolete by making it simpler and more intuitive and a designer must always strive for the same.


Robert Hernandez - 1/24/2014 22:25:38

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

Lewis & Rieman, in contrast to the three-stage cycle described in lecture, had a stronger emphasis on task-driven design and evaluating the result with the use of testing it with users. If I would break down there style, it would be the following: Pick your audience, see what works for that audience already, document what you plan to build, do estimates on the project to see if it is feasible to carry on, prototype, test with users, repeat until, design official built, check progress of design, upgrade. In an abstract point of view, it does carry out the principles of design the prototype, make the prototype, and evaluated. However, it has more of an “Agile” approach, a term described to me in CS169 that works close with the consumer to improve the design, but here the consumer being the users that test it until all the original goals are achieved. I like Lewis & Rieman’s design cycle because of this fact and was really easy to understand. It is important to note that three stage cycle is similar to the first 9 steps of L&R, but L&R branches that it finally picks one, and then monitors the success or failure of this prototype for sometime, and accepts the fact that change happens again and restarts.

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 today, when most mobile applications are downloaded through app stores?

I feel like it still holds true for the most part insofar as the mobile industry already has a lot of duplicate applications such as in games and seem to carry the same problems as it did before. With better testing with users, more creative design but also have familiarity with what users already can do, it can lead to a successful application.

What changes in the design process for these apps? Well for one step 1.4-1.6 can be fused insofar as there are already software that allows you to make prototypes online much easier, so you can make a mock prototype, rough out the design a bit, and then consider how long it would take in that order but would be separate stages but one cumulative stage. You still need to test and repeat, so all the other steps in my opinion would remain the same.

Where do you disagree with Lewis & Riemann & Why?

For the most part I agreed with Lewis & Riemann as they had, in my opinion, an Agile approach, or consumer-first mentality. However, I would improve on the fact that on step 1.4, they said that you should not include task if they are not part of the representative tasks it supports, but it does mention the list of task should be upgraded if such task is needed. In my opinion, these extra features could be always the game-changing ideas that sell or market your app, as well as make life easier. The way to stay on track but not lose creative ideas however is to challenge the idea creator how would that new feature bring to the table some brand new functionality that wasn’t there before. If it is something that users are used to such as swiping, then ask how much more different would it be for just clicking a button instead. Make the creative person’s passion be the advocate for adding a new feature, not a consensus list.


Aman Sufi - 1/24/2014 22:31:22

The Lewis & Riemann design cycle closely resembles the three stage cycle described in lecture with a lot of details pertaining the design stage of the cycle – Steps 1 through 5 are basically all spent on creating a thoughtful design geared towards users, while just about one or two steps each are dedicated to the prototype and evaluate stage. From Step 8 onwards, the Lewis Riemann cycle encourages a return to the previous steps at a smaller degree based on additions and modifications to design based on user feedback and premeditated evolution of the software in its intended direction. Usability tests and putting the designers in the shoes of the customers are both key points in the development of good design according to the design philosophy of both cycles. However, the main difference I would say between the two cycles is that while Lewis and Riemann’s approach emphasizes building up a presentable design based on tasks acquired from customers before prototyping them, the three stage cycle described in lecture is decidedly more flexible, allowing for a simpler, and even incomplete, design to be approached and worked with and then prototyped and evaluated before being developed on further. In addition, it is flexible enough to accommodate the fact that the user of the app often doesn’t know what he wants until it is presented to him or becomes a pain to him through a bad user interface. Therefore, by starting with a simpler prototype, design can be naturally progressed according to newly discovered user insights.

In regards to today’s situation of easily accessible applications all competing with each other in the marketplace, much has changed in the sales of software. Now it is much easier to compare different applications easily by seeing side by side the reviews and ratings left by other users as well as screenshots and other supplementary media. In addition, most app stores now allow app returns within a limited timeframe, allowing for users to test drive applications and return them if they seem unpleasant, as opposed to the old policy of software being unreturnable once opened. All these changes mean that some of Lewis & Riemann’s assumptions such as plagiarizing other designs and the testing process must be modified a little. For example, while few people would notice plagiarized designs or care much in the past as they were often only exposed to a single or few apps that served their purpose, today with the availability of many apps that often do the same thing, no one wants to use an app that is a clone of something else, just as no one wants to use a Chinese pirated iFone rather than an iPhone. While there are design trends that the whole industry tends to follow which should be followed and are important for keeping your app up to date with, users tend to see no need to change applications when they already have something that looks and works similarly and would often be hesitant to just install the new app unless they can see some noticeable changes. You have to stand out from your competitors and have a key design insight which they don’t have to gain some of their market share. And regarding the testing process, what the cycle fails to mention is the simple fact of whether or not a user would recommend the app to a friend, are they that genuinely happy with it? In the past, people would often buy software based on the recommendation of a sales clerk and they were often expensive purchases, so even if friends provided recommendations to each other, it wouldn’t have had the same large impact as in today’s markets with cheaper yet much more numerous downloads of software, where the most successful ones are the ones where users can get their friends to go on to their phones and easily download the latest and best apps. And the last thing I would like to mention is that as platforms are becoming more and more iconic and adopting their own preferred work flows, it is important for applications to be tailored individually to each platform for the best effect. Applications should also integrate well into the existing ecosystem of user and system apps on each platform to allow an easy and accessible flow to and from the application within the platform.

In general, the main things I disagree with Lewis and Riemann is that while I think that tasks are a good way to continue adding features to an app based on user behavior and requests, it is easy to get carried away and focus on too many tasks than the user can handle. The best strategy in my opinion is to focus on lightweight initial applications that only focus on one or two key ‘painful’ tasks and simplify them to gain a strong user base before gradually beginning to add in new tasks/features based on user requests and insights. But other than that, most of what they said back two decades ago still holds as a good foundation for current and modern design strategies.


Dong Han - 1/24/2014 22:35:52

It's similar in that they both talk about the same topic. However, the design cycle which is described in Lewis & Riedman is more detailed. To explain, the first five sections could go in as design. It's highly focused on satisfying the end user's needs.

I still feel that this argument about the design process still holds today. Even though mobile applications are downloaded through app stores, the end users didn't change. The only thing that changed was that there are middle man now called apple stores or google play stores. So in order to get published, they have to get through apple stores or google play stores, even though apple store is more strict. The only thing is that since so many users are out there downloading applications, developers can publish the application and cut out the later parts described in the Lewis & Rieman(1.8-1.11). For instance, they could publish the application and test it with end users with beta version. It has become much easier for developers to publish the application, but the core concept, in my opinion, hasn't changed.

I disagree with plagirizing although I do understand what they are saying. However, when you look at other designs over and over, your design will not be unique. I feel that that shouldn't be always utilized in designing an application.


Steven Wu - 1/24/2014 22:38:00

The Lewis and Rieman task-centered design cycle is very similar to the three-stage design cycle, but with a few extra steps. In the reading by L&R, you find what the users deem important even though the feature may not be crucial to the system's main functionality. In the three-stage process, you observe existing practices from users. There are other shared commonalities between the two design cycles in that there are low fidelity techniques like paper sketches to interactive simulations (that don't incorporate programming yet), so that the designer isn't too focused on making too many decisions early on in the process. And finally they both incorporate testing with a sample size of the target users and release a feasible low-cost model, and then iterate as needed. While most of the process is the same, L&R adds one more process, plagiarism, which was not mentioned in lecture. Plagiarism allows the designer to benchmark a product off of something that the users are already familiar with. A key point about plagiarism in design is that an existing product will be easier to implement because the decision made for that design decisions have already been made for that product. Without properly considering plagiarism, there is a possibility that a new implementation will have a high failure rate. Another concept that task-centered design incorporates is that the tasks are gathered from a few words, but built upon to any level of detail a designer sees fit, and this allows for several interpretations. While this all may be the case, again the designer must present an effective set of tasks that will reflect their understanding of the users and what they will use the product for. L&R discuss the importance of simple tasks and complex tasks that will better represent the real would interactions that would be faced by the target users. Task representation is highly valued as there is there are only so many features that can be presented in a prototype of a product. Features that don’t fully encompass the tasks user have should be discard to accommodate something of a higher necessity. And since this is task-centered design, the represented tasks should act as a checklist to make sure a system is complete.


Lewis & Rieman's argument still holds today since previous software products were updated annually. Each product release had to be as polished as ever. Today there are products that can ship out as quickly as design and development has completed. Instead of relying on the in-person interaction with users and having a designer take the role of customer support as stated in the reading, today’s companies rely on analytics to provide user findings and problems. But of course, user researchers and user designers still exist. Lewis & Rieman's approach allows for designers to minimize the cost of construction of a product by using analytics that companies use today. L&R referred to this similarly as GOMS analysis. Both in the past and in the present, there is an importance of noting particular activities that a user does. For example the average time a user spends on a certain part of a web page to the where a mouse clicks all ultimately influence the decisions for today's designers.


When asked if I disagreed with this tasked-centered design process, I cannot find much to argue against with since the majority of the finished product will have to meet the needs of the target user. By building an entire design process that puts the users’ tasks in the forefront, finding representative features that reflect a user’s needs should be a focal point to today’s design process. The task-centered design process incorporates the three-stage process but includes additional steps to ensure user satisfaction. Plagiarism is valuable since it will remain familiar with the user. Representative tasks should also be assessed since it this should reflect the designer’s open interpretation to the target users’ needs.


Juan Pablo Hurtado - 1/24/2014 22:38:41

1. The Lewis & Riemann task oriented design cycle has a lot of similarities with the three stage design cycle. You could say that the first stage, "design stage", would be equivalent to:

   - figure out who's going to use the system to do what
   - choose representative tasks for task-centered design
   - plagiarize
   - rough out a design

the "prototype stage" would be:

    - think about it
    - create a mock-up or prototype

and the "evaluate stage" would be:

    - test it with users
    - iterate
    - build it
    - track it
    - change it

but the three stage cycle feels more flexible and dynamic, because you don't just build the design, but you keep building it and redesigning it the whole time given your users feedback.

2. Part of it still hold true today, but because of the app stores and the "almost always" online nature of these apps, now the feedback is faster and more sincere (because of the reviewing of the apps in their stores and the anonymity of the users) and also because of that fast feedback, the developers have the ability to be evaluating and redesigning the app constantly.

3. In the context of the design focused to mobile apps where the iterations are shorter and you receive constan feedback from your users I disagree with L&R in the iteration stage, they say that when all the usability objectives are met you should stop, but given that the users don't know what they really want until they notice what bothers them, you have to keep iterating and incorporating the feedback of the users for all the app life cycle.


Maxwell Rutman - 1/24/2014 22:52:08

The process is similar in the way that the cycle approaches the process of creation. Each cycle though, however is different in the way that the steps are laid out. The process in lecture goes through 4 phases that include a variable number of sub-phases depending on the project at hand. The most interesting comment by L&R is the comment they make about plagiarism and to observe other forms of design. Lecture material makes little mention of that. Both forms also operate on a cyclic basis to prove the underlying theme of the process is that the process has no end. To design effectively you need to observe and seek to improve every next stage and model. Absolutely, I feel as though their process fully applies. Some of the comments are a bit dated and things in the article would need to be tweaked, but I fully feel as though the cyclic process with the certain phases relating to prototypes, tracking, and follow-up are absolutely crucial. I would disagree with the article in the sense that the press lots of testing phases before building. The authors wrote the piece in a time when things were more 3-D and lots of time had to be invested before creation. We live in a time now with software when we can make quick and dirty models and run through ideas and adapt at a much faster rate.


Saerom Park - 1/24/2014 23:02:15

The Lewis & Rieman design cycle was in a larger scope quite similar to the three stage cycle (design, prototype, evaluate) discussed in class. It seemed as though the design cycle outlined in the reading was a more comprehensive breakdown of the three stage cycle. For instance, the middle stages: create a mock-up or prototype, test it with users, iterate, and build it steps seemed like a more specific breakdown of the prototyping stage discussed in lecture. I still feel as though Lewis & Rieman’s arguments about design hold very true today, despite us being in a much different age of technology compared to when it was written. In fact, while doing the reading, I wasn’t even aware that the article may have been dated, as I mentally applied these concepts to the android project we will be working to produce through the course of the semester. There are specific areas that could be updated however, by accounting for the new ways developers and users can interact by nature of now being able to download apps through app stores, instead of having to buy them “shrink-wrapped” in stores. One change in the design process for today’s apps available in the app store would be that they no longer need to be tested as rigorously, as developers are now able to ship out updates directly through the internet into the consumer’s hands. That’s not to say we want to diminish the final quality of the products, but developers can be more flexible in gauging the consumer’s responses and ship out more tailored updates to the app. Another notable change is that the “plagiarism” section in Lewis & Rieman’s article can be emphasized less, since it is now much easier to standardize the interface of apps. For example, on the side of android development we saw the introduction of themes such as the Holo UI to enhance the users’ experiences with the product through functional familiarity.


Luke Song - 1/24/2014 23:03:41

The author seems to have described two iterations of the three stage cycle; two design stages (rough out the design, build the design), two prototype stages (create a mock-up or prototype, track the design), and two evaluation stages (test the design with users, change the design). The first iteration and the second iteration are roughly divided by the date of the first release; three stages for the prototype and three stages for the final product. The design process described here still hold today; I'd argue that it's now easier to get feedback from users because of the ease of sending feedback through web sites or the application tracking its own usage.

The section on plagiarism reminded me of the introduction of New Coke in 1985; one theme of the section seems to be "if it ain't broke, don't fix it." The massive UI overhaul that Windows 8 introduced is also comparable, and brings up the idea that while some new design ideas may be better than older ones, humans are finicky such that they prefer designs that they're used to, so much so that people actually protested in 1985 to bring back the old Coca-Cola formula.

I definitely like section 1.9 Build the Design: "minor changes with easily changed variables." One example of this is mod support for many PC games; such as replacing new textures for generated models. It can also be as simple as allowing the user to have a wide variety of choices in the options menu; anything from key bindings to adjusting the screen resolution and frame rate.


Stephanie Ku - 1/24/2014 23:13:33

1) Firstly, both cycles discuss the importance of observing existing practices, and in L&R’s terms “plagiarize”. In L&R’s version, they go a step further to adapt what already exists and examine why certain paradigms are more effective. While the cycle in the lecture only discusses creating scenarios and models of usage, L&R’s design cycle has a much more distinct and rigorous approach to plan out the tasks the application will have. For example, L&R’s utilizes task-centered design which involves breaking things down into tasks, where features support each task.

Similarly, both design cycles discuss rapid prototyping. Both stress the important of “roughing out the design” on paper before even touching the keyboard to code. L&R’s sketch-think-prototype has that extra ‘’Think About It’ in between that suggests analyzing through potential statistical methods before creating a prototype or mockup. On the other hand, the three-stage cycle’s Prototype stage incorporates both low fidelity techniques (such as sketching) with interactive tools and UI builders.

In the three-stage cycle, it asks you to evaluate analytically without any users as well as test with real target users whereas the L&R cycle is more user-focused and wants you to run through your design with users before you build anything. Thus, L&R has more user feedback along its process.

In conclusion, both cycles have similar structures in terms of overall themes. Where they differ are in the details. L&R has a more rigorous and detailed approach to the design cycle, whereas the three-stage cycle encapsulates many of the shared ideas but leaves the choice of action up to the implementer. L&R’s cycle also stress more ‘thinking’ and constantly iterating on each process while consulting with users.

2) I believe that in general, most of their arguments about the design process still holds equally for today. It is important that throughout their process, they constantly refer to the users; gaining feedback continuously to make sure each sketch/prototype is adequate and fulfills consumer needs before even building anything. However, today when mobile applications are downloaded through app stores, a great portion of the user feedback doesn’t necessarily need to be collected before you build anything. For example, if we follow Agile methodologies, you consistently build iterate and push the latest updates and features directly to the user.

As a result, the design process for these apps could change. The process becomes more of a cycle (similar to that of the three-stage cycle). We do not necessarily need to test the design and iterate on these designs before building and tracking them. We can simply build first, and we iterate on these builds by assessing user feedback to each build that we have pushed as an update of the mobile app. Additionally, Step 1.2 “Choose Representative Tasks for Task-Centered Design” could also be changed. As we are building and iterating consistently, it may be easier for developers to design with features in mind such that it is easier to track. However, I believe this is an optional process change.

3) There are a few points that I do disagree with Lewis & Riemann. Firstly, I believe that sometimes ‘plagiarizing’ new designs is not the most innovative way to implement designs. While there are some standard cases (such as where buttons/menus should be placed on Android devices), innovation and new ideas stem from thinking outside the box. Take for example, Flipboard’s way of ‘flipping’ through each story is not a copy of any other applications, and has become popular for this unique user experience.

Additionally, I feel as though the Lewis & Riemann process could act more as a cycle rather than a ‘process’. After we build the design, we should track and continuously iterate. While it is good to iterate on potential designs with users prior to building it, if we consistently do this it may be time consuming and wasteful of resources. Depending on the magnitude of the change, some prototypes or sketches may not need to be consulted with the user before we build it.


Diana Lu - 1/24/2014 23:28:24

The Lewis & Rieman design cycle is actually quite similar to the three stage cycle described in lecture. Without having known that the article was written at a point in time where software was sold "shrink-wrapped" in stores, it could easily be believed that the same design process holds today. In many ways, while the stages seem to be staggered in the Lewis & Rieman process, they equate to the design, prototype, and evaluate cycle utilized currently. A large emphasis is placed upon getting user feedback as a primary part of the cycle in both processes, which is key.

Just like the process described in the article, the current process utilized for making mobile applications is largely the same, iterative in nature and dependent on the feedback of the user to determine the content of the next iteration. Just like the task-centered design process, there is care taken to ensure that the way the user interacts with the application in a way where existing paradigms are emphasized, but with mobile applications there is also room for novelty and innovation.

The only place I would perhaps disagree with Lewis & Rieman is in the sense that it is always better to use existing paradigms if there are there as opposed to trying newer things. While it is true that familiarity is key, I think that there is room in the newer, under-explored market for mobile application development for innovative ideas for different interactions with the end user.


Kiki Liu - 1/24/2014 23:32:55

1. Lewis & Rieman design cycle also includes the iteration of design (user analysis, representative tasks design), prototype and evaluate. Notice that it also requires the designers to evaluate (discover stengths and weakness) even at the design stage. What's more, it brings design building, design tracking into the picture and emphasizes the importance of involving designers "in the rest of the system development effort".

2. The design process, in my opinion, has changed as most mobile apps are downloaded directly from app store. You don't necessarily get every design detail done before release. The design iterations are gradually conducted via easy updates from app stores. One reason is timing. Another is that user log data and "organic" user (not paid by using the products) feedback could help designers improves their apps.

3. I cannot fully agree with the "Plagiarize" part. Leveraging existing interface design could save development time. However, unnatural design should be disgarded by more intuitive design even if users have been used to it. If iPhone sticked to the qwert keyboards, it wouldn't have initiated the revolution of touch screen.


Yan Zhao - 1/24/2014 23:36:21

The Lewis & Rieman design cycle and the three stage cycle both emphasize on behavior driven development. The L&R design starts with a length phase on user behavior analysis by specifying "tasks". As for the three stage cycle, this is achieve in the design and evaluate stages. However, the L&R design cycle has more steps and longer than the three stage cycles, this may cause the design period being longer.

No, the L&R design cycle does not hold equally for today. One main reason is, with today's software distribution process, the software/app release is much more frequent, especially with the rising of SaaS and app store distribution. Design process today is usually more quicker and efficient, which means one design iteration is much shorter, due to the easiness to fast prototyping and release, as well as continuous integration.

One thing I disagree most with L&R is the length of the design process. As for today's software development trend, the release and development of a product is much quicker. Usually, the "Test the Design With Users" phase is merged into the "Track the Design" phase. At one sentence, L&R is not AGILE enough.


Dennis Zhao - 1/24/2014 23:36:52

Lewis & Rieman's design cycle is similar to the three stage cycle described in lecture in the sense that those three steps are still retained. The difference between the two is in how decisions related to how to move forward are made. Lewis & Rieman's approach focuses on the tasks you'll want your users to be able to perform, while the approach described in lecture is more of a general design, prototype, and evaluate cycle. Lewis & Rieman's process feels like just a more concentrated version of the process described in class that applies more directly to software. 

Yes, I think generally the procedure outlined in the article is still applies to applications that are downloaded through app stores. A difference is that many companies can now easily hold large-scale 'alpha' or 'beta' phases for their apps, allowing them to receive feedback without having to go through many of the processes that companies from a long time ago had to go through in order to get feedback. Iterating and making changes to the existing apps that are out in the world also becomes much easier, as all of that is handled through the app store and through a virtual marketplace that's more accessible to developers and customers alike.

I disagree with Lewis & Rieman on how they believe features that don’t support any of the representative tasks that are thought up in step 1.2 should be discarded. I think it’s always best to keep an open mind about how any sort of product will be expanded in the future, and to completely cut off ideas at such an early stage in the design cycle could present problems later on when these features become important.


ByungSoo Ko - 1/24/2014 23:37:55

Compare to the three stage cycle described in lecture, the Lewis & Rieman design cycle is very similar to it with their similar structures and function.

I think their argument about the design process holds equally for today, although most mobile applications are downloaded through app stores. The change is that iteration occurs more frequently as there are more frequent changes and updates on mobile applications than those on software programs on computer.

I mostly agree with Lewis & Riemann; however, for 1.11 I sometimes saw some applications that used to have better service than updated ones. I think for some applications there is no need of changes to the newer skills and expectations of users.


Sirui Xiao - 1/24/2014 23:48:28

Whereas Lewis and Riemann emphasize task-centered design, the goal in today's day and age is focused on user-centered design. In terms of the design cycle however, Lewis & Riemann has a similar structure as the three stages introduced in lecture: design, prototype, and evaluate. Although the line out a series of steps, in general they can be summarized and condensed into those three stages. The major difference, however is choosing whether to design for the user or the task. User-centered focuses on understanding the user's needs and goals, while task-centered focuses on behavior: not why but how.

I agree with the general process of Lewis & Riemann's design cycle, but I too think that UI today should be more user focused, (on the why component). Back then, there was not as much selection to choose from, but with the emergence of mobile applications, the selections are endless, and designed for specific targets and segments of people. Instead of trying to understand the tasks each user may perform, then, it may be more effective now to understand what the central users for a specific application/software are familiar with, and how they generally tend to think and interact with the computer. Therefore, to design good interfaces, it is most important to understand the people you're designing for.


Zhengda Zhao - 1/24/2014 23:52:43

Q1
  • Design
L&R: Task-centered design process. Find out representative tasks first.
Lecture: Observe existing practices;Create scenarios of actual use;Create models to gain insight 

into work processes

  • Prototype
L&R:The entire design doesn't need to be implemented at this stage. Paper mock-up and UIMS will be sufficient.
Lecture: Rapid Prototyping; Build a mock-up of design or more. The prototype can be built to be interactive. 
  • Evaluate
L&R:Test the design with users and do lots of iterations.
Lecture: Evaluate analytically (no users); Test with real target users
Q2

I believe their argument about the design process still works but not efficient for today as mobile apps could be changed at anytime and they are super easy to change. The design process should be continued along with the life cycle of the mobile app. Whenever a new user problem occurs, the mobile app can be updated to solve that problem.

Q3

I think before roughing out the design we should conduct lots of potential user interviews to validate the need for a new design.


Paulina Ramos - 1/24/2014 23:59:09

Lewis and Reiman's design cycle is very similar to the one presented in lecture. In short, although the article states more steps in their process than the three main ones discussed in lecture, all the steps still represent them in a holistic manner. However, the article shifts its design methodology around so that the sequence of its steps are different from the one in lecture, Lewis and Reiman mix aspects of the design and prototype stage and also a bit of the evaluation step. However, one similarity is that Lewis and Reiman state that one should iterate and improve upon the design.


Cheng Sima - 1/24/2014 23:59:15

In general, the Lewis & Rieman design cycle is still quite similar to the three-stage cycle described in lecture. It first finds out for whom and for what are we designing, what we can learn from existing resources for the design, then have a rough design and prototype it, and finally test and evaluate, and constantly go through the cycle again to update features.

However, many things have changed since the time the article was written. Nowadays, not only are mobile applications mostly downloaded through app stores, but also there is a plethora of them that focuses on many similar tasks. Simply pinpointing what tasks need to be done and orienting the design by these tasks might result in an app that is simply drowned in this sea of applications. Designers can now even collect information from users who have been complaining about other apps that perform similar tasks. Also, the "Think About It" step may require different methods due to different mobile devices and technology we use nowadays. For example, the "keystroke" method might be obsolete as most of our mobile devices are now touch-screen and operated by hand gestures. Finally, during the evaluation stage, designers can collect many feedback from Appstore user reviews.

I disagree with L & R mostly for the aforementioned changes due to technological shifts and app development environment changes.


Qianyun Li - 1/24/2014 23:59:19

Q1:Comparing to the three stage cycle, Lewis&Rieman design cycle spends most of the steps conducting user research, analyze and making prototype. I think the reason for that is back then, the cost of correction is too high.

Q2:Their arguments still mostly hold true for today when most mobile apps are downloaded through app stores. However, several things changes: 1. updates become easier and less expensive because users can just easily download the newest updates from the app store. 2. User behaviors can be tracked more easily. Engineers do not need to work in customer services in order to learn about user's experience with their product. They can easily learn by looking at the data of user's interaction with the product. 3. The market is more competitive because the entry barrier is lot lower. The design process should take shorter time in order to stay competitive.

Q3. I disagree with Lewis & Riemann 1) prototyping tool should not be universal. Developer and designer should be able to decide which tool fits their product the best. 2)Task-centered design process might omit a lot of experience-related details. The experience might not be smooth enough.

Austin Chen - 1/25/2014 3:28:01

Lewis & Rieman's cycle incorporates the three main stages in one form or another. The differentiating factor that is proposed in the former, then, is the concept of beginning with concrete tasks rather than more fluid ideas. On one hand, having specific goals to mock up and approach is definitely important. However, I worry that the approach overly stresses conforming to existing expectations, which may stifle truly innovative changes in both tasks and interfaces from being implemented.

Nowadays, updates and changes to apps propagate very quickly. With the introduction of a single central source in the form app stores for iOS and Android, new versions of an app can be deployed within hours; updates to web apps can be pushed in seconds. I believe that the speed with which modifications can be made renders Lewis & Rieman's design cycle obsolete. Though there is still a place for prototyping, testing, and iterating, these stages can now be done after product release, rather than before. For example, one common technique used in design nowadays is live A/B testing, which was enabled by the new speed of updates.

Personally, I'm more of a believer in straight-up building whatever it is that is supposed to be prototyped. I'm unsure if paper or wireframe prototypes adequately convey how a certain design works when it comes down to it. Additionally, interface design tools have advanced since the publication of the article, such that forming a working layout in Android or iOS can be accomplished by dragging and dropping a few widgets. Generally, though, I feel that Lewis & Rieman proposed a good process on how to approach UI design.