The Design Cycle and Brainstorming

From CS 160 User Interfaces Sp10

Jump to: navigation, search

Lecture on January 25th, 2010

Slides

Contents

Readings

Submit Response

Discussion Questions

  • How does the Lewis & Rieman design cycle compare to the three stage (design, prototype, evaluate) cycle described in class?
  • Lewis and Rieman suggest that a system should include generic features that users expect even when these features don't play an important role in the system's functionality. Do you think this is always true?

Student Responses

Bjoern Hartmann - 1/20/2010 13:13:59

This is a test response.


Charlie Hsu - 1/21/2010 23:31:11

Lewis and Rieman's design cycle seems very similar to the design-prototype-evaluate cycle described in class. Their first 5 steps can all be lumped into a "design" phase, the 6th step is exactly prototyping, and evaluation takes place with tests, iteration, and tracking of the design.

As for the assertion that user interfaces should include generic features, even when they don't directly play an important role in the system's functionality, I feel it is not true in many cases. For an extremely simple program where an emphasis is placed on small program size, those extra features may work contrary to the goal of having a small program.


Raymond Lee - 1/21/2010 23:36:03

Brainstormer: I liked the "The Space Remembers" suggestion for brainstorming. There were numerous times I've erased potentially good ideas from a whiteboard because we didn't have enough space. The "spatial memory" theory where a mindset is tied with a position on the white board is pretty interesting too.

Task-centered...: Counting keystrokes/number of decisions is a great metric to go by. I often find my most often used tasks in a program taking too many keystrokes for my liking. I hope we can incorporate some GOMS Analysis in our project at some point.


Jonathan Hirschberg - 1/22/2010 0:46:03

Regarding the question of whether to make a novel interaction paradigm versus using an existing paradigm, the authors advocate using an existing paradigm because users are accustomed to using them and many of the design decisions are made. But does this discourage innovation? If we always have to use an existing paradigm, even for purposes of cost effectiveness and familiarity, could it prevent us from experimenting and thinking of the system in a different way that could possibly be better? That relates to brainstorming in the sense that people need to be open to all kinds of ideas before they decide to weed them out. If we're just weeding out ideas because they're too different from an established system, it seems like we're discouraging innovation.


Thomas Evans-Pratt - 1/22/2010 10:03:00

How does the Lewis & Rieman design cycle compare to the three stage (design, prototype, evaluate) cycle described in class? They seem very closely related. The process outlined by Lewis & Rieman is simply more flushed out. Overall their design cycle is of the same formula but given depth for the overall design process. Lewis and Rieman suggest that a system should include generic features that users expect even when these features don't play an important role in the system's functionality. Do you think this is always true? For the most part I think this is a good design methodology, but it is not always needed. Apple decided against backwards compatibility when most users expect that, but it allowed them to create a (possibly) better OS because it no longer had to worry about that aspect.


Calvin Lin - 1/22/2010 12:36:21

1. The design cycle described in the chapter is essentially a more specific version of the three stage cycle, in that each stage is broken down into concrete and detailed steps. Lewis and Rieman outline a particular method to approaching UI design, which they call task-centered, whereas designing, prototyping, and evaluating are very general terms. Two designers could very easily take different approaches to these three stages. So in essence, the Lewis and Rieman cycle is one specification of the three stage cycle.

2. This is certainly not always true. Especially in today’s society, companies that don’t do something different very often get overlooked and unnoticed. The mobile space is a great example of this, where companies such as Apple and Google are pushing out innovation and challenging the way people are used to engaging with their phones. In general, companies should not always be afraid of taking a risk in trying to modify users’ behavior and how they are used to interacting with applications. If it were still the case where companies always included old features, the level of innovation we have seen probably wouldn’t be as far as it is today.


Jason Wu - 1/22/2010 14:27:00

It seems to me that the Lewis & Rieman design process is an expanded version of the three stage cycle described in class, as it goes into more detail about what steps should be taken during each of the design, prototype, and evaluate phases. The design phase includes the first five steps of the Lewis & Rieman process (task and user analysis, choosing representative tasks, plagiarizing, roughing out the design, and thinking). The prototype phase includes the next step of the Lewis & Rieman process, namely creating a mock-up or prototype, and the evaluate phase is equivalent to Lewis & Rieman's 7th step, which is testing the design with users. While we did touch on the next two Lewis & Rieman steps, iteration and eventually building the design, in lecture, we did not really discuss tracking and changing the design, which I believe are critical to the success of any product.


Jessica Cen - 1/22/2010 17:19:28

Lewis & Rieman design cycle is more complex and requires more elaboration than the three stage cycle described in class, and it puts a lot more emphasis on the design stage. Like the three stage cycle, the Lewis & Rieman design cycle needs a good understanding of the user and their tasks. However, The L&R cycle also includes the use of the GOMS analysis to estimate task time. Furthermore, the L&R design cycle is very similar to the three stage cycle since both require the creation of a mock-up or prototype. Both cycles agree on sketching the product on paper. However, each cycle suggests different interactive prototyping rules. The L&R cycle also suggests testing the design with users, whereas the three stage cycle also suggests evaluating the product without users. Evaluating the product without users will be useful when correcting major mistakes that can be easily detected. Also both cycles agree on changing the design in the future in order to correct mistakes and improve the product. Finally, I believe that including generic features that users expect even when these features don't play an important role in the system's functionality is important at some extend. Nowadays, people expect the computer cursor to be able to select any text and copy it. It has become intuitive for many computer users. Disallowing this feature may disappoint some users, even though the purpose of the product isn’t to select and copy with the cursor. However, I believe that unimportant features or features that may cause malfunction must not be included in the system’s functionality. For example, cutting text from a web page should not be allowed unless the web page is in edit mode.


Tuan Le - 1/22/2010 21:28:02

1)Lewis & Rieman design cycle contains 11 steps, but the first 8 steps could be summarized into three stages (design, prototype, evaluate) that we discussed in class. The design stage will include: Figure out who’s going to use the system to do what, choose representative tasks for task-centered design, plagiarize, rough out the design and think about it. The prototype stage will be “Create a mock-up or prototype”. The evaluate stage includes: Test the design with users and iterate. Out of the steps listed in Lewis & Rieman design cycle, what grasps my attention the most is the idea of “Plagiarize”. From my experience, I absolutely agree with the authors’ idea that we should “follow the lead of the existing system”. This is like someone who is a PC user. It is not likely he or she will switch to Mac some day. I have been using PC for more than 10 years. Although Mac is growing up quickly, I still like PC better. Perhaps, it’s because I am not familiar with Mac. Using something you’ve already known is always easier.

2) I think if a lot of users expect certain generic features, then they should always be included in the system. Putting these features away helps simplify the interface, but the result is that the users might turn away from our company's product to look for other products on the market that meet their needs.


Tomomasa Terazaki - 1/23/2010 17:40:04

The Lewis & Rieman design cycle and the three stage (design, prototype, evaluate) cycle described during class were very similar. During design they both explained about how the designers should think what the users want to see and be the most useful. Then in the prototype part, both descriptions said to write on a paper (the class discussion used a sticky-notes to draw the design). Then use some software to make the prototype. Then evaluating part consisted of testing and iterating the program. Afterwards, building, tracking, and changing the design until the program is completely made so it is user-friendly.

I think a system should include generic features that users expect even if it is not important. The reading used an example of Macintosh users expecting the cut and paste function even if it has no use. This is a great example because Mac Applications all have cut and paste even if it is useless (sometimes it is shown but cannot click on it). This is fine because it only takes up two spaces and usually those functions are not the main function so it does not show up as a cut and paste buttons. I suppose that by cut and paste functions being in the edit section, it just comforts the Mac users.


Owen Lin - 1/23/2010 22:17:56

1. The design cycle as described in the Lewis & Rieman article is similar to the cycle as described in lecture. The ideas of "designing" (figuring out the target audience and making sketches), "prototyping" (making a working model of your system), and "evaluating" (making sure the product is refined and going back to the drawing board if not) are fundamental to the process. The article goes into more depth and lists techniques on how exactly to go about those steps, and they list useful examples.

2. I think that the inclusion of generic features that users expect is often a good idea. The only time that I believe it wouldn't be wise to include them would be if the product absolutely cannot use the generic features in a way that makes sense (i.e. a cut & paste feature in a video playing program such as Apple Quicktime).


Wei Wu - 1/24/2010 13:06:13

The design cycle detailed by Lewis and Rieman is very similar to the "design, prototype, evaluate" outline described in lecture, but goes into deeper detail into each of the steps. For the design process, much of the steps are the same, but L&R discusses a "plagiarize" step that stood out to me. In lecture, we talked about looking at the existing interfaces that are being used for the task and analyze what aspects are successful/flawed, which I agree with, but L&R suggest going as far as copying existing paradigms for button placement and menu names, following a "if it ain't broke, don't fix it," logic. I think that one has to be careful in following this philosophy in designing a new interface, because if the resulting product is too similar in feel and use to what already exists, users will find little incentive to switch to it. The challenge in making a new interface for tasks that already have interfaces is to find new but equally viable (or better) alternatives for details like button placement, to reach out to a sector of the users not completely satisfied with the layout of existing interfaces who will find the new design more appealing for their tastes.

As for the inclusion of generic features that users expect, I believe that generally, features are part of a system because there is some functionality to it. But, if a feature has become obsolete but exists purely out of convention because users are accustomed to it existing, there is little point to keeping it there. Users will adapt to its removal if it served little purpose besides being the users' "safety blanket" before.


Alexander Sydell - 1/24/2010 14:38:46

The Lewis & Rieman task-centered design process is a more concrete and expanded version of the three stage cycle described in class. It contains a cycle and has steps similar to designing, prototyping, and evaluating, but also has more in-between steps such as choosing representative tasks and thinking through a design before prototyping it. However, whereas the three stage cycle is more general, the task-centered process focuses specifically, as the name implies, on the tasks that users will perform using the UI to be designed.

I agree with Lewis and Rieman in that generic features expected by users should be included even if they are not central to a system's functionality, but I do not think that that is always true. Following their example, something like cut and paste is often not central, but is expected by users in any input field and could lead to frustration if it is not supported. However, sometimes these generic features could be completely useless (such as cut and paste in an application without text input), and thus would only add extra time to development with no benefits.

I found the chapter on brainstorming an interesting, almost scientific, take on such an unscientific process. However, as the things to do and things not to do have been tried in practice and have worked for IDEO, they are definitely points that I'll keep in mind for any brainstorming sessions I am part of. In particular, the less obvious points such as numbering ideas and asking the boss to leave could possibly be the most productive.


Victoria Chiu - 1/24/2010 14:55:07

I totally agree that "the best way to get a good idea is to get a lot of ideas." It is similar to writing the first draft of an essay; it is the best to write down whatever that flows in the head and modify them later. Setting rules like how the boss announced that "every new idea has to be patentable" really limits the flow of people's ideas. Doing content-related homework is another good idea. In my past experience, getting a brainstorm session to start is the hardest part of the whole session.

The task-centered design process seems rather intuitive. But I never thought of using existing interface might be a good thing. I did not realize that it usually takes time for people to get used to new interface even if the new interface requires fewer steps.


Victoria Chiu - 1/24/2010 15:12:37

Lewis & Rieman design cycle provides more steps and it has more details than the three stage design. It can be a good thing to consider things in a more detailed way, but it also seems more rigid.

Having generic but irrelevant features can be either a good or bad things. It could be good when users feel more comfortable to have what they expected even when they rarely use them. But it could become a bad idea when these generic features take up too much space or interfere with those that are actually relevant to the functionality.


Chris Wood - 1/24/2010 15:44:14

I felt that the first article, outlining the steps that should be taken when designing an interface, was complemented perfectly by the second article concerning effective brainstorming. Many of the steps outlined for optimal interface design consisted of gathering one's thoughts and cleary defining the desired functionality of the interface. In order to do this, good brainstorming techniques such as staying on topic and creating a supply of useful ideas on which to build are necessary. A key point made in the article on brainstorming was to keep an open mind. This is relevent to interface design because the needs of users are very diverse and often very hard to predict.


Jeffrey Bair - 1/24/2010 15:47:22

The Lewis & Rieman design cycle is similar to the one discussed in lecture. The L&W design cycle seems to just be an elaboration of the three stage cycle. In stage 1.4 of L&W they rough out the design after careful consideration of your target audience. Then in 1.6 they create a prototype to just show the basic parts that can be done. In 1.7 they test the design with users and in order to evaluate what problems crop up and how well the product is received. This is all similar to the three stage cycle explained in lecture (design, prototype, evaluate).

I don't think this is always true. Oftentimes this will only add to clutter on the program in question. Only when there is a demand for these generic features during the evaluation phase should these features be put in. Otherwise it will only prolong the design cycle and delay the time it takes to ship out the product.


Daniel Ritchie - 1/24/2010 16:12:12

Response to Kelley reading:


Kelley presents a lot of useful brainstorming advice, but he doesn't make any mention of what to do AFTER a brainstorming session. Brainstorms can generate a huge volume of ideas, some better than others: what's a good approach to sorting through all of these? The period of time immediately after a brainstorm can often be, in my experience, the critical bridge between idea and action. If one waits too long or lacks decisiveness, the usefulness of the brainstorm can fade.


Response to Lewis and Riemann reading:


Including in an interface features that users have come to expect, even if they play no major role in the application, does make a certain amount of sense to me. After all, a designer can't anticipate how each user's unique workflow does or does not take advantage of these "typical features." However, one can be overzealous in this approach, insisting on replicating each and every such "typical feature." This likely burdens the interface more than helping it. They key is to strike the right balance between being too novel and being too bloated with familiar functions.


Jungmin Yun - 1/24/2010 16:32:48

I think this is always true. We do not know when users need to use generic features because users take some time to get familiar with new features. When users do not know how to use new features, users are willing to use the generic features. Therefore, a system should maintain the generic functions even thought they are not important any more. This is one way of understanding the users' background that we have to know before we start designing user interfaces.


Eric Fung - 1/24/2010 16:33:05

In the development cycle described in class, evaluation occurs as its own step towards the end of a cycle. The Lewis and Rieman design cycle is somewhat similar, but seems to emphasize constant evaluation of the usability of the interface in each step of the process. Generic features are nice to get the user quickly accustomed to the interface (since it's familiar), but if an interface will be quite different than what has come before, then those features can be left out, since users will have little familiarity anyway.


Richard Lan - 1/24/2010 16:35:33

In the article about brainstorming, the author seems to emphasize the quantity of ideas produced over the qualities of the ideas. Even though an idea may sound crazy, it is best to record it because it may come to some use later. Brainstorming seems like it would sacrifice efficiency for creativity, because many ideas are produced, but only a few get used eventually. On the flip side, the more ideas produced, the more likely one of them will be useful. A brainstorming session should not seem like a normal meeting, so the author says it should not be run as a meeting.


Jason Wu - 1/24/2010 16:39:24

I really liked two of the points that Kelley made in The Perfect Brainstorm. Generating a problem statement at the beginning of a brainstorm seems like an obvious thing to do, but many of the brainstorms that I have attended at work seemed to wander because of a lack of focus. Of course, as Kelley says, the problem statement should also be worded in such a way that it is not too narrow-minded, as that could limit the creativity of the discussion. Another interesting point was that brainstorms should get physical by bringing in objects relevant to the discussion - this will likely help participants stay focused and keep them interested.


Vidya Ramesh - 1/24/2010 16:42:16

While the authors of The Task Centered Design Process bring up some very good ideas about a process for designing, there are a few points that I do not agree with. For example, adding functionality that should not be in a system and is irrelevant to the point of the system just confuses users and encourages them to use the system in inappropriate ways. Also, the authors suggest that using something familiar to users is better than something that totally different. While I agree with this on some level, they seem to disregard the fact that the designers are trying to develop a better system (especially if something familiar already exists). It does not seem desirable to fall into the limitations and pitfalls of an already existent design. Other than these two small points, the authors of The Task Oriented Design Process came up with a very clear and reasonable process for design.

The authors of Brainstorming have obviously used their own company as a model for all other companies in their paper when describing the value of brainstorming. It seems reasonable to assume that their company could be used as a model for some of the other companies out there, but the repeated use of that analogy weakens its effectiveness and strengthens the idea that not all companies are similar to their company. They pointed out a couple of very good actions that I would not have thought of when brainstorming such as building a model, not allowing critiques of ideas, and writing the ideas in various places within a room to encourage spatial memory. The one question that I have is that they were not very clear in describing how to come up with focus ideas for a brainstorm that were not too focused, but also not too wide and implausible.


Bryan Trinh - 1/24/2010 16:55:13

This was my first encounter with a methodology for creating a user interface, but I have learned about an analogous methodology for creating physical products. The task-centered design process parallels the need finding product design methodology for creating physical products. Each of the two methods count their success on focusing on the needs of the user primarily, prototype to understand more, and iterate to finally get it right.

After reading this article I realized the importance of coming into a Brainstorm with the right attitude. Many times before have I been invited to a Brainstorming session only to walk out with the same reciprocated ideas rehashed in a different guise. It was particularly remarkable that the group who Stretched their Mental Muscles by going to the toy store had the most successful brainstorm of the groups. I think as adults, we feel that our experiences and knowledge should guide us in our thoughts... but then we miss the central tenet of a brainstorm, to explore things anew. Forget what you know, and turn on that child like awareness so you don't miss life's smaller details. I think that was the message.


Richard Lan - 1/24/2010 16:57:31

The task-centered user interface design cycle seems to match the design cycle presented in class very closely. I think including functionality familiar to the users, but not essential to the main functionality is important, though not always necessary. It accelerates the rate at which the user becomes accustomed to the new interface because they can draw from their experiences with other user interfaces. This thinking leads the author to say that essential features of existing interfaces could be copied into the new interface as opposed to making new design decisions.


Dan Lynch - 1/24/2010 17:20:31

In response to Task-Centered User Interface Design:


This reading was very informative about the entire design process---from identifying what the system does and who is does that function for, to how to effectively build a design and build it in a way that allows for change with the evolving technology.

I thought that a lot of the ideas were very good. I think that the idea of keeping a checklist and comparing it with the functions that it should perform is a good way to ensure functionality, as well as mapping functions to representations in the English language.

The idea of keeping the future in mind---keeping track of the technology in the world and the ever-changing environment through our workplaces and our homes. This is key. Also, building the design so that these changes can be made procedurally and easily, without hard-coding design aspects such as shapes and colors of interface elements.



Dan Lynch - 1/24/2010 17:21:37

In response to the brainstorming article:

The first thing that struck me is that your really aren't a fan of something if you do it only once a month. Practice and repetition is a key to gaining a skill. In this case, brainstorming was the topic. This article elaborated the different ways to facilitate and impede brainstorming sessions. It seemed to coincide with common sense mostly, but there were some aspects worth mentioning: Getting physical and using spatial memory to help in sessions. I know that this is entirely true---typing an idea up in front of a computer can be mundane---whereas frantically spilling ideas onto a paper napkin can make a much greater impact on our neurological tissues for future recall.

I also thought is was good to mention certain ways not to brainstorm, such as a boss should never say his ideas first which limits the rest of the groups contributions. Also, yet unfortunately in some cases, going to exotic locations was not the answer to creating a productive environment for brainstorming.


bobbylee - 1/24/2010 18:22:56

Question1: Lewis & Rieman(L&R) design cycle supports the idea of the three stages cycle described in class. For designing, L &R suggests that we should make the design task-centered and we should have early and continued contact with the users and designers in order to make a customer-fulfilling design. Also, L&R recommends that we can reference to current applications, which have the same tasks, ‘user interfaces. Therefore, we should observe existing practices as it is said in the class. After having the rough design, L&R reckons that we should also analyze our design such that we can discover our UI’s strength and weakness. Creating scenarios and models are possible ways to analyze our UI. After the design is being analyzed, L&R depicts that we can prototype our design using UIMS or any other prototyping tools. And it is the same idea as rapid prototyping in the slides. The last part is to evaluate the designs. Testing the design with users is one of the evaluations. L&R mentions that we can survey our target group of people to get the feedback and understand the confusion that the users might get during the trial. If the cost is affordable, we should also iterate our 3 steps until to a point that we think it is good for the market. In addition, the product should have regular review after its release in order to catch up with user’s changes and new technology.

Question2: I think it is true in the macintosh example and it is often true.

From the customer’s point of view, if something is good, I would like to buy of it.  Apple-users would buy another Apple gadget since they like the features and UI of the Apple’s products. Therefore, it is essential that the system encompasses the generic features. 

From the point of view of Apple, the common UI and features of Apple products define what kind of image Apple projects to its customers. Besides the Apple case, even if you devise of a new way of doing the same task, it is also good to keep the old ways and features since not all the users are accustomed to the new way. For instance, Facebook has changed its look&feel a few times. However, the new features and the new looks were not attractive to the users. As a result, the users request that they should have their rights to choose to remain the old features and look.


Long Do - 1/24/2010 18:59:46

1) I find both Lewis and Rieman's design cycle and the three stage cycled discussed in class to be very similar. Both put a great amount of emphasis on the design process before any coding is done and recommend having iterations where the design is continually improved upon by a previous version's testing with a sample of the user base. I did like that Lewis and Rieman's design stage also included a stage after the user interface is released that talks about keeping contact with the users so as to get real world feedback and capitalize on any opportunities presented by the users.

2) I don't agree with the Lewis and Rieman's point about including generic features. If the features do not help to serve any of the tasks of the system, then it is just bloat and good design should be to keep a program as simple, efficient, and free of unnecessary features as possible. If users want the generic features, then the system's task should be change to include a task that would require the features and take full advantage of such features.


Daniel Perry - 1/24/2010 20:32:58

The Lewis and Reiman reading go into greater depth with the "design" stage by recommending a task-based approach. This means the product's underlying tasks drive the design process. While I understand their point of "plagiarizing" existing UIs to take advantage of what already works, I think the designer should be highly skeptical of previous UIs and not get trapped into copying something that really could be improved.


Vinson Chuong - 1/24/2010 20:54:32

In response Lewis & Rieman, I believe that task specifications that are too fine and concrete may be detrimental to the overall design. Instead of designing around a list of "real-world" tasks the product must support, I believe more in expanding out from a single goal. Start from a single action--a main goal for for the product--and design around that. Focus more on the action the product is meant to carry out and less on what the user wants to do with the product. Now a days, there are thousands of applications that not only specialize in one action but also in one method of carrying it out.


Calvin Lin - 1/24/2010 20:58:03

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

The design cycle described in the chapter is essentially a more specific version of the three stage cycle, in that each stage is broken down into concrete and detailed steps. Lewis and Rieman outline a particular method to approaching UI design, which they call task-centered, whereas designing, prototyping, and evaluating are very general terms. Two designers could very easily take different approaches to these three stages. So in essence, the Lewis and Rieman cycle is one specification of the three stage cycle.

Lewis and Rieman suggest that a system should include generic features that users expect even when these features don't play an important role in the system's functionality. Do you think this is always true?

This is certainly not always true. Especially in today’s society, companies that don’t do something different very often get overlooked and unnoticed. The mobile space is a great example of this, where companies such as Apple and Google are pushing out innovation and challenging the way people are used to engaging with their phones. In general, companies should not always be afraid of taking a risk in trying to modify users’ behavior and how they are used to interacting with applications. If it were still the case where companies always included old features, the level of innovation we have seen probably wouldn’t be as far as it is today.

2nd reading - The Perfect Brainstorm

I found this to be a very refreshing read. It seems very easy to just have a manager delegate specific tasks without allowing engineers to explore and express their individual creativity. Especially in a very technical field, I find that it can be easy to get bogged down with details and technicalities, and I agree that it having brainstorming sessions where everyone is thinking big picture ideas would be productive and useful. However, I could imagine how office politics could affect these sessions - such as issues with who is taken seriously/respected, giving criticism for someone’s idea, etc.


David Zeng - 1/24/2010 21:00:20

I believe the design cycle that's proposed by Lewis and Rieman, is actually a more specific form of the waterfall approach, rather than a different style of development. The task-focused steps of the cycle is probably a consideration that is taken into account during the development, but is not the focus in the waterfall approach, which may encompass a variety of different focuses. Step 8 makes the similarity between the 2 a bit more obvious. Although steps 9 and beyond go a little bit farther than the waterfall approach because it talks about the steps after the product has come out, it can be assumed that a product is not static after initial production.


Kathryn Skorpil - 1/24/2010 22:17:39

How does the Lewis & Rieman design cycle compare to the three stage (design, prototype, evaluate) cycle described in class? The Lewis and Rieman has more steps than the three-stage cycle from class, but it is essentially the same process. The first step "Figure[ing] out who's going to use the system to do what" is an evaluation of what your target user will be. Also the second step "choosing representative tasks for task-centered design" could also be part of the analysis and inquiry process. "Plagiarize", "Rough out the design", "Think about it", and "Create a mock-up or prototype" are the same as the prototyping step in the three-step cycle. Finally, "test the design with users", "iterate", build the design", and "track the design" are part of the evaluation process. The final step in Lewis and Rieman is to "change the design" which is essentially performing step 1 again given all the information given at that point.

Lewis and Rieman suggest that a system should include generic features that users expect even when these features don't play an important role in the system's functionality. Do you think this is always true? No, I do not think this is always true. Having generic features can sometimes add complication to the system and make it look much more complicated than it actually is. Even though these generic features may be something that is familiar to users, if it is not important to the system, it should not be implemented. Also having more features can make it difficult to spot problems/bugs later on.


Daniel Perry - 1/24/2010 22:46:14

The emphasis on developing a good problem statement was helpful. I've found in my own experience at brainstorms for an interactive agency that many of the ideas were similar regardless of the movie or project because the problem statement was so similar; making sure the problem statement is unique is important. I also like the concept of a warm-up and how the IDEO team would look at objects related to the brainstorm to generate ideas. This isn't discussed explicitly in terms of web interfaces (only tangible objects). Might brainstormers look at other websites before hand?


Saba Khalilnaji - 1/24/2010 22:48:06

The Lewis and Reiman is essentially the same cycle described in class, but it more detail. We need to find a target audience which is part 1.1, 1.2-1.5 talks about the design process and gives you tips such as building upon existing ideas. There's no need to reinvent the wheel. The article concludes with prototypes and testing.

Brainstorming is an essential part of every design cycle and pauling's book makes its importance clear. Brainstomers I think can eve increase the productivity of the employees by raising their excitement and involvement with a project. The team will learn to communicate with each other properly once they know how to properly brainstorm!


Annette Trujillo - 1/24/2010 23:24:10

I had never thought of the plagiarizing concept, and I think it is a really important one. If a user is already used to doing a task from a certain menu or tapping certain buttons, then it makes sense to create a new program that does those tasks in the same way, so as to not confuse the user. I think if there were several differences in the ways that tasks are done for a new program, people might get confused and furthermore feel un-interested in using the new software, and just feel more comfortable using something they already know how to use. On the other hand, if the new software does tasks as the old software, plus with additional new features, then I think a user would feel more comfortable using the new software, at least knowing they can still do the old tasks in the same way, and learn new tasks along the way.


Andrey Lukatsky - 1/24/2010 23:29:43

Lewis & Rieman design cycle employs a very user-centric model, and I was left wondering about the trade-offs, if any, in engineering speed. The user along with his desires, expectations, etc. is constantly taken into account every step of the way. Even before the mock-up is complete, the user plays a large large in dictating the direction of the project. Would it be more efficient to build a rough prototype from the data gathered in 1.1, and then bring the user in 1.7? How many users will know exactly what they want? --- Regarding Kelley's article, I feel that the best ideas come to people quite randomly - not when they're actually trying to think of them. I'm a bit skeptical of the usefulness of brainstorming sessions. Perhaps, it's because I've never followed all the guidelines he mentions in his article, and consequently haven't had a fruitful brainstorming session.



Angela Juang - 1/24/2010 23:42:21

1. The Lewis and Rieman design cycle is very similar to the three-stage design cycle presented in class. While the Lewis and Rieman cycle breaks up each stage into multiple parts, the two cycles both present the same fundamental requirements to come up with a good user interface. In particular, this requires careful planning and design with the user in mind, the creation of a prototype, and testing with real users to refine the design.

2. Yes, I agree that any new user design should include elements that users expect. Even though new user designs will often want to come up with innovative user experiences, presenting a completely new interface with no familiar functions will make users feel alienated. Since for the most part people do not enjoy being put into completely unfamiliar territory, providing at least a few small familiar functions will put them at ease and make them more receptive to learning unfamiliar functions.


Richard Heng - 1/25/2010 0:05:42

I completely agree from Kelley's brainstorming passage that a session should be silly. In my experienced, the more relaxed the situation, the more people open up. This leads to an increase in contributions, and ultimately the best ideas. The bonus of having fun makes it even more worthwhile. I was wondering how often brainstorming sessions would be applied to the task centered design model though. Brainstorming tasks would be helpful, but I believe using this approach to designing mocks ups might be valuable also.


Yu Li - 1/25/2010 0:09:43

Lewis and Rieman's design cycle includes the three stage (design, prototype, and evaluation) cycle we discussed in class, but it also includes some other useful parts such as: plagiarize and tracking the design. Instead of simply doing a three part interface design cycle, Lewis and Rieman's method focuses on choosing specific user tasks that the system should be able to accomplish. I think this is a very interesting and efficient way to design a system, because it addresses the problem and designs a system that solves the specific problem at hand. Instead of spending lots of time figuring other features, Lewis and Rieman's design cycle is very goal oriented.


Darren Kwong - 1/25/2010 0:13:09

The Lewis and Rieman cycle is essentially the same as the one described in class, but the details appear to be guidelines rather than hard rules. I believe the decision to include expected generic features depends on the goal of the system. As Lewis and Rieman mentioned, features should generally be left out if they do not support any of the system's tasks. If the feature is "expected" but does not support any of the user's tasks, then costs should be considered first.


Kyle Conroy - 1/25/2010 0:19:59

Lewis and Rieman's suggestion to include general features users expect even when such features are unnecessary could steal attention from developers and lead to feature creep in a product. Instead, developers should focus efforts on streamlining the core representative tasks and choosing a small number of features to do extremely well. The first-generation iPhone is a perfect example of this methodology. It lacked many basic features (MMS, copy and paste) of cell phones at the time, but made up for it by providing a superior mobile web experience over any platform on the market. Only later did Apple choose to add those general features back into the iPhone platform.


Daniel Nguyen - 1/25/2010 0:26:24

Between the Lewis/Rieman design cycle and the design cycle presented in class, there are several common themes, including the emphasis of the design process as an iterative cycle as opposed to a linear process, as well as the importance of large amounts of interaction with the potential users during the design process. However, I think another important concept that the reading presents (that I do not remember being brought up in class) is continued feedback from users after a finished product is released. I feel this is just as important as evaluation of the product during the design cycle in order to ensure that a product that is relevant when released stays relevant overtime.


Mikhail Shashkov - 1/25/2010 0:59:20

I thought the brainstorming article was an interesting choice for a homework assignment; I definitely appreciated the fact that it defending "true" brainstorming and clarified its meaning.

Just as the brainstorming article mentioned that most people brush aside brainstorming, I'm certain people do the same with some of the task-centered design process. It seems to intuitive and logical when you read it that you almost don't pay attention; but I bet most people don't apply the formula laid out when dealing with real projects. They probably let emotions cloud their design process. For example, I've wasting many many hours trying to fix bugs in code that I should have just re-written from scratch.

Anyway, good opener articles.


Wilson Chau - 1/25/2010 1:32:48

The Lewis & Rieman design cycle is very similar to the three stage (design, prototype, evaluate) cycle described in class, they both follow the same order of designing first, then building prototypes and then evaluating it on users and then making it better.

I think that it should always be true because even though they dont play an important role in the functionality having generic features makes it so that users feel more comfortable with the system, since they've seen some of it before.


Conor McLaughlin - 1/25/2010 2:34:30

In reference to question 2, I can definitely understand the idea of leaving certain features in so as to foster a more comfortable and familiar environment for new or returning users. By leaving in such features, the transition to a newer version or product is more seamless, what with the user feeling as if they have more of a grounding; however, I disagree about the necessity of leaving in all such features. If a designer is careful about removing only a certain number of features at a slower progression, the slight confusion a user may feel at the removal of one or two well-known features would be out-weighed by the new utility offered by the software's ability to perform certain tasks (as the software was originally intended to address).


Andrew Lee - 1/25/2010 6:06:26

The task-centered approach to user interface design does seem to correspond pretty well to the design-prototype-evaluate methodology laid out in class. In fact, there's pretty much a one-to-one correspondence between the three stages and subsets of the steps laid out in L&R.

Regarding the inclusion of "generic" functions, I think that this is not an issue if the representative tasks are chosen carefully. I think that generic functions will arise naturally during the process of improving user-friendliness and usability of certain tasks. Using their own example of cut-and-paste, a task that could call for this function could be reorganizing folders. During the development of a user interface for this task, developers may find that a certain cut-and-paste functionality is desired, and once developers become aware of this, they can be enticed to extend the functionality to an overall cut-and-paste functionality.


Hugh Oh - 1/25/2010 9:59:30

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

The Lewis & Rieman design cycle is very similar to the three stage process described in class. However, the Lewis & Rieman design places much more emphasis on the design portion of the process. I am grouping the first three steps (figure out who’s going to use the system, choose representative tasks, plagiarize) into the category of design. I feel like the three stage cycle from class has more emphasis on making many prototypes and continuing to refine them with each new cycle. The Lewis & Rieman cycle suggests more emphasis on the design phase with the result of cycling fewer times. Another distinguishing factor of the Lewis & Rieman design cycle is the tracking of the product after it has been finalized. Tracking the design is intended to see how the product does outside of testing which will benefit future projects. I think this is a very critical step which the three stage process lacks.

Lewis and Rieman suggest that a system should include generic features that users expect even when these features don't play an important role in the system's functionality. Do you think this is always true?

I think that a system should always include generic features that users expect even when these features don’t play an important role in the system’s functionality. The key words in this statement are “generic” and “expect.” If users are expecting certain functionality and it is not given to them then the system has failed even if it runs perfectly. Generic features can also be changed and still retain their generic functionality which means that there isn’t a good reason to leave out an expected generic feature. Lewis and Rieman emphasize the users rather than the system which, I believe, is the correct way to go about designing a system.


Wei Yeh - 1/25/2010 11:04:19

In most cases, a system's UI should include generic features that meet users' expectations so that they are placed in a familiar environment, which allows them to rapidly learn and explore the system. Without such generic features, users' would be confused and even discouraged from using the system. However, rarely should things always be true in UI design. For instance, if generic features clutter up the UI and distract users' from the main features that are part of the representative tasks, then those generic features should be made less prominent, or entirely removed if they are discovered to be rarely used after testing.


Arpad Kovacs - 1/25/2010 12:25:11

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

The Lewis & Rieman and 3-stage design cycle both begin by analyzing the task and users, then specifying concrete use-case scenarios. However, at this point the Lewis & Rieman cycle takes the additional step of identifying and copying existing interface paradigms to ease users' transition into the new system from previous experiences. L&R also advocate spreading out the decision-making process by describing the design on paper and then reflecting on it, instead of premature rapid prototyping on computer. However, the remainder of the cycle (mockup, evaluation/user testing, and iteration) is similar in both methods, although L&R add the additional steps of final design implementation and post-deployment correction.


2) Lewis and Rieman suggest that a system should include generic features that users expect even when these features don't play an important role in the system's functionality. Do you think this is always true?

Yes, I think that implementing standardized features (such as the example of cut and paste on the Macintosh platform) reassures new users with familiar functionality. Most users are smart enough to understand this system-wide functionality, and will not perceive it as bewildering extra complexity. In contrast, if this basic expected functionality is absent, then the few users that might actually need to use it will be very annoyed at the inconvenience. They could then come to perceive the application as flawed or deficient, which will adversely impact their willingness to learn or use the system.


Michael Cao - 1/25/2010 13:08:40

I don't agree with Lewis and Rieman that a system should include generic features that users expect even when these features don't play an important role in the system's functionality. Take the website Facebook for example. It originally had a very simple and intuitive design that many people got used to. But it constantly changes the look and layout of the website to something much different than before. Although people weren't used to it at first, almost everyone eventually became used to it again as the norm. So I think even if a system does not include generic features that users expect, they will still get used to it with time.


Linsey Hansen - 1/25/2010 13:13:43

So, I am totally one of those people who have approached brainstorming in a rather limited way, since I have probably spent more time writing stuff down or criticizing my own ideas than just trying to throw fun and crazy things out there. The way Kelley explained brainstorming sessions definitely made them seem a lot less like work and more like a fun, enjoyable creative process, unlike the things I was introduced to back in grade school. So yeah, this new approach definitely sounds more interesting and will hopefully be more productive. Oh, and I am also grateful for that plagiarism section in L&R, since I've personally always been one of those people who feels like everything needs to be original, but borrowing a few functional, familiar features makes sense, because it not only makes things easier on the user, but the designer as well.


Sally Ahn - 1/25/2010 13:33:51

Lewis and Rieman's design cycle emphasizes the importance of testing the prototype with real users who perform "representative tasks" to "make sure the system is complete," and this reflects the "create scenarios of actual use" step that was described in lecture. Moreover, the "plagiarizing" that they describe correspond to "observing existing practices" step that was covered in lecture. However, I wondered what should be done for functionalities that have no single dominant convention. For example, the Mac platform has windows with the control buttons on the upper left corner while in Windows, the controls are on the right corner; in other words, there are opposing "existing practices." Lewis and Rieman also suggest that "you should find existing interfaces that work for users and then build ideas from those interfaces into your systems as much as practically and legally possible," which made me wonder where exactly where the boundary lay between "practically" copying good interface design ideas and illegal plagiarizing.


Kevin Tham - 1/25/2010 13:37:22

In Lewis & Rieman's reading material, their design cycle is largely similar to the three stage (design, prototype, evaluate) cycle described in class though it's just that the L&R reading was more in depth. Both descriptions rely on observing current practices and "plagiarizing" from them, then come up with a prototype that fulfills our criteria, test, and iterate until all conditions are finally met. These processes are pretty straightforward. Lewis and Rieman suggest that a system should include generic features that users expect even when these features don't play an important role in the system's functionality. Do you think this is always true? Regardless if it's useful or not useful, it's good to follow standards. I think one of the most successful things would be how well a system integrates with other systems, and if an application usually has a "file" menu, then the system we are developing should also have one. I believe consistency is best. It also allows us to use these features in the event they do become needed without having to make a drastic change to the UI. E.g. Many people say that Mac OS X is very user friendly, all applications have a "Mac look," regardless if that look is a useful feature of the UI.


Nathaniel Baldwin - 1/25/2010 13:38:00

A couple things from the reading jumped out at me. First, and this may be nitpicky, the Kelley article emphasized the lack of note-taking in a "brainstormer" several times, but also noted that things did need to be written down, both so they can be remembered and revisited. I wish it had spent a paragraph or two spelling out a little more clearly how they balance these statements that are seemingly at odds. The other thing that caught my eye was in the "Hypertopic" section at the bottom of the Lewis and Rieman article, where they said of the team that is working on building the user interface that it need not necessarily contain someone who is specifically a UI analyst. Their idea that the team should be multi-disciplinary and have a "shared commitment to interface quality" makes sense, but it seems strange in a text about designing user interfaces to imply that UI design is more of a process than a skill. Perhaps I'm just misinterpreting. Oh, also - I haven't heard anyone reference HyperCard in a LONG time - pretty cool.


Alexis He - 1/25/2010 14:40:15

on Task-Centered Design:

Plagiarize sec 1.3: Since the reading doesn't make it clear what constitutes legal or illegal plagiarizing, it would be helpful if we could learn some guidelines. For example, I've seen websites who closely copy original websites and brand them as their own (http://www.techcrunch.com/2007/01/11/suggestion-if-you-copy-digg-at-least-thank-them/). Would this be considered legal or illegal?

on brainstorming:

A demonstration of a good brainstorm-session would complement this reading nicely.


Esther Cho - 1/25/2010 15:05:27

I don't think it's always true that a system should include every generic feature. The example in the reading uses cut and paste which seems like an unfair example because about every system uses this feature. If it's something the user expects, it should be considered whether it would help users or just get in the way (such as auto-complete can be in certain cases).

I quickly wanted to note that Kelley's reading was rather interesting and presented ideas I haven't heard before (such as taping paper everywhere to write down for spatial memory). I wonder how people go about instituting this kind of creativity into their work force.


Mohsen Rezaei - 1/25/2010 15:09:05

  1. 1: Lewis & Rieman explains how after a rough design and creating mock-up/prototype we need to test the design, whether its a computerized design or mock-up/paper design, with users who are the target of our design. After testing the design with users we are most definitely going to have to change/edit some parts of our design. This is exactly what the three stage cycle described in the lecture points out. We need to design, create a model, and at the end evaluate. If errors found in the evaluation stage the we cycle/iterate through the same steps.
  1. 2: This is true in most cases because users feel very comfortable when the interface looks familiar to them. In my opinion when placing generic functionalities in our design we encourage users to continue and learn more about the design/program. If everything looks brand new to users, who are not comfortable with new designs, then they might get discouraged to continue learning about the program designed.


Brian Chin - 1/25/2010 15:17:09

I thought the reading about the task centered design process described something very similar to the design process described in class, except that it seemed to emphasize taking features in already existing systems and incorporating it into your new design. I think this would hinder developments of new and innovative systems, as it would become easy to conclude that the current system works perfectly fine, and that there would be nothing, or not much, to improve upon. The process described in class however, seemed to emphasize incorporating new ideas much more. The second reading describes an interesting way to brainstorm that seems very effective in eliciting new ideas.


jonathanbeard - 1/25/2010 15:36:52

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

The basic three stage design cycle described in class is expanded upon by Lewis & Reiman. They describe how the design process must first identify its users and tasks. Further, they provide plagarism as smart approach to initial designing. Lewis & Rieman elaborate upon the simple "design, prototype, evaluate" cycle, proving that designing is not as simple as counting to 3.


"Lewis and Rieman suggest that a system should include generic features that users expect even when these features don't play an important role in the system's functionality. Do you think this is always true?"

In most of the cases I can think of, a lack of generic features is more of a problem than the addition of an unused generic feature. When the iPod Touch and iPhone came out, I thought for sure that I would be able to use my Apple keyboard with them. Both devices have BlueTooth capabilities, my keyboard works with all other Apple computers, so why doesn't it work with my iPod Touch. Adding the ability to use an external keyboard isn't a key feature of the devices, but it wouldn't take anything away from them. Another feature users would expect out of the same devices is the ability to choose a background picture for their desktop, a feature available on every computer and phone except Apple iPod Touches and iPhones.


Boaz Avital - 1/25/2010 15:39:21

The article on brainstorming reminded me of a case study I read about a group at Proctor and Gamble whose only purpose was to think outside the box and create new product lines. There was a contrast between P&G, which was a very corporate environment, and their group which was more open and fun (like all those crazy startups nowadays).

I liked the task-centered design process. I especially appreciate the concept of "plagiarism." In software as in many areas in life, copying someone else's successful methods (and building from that) is the best way to do things.


Long Chen - 1/25/2010 15:57:44

The readings put in writing what everyone approaching design or a new project has thought of. They definitely give insight to the details that may be glossed over during the actual implementation. I am also taking CS169 concurrently and the task-first process definitely sounds more flexible and useful than the waterfall process model. As for the brainstorming article, the writer did exactly what he said was not productive; instead of following through with a "show and tell" approach, he wrote a rigid article detailing each step of brainstorming for future sessions. Brainstorming is proportional to the types of people involved in the session and can occur spontaneously. Just going through a couple of iterations will nail down the best brainstorming strategy for each distinct group.


sean lyons - 1/25/2010 16:01:28

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

While the Lewis & Rieman cycle more heavily emphasizes and spells out their iteration of the design phase, the two cycles are largely analogous. The stages discussed in class seem to favor prototype experimentation, whereas L&R favor spending more time in the design process. The rapid prototyping steps favor mockups, playing with the physical elements of the product, and building many successive UIs towards a Platonic ideal. This approach is not quite the opposite of K&R's "measure twice, cut once" sensibility, but the difference in ideology and appeal to different mindsets is clear.

  • Lewis and Rieman suggest that a system should include generic features that users expect even when these features don't play an important role in the system's functionality. Do you think this is always true?

Generic features are generic because they are ubiquitous, and can always be expected to exist. A piece of software's scope can be narrow or broad, but wherever it boundary ends, the point at which it returns to its native environment must be clean. A windowed application should always have the standard suite of buttons in their familiar locations, as a user can be expected to want to fullscreen, minimize or close a program in the defined, generic way. Apple-Q or alt-f4 should be expected to close an application immediately, absent a specific, good reason. Just as the functionality must be there, the standard way to apply that functionality must also be there, or be intuitive enough to excuse the exception, or else the functionality might as well not have been added at all.


Divya Banesh - 1/25/2010 16:10:51

1. The Lewis and Rieman (L&R) design cycle and the 3 stage cycle discussed in class are similar in that they are both task driven and follow the idea of iteratively gathering information, creating a prototype and testing with users. The L&R cycle however, is more descriptive and explains beyond the iteration cycle into actual implementation and post-implementation steps. For example, Steps 1-5 from the L&R design cycle is what the 3 stage cycle calls "Task Analysis and Contextual Inquiry", but both include observing existing practices and interfaces, creating scenarios of actual use by counting keystrokes or mouse movements and walking through the tasks and creating rough designs. Step 1.6 from the L&R cycle corresponds to the "Rapid Prototyping" step when paper sketches and prototypes of the system are built. Also, Step 1.7 from the L&R cycle corresponds to the "Evaluation" step, where the users test the product and give feedback. Finally, all these steps are repeated until both the designers and users are satisfied with the results. At this point, the actual product will be produced by the company. However, under the L&R design cycle, there is a final step that advises the designing team to keep updating and upgrading the product to keep up with current demands.

2. I agree that generic features that users expect should be added to a system, as long as they don't hinder the tasks the system is trying to accomplish. A solution may be to give the user an option to turn off an extra feature if it becomes a problem. For example, in Microsoft Word, there are features that automatically capitalize certain letters in a sentence or automatically fix spelling mistakes if it seems that the word typed is very close to what the computer thinks the word actually should be. As a beginner user to Microsoft Word, these features might be helpful to make sure text is typed properly, but otherwise, these features might be problems to the user rather than a help. Many times in the past I've had to decapitalize a word or change the spelling of a word to what I had originally written because it should have been what I had originally written. Going back to fix the computer's mistakes is a waste of the user's time and hinders the user from quickly and effectively creating a text document.


Matt Vaznaian - 1/25/2010 16:17:35

One thing stood out for me in the Task Centered Design Process article. At the end of section 1.3 there is a part about how between trying to create a new and more efficient process for a function and using what the user already knows (which means possibly doing more than might be necessary), one should design a function that integrates what the user already knows. I personally would want to help the user by creating new functionality that in the long run would benefit them. However, I guess it makes sense that users want what they are already comfortable with, even if it means adding a few more keystrokes. If only people were more open-minded to spending a few weeks to get used to something slightly different, their lives would be so much more efficient.


Richard Mar - 1/25/2010 16:57:57

  • Six Ways to Kill a Brainstormer contained some useful points on how not to stifle the creative process. In particular, the part about the boss/project leader not speaking first during a brainstorming session reminded me of many meetings where the group leader spoke first, and we consquently had a hard time coming up with good ideas. In the end, however, whoever is in charge needs to step in and enforce any deadlines or stop the idea creation process before it spins out of control. Otherwise, the team would endlessly produce ideas and no results.
  • Lewis and Rieman's design cycle is essentially a more in-depth and explicitly user-centric version of the design-prototype-evaluate cycle shown in lecture. The plagiarism bit is interesting; while it is good to follow convention, there are a lot of people who are completely unaware that a convention even exists. I do agree that it is vital that the designer maintains contact with the user- I've been witness to a case where the designer met with the user once, built the app, and went back a week later only to have the user say, "This isn't what I wanted."
  • I disagree with providing generic features, particularly when said features wouldn't fit in well with the application. The worst case would be a feature that looks like something in line with expected conventions, but does something different. Users would be confused and irritated by such a bait 'n' switch.


Juan Cadena - 1/25/2010 17:11:29

In regards to the Task-Centered User Interface Design Process, I am wondering what an appropriate time frame would be for a complete application to be produced. I am curious about this since the needs of web/mobile users change so frequently that having to redesign an application well into the testing phase would be wasteful. Also, in the existence of a competing company/group, is it okay to speed up the process? Not necessarily skip phases but maybe shorten each phase?


Andrew Finch - 1/25/2010 17:17:08

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

The Lewis & Rieman design cycle includes this basic 3-stage cycle (design a product, build a prototype and test it on users, then iterate while making improvements based on the feedback). It does, however, expand a lot more on initial steps (how one should develop an idea and how one should go about constructing the preliminary designs), and on final steps (how to maintain follow-up on the product and keep users satisfied, etc.)

2. Lewis and Rieman suggest that a system should include generic features that users expect even when these features don't play an important role in the system's functionality. Do you think this is always true?

Yes and no. Features that aren't critically important but are still expected and likely to be used should be included (such as copy and paste), but features that are generic but really have nothing to do with the application (like having print in a file browser) should obviously not be included.


Mila Schultz - 1/25/2010 17:20:39

The IDEO article on brainstormers advocated for a specific brainstorming structure despite emphasizing unstructured mental creativity, which was interesting to me. It seemed that he distinguished between brainstormers and meetings, almost in a polarizing way; I would like to read about other types of meetings that encourage creativity in different ways from a brainstormer. The task-centered design process article seemed to come from the perspective of software design, but obviously the methods can be extended to any sort of system design that involves users. Understanding that the chapter was meant to outline a trusted design process that can work for a set task and/or team, I do wonder if designers should be more encouraged to push the boundaries of current interface paradigms rather than end up in a local maximum, which seems possible from following the steps in the chapter (though it is a good outline even if testing a wildly new idea).


Swapnil Ralhan - 1/25/2010 17:21:44

On one hand L&R have a point, and generic features should be preserved in order to capture an existing market, and allow users to have a familiar feel with the interface. On the other hand, an intuitive enough interface can enable designers to get rid of deprecated features(which may often add clutter, making the interface less user friendly). For example the iPhone does not have many of the features of traditional mobile phone interfaces, both in terms of numeric keypads, as well as the OS interface. Its intuitiveness enables iPhone to capture a significant market share.


Geoffrey Wing - 1/25/2010 17:25:17

There is definitely a strong connection between brainstorming and the task-centered design process. At many of the design steps, you will need to brainstorm. Not only just to get ideas and make decisions, but the brainstorming article also talks about creating rough models, which is part of the design process. Also, the brainstorming talks about bringing in competitive products, which is related to the "plagarize" step. Combining both articles will make for excellent designs. I have also learned about similar processes in CS169, the software engineering class.


Weizhi Li - 1/25/2010 17:53:51

Lewis and Rieman’s design cycle is more comprehensive than the three stage cycle described in class. Lewis and Rieman suggest an eleven stage design cycle. According to the article, the authors suggest that the rough description of the design should be put on paper instead of be programmed into a computer. This stage, in my opinion, is very important, because the designers’ imagination is usually limited as they make too many decisions too early in the whole process. And it also can save a lot of time. Another interesting point mentioned in this reading is that the user interface often occupies more than half of the code of commercial product. There is no denying that the design of the user interface is becoming more and more practical in this industry.


Weizhi Li - 1/25/2010 17:57:58

Lewis and Rieman’s design cycle is more comprehensive than the three stage cycle described in class. Lewis and Rieman suggest an eleven stage design cycle. According to the article, the authors suggest that the rough description of the design should be put on paper instead of be programmed into a computer. This stage, in my opinion, is very important, because the designers’ imagination is usually limited as they make too many decisions too early in the whole process. And it also can save a lot of time. Another interesting point mentioned in this reading is that the user interface often occupies more than half of the code of commercial product. There is no denying that the design of the user interface is becoming more and more practical in this industry.


Raymond Lee - 1/25/2010 18:01:32

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

The Lewis & Rieman design cycle is quite similar to the three stage cycle described in class. It fleshes out exactly what should be done during each of the stages, with specific tasks (plagiarize, creating a list of tasks) to be performed before moving on. It also stresses iteration as part of the evaluation stage discussed in class.

   * Lewis and Rieman suggest that a system should include generic features that users expect even when these features don't play an important role in the system's functionality. Do you think this is always true? 

I think this is always true, if the aim is to provide familiar surroundings for the user. Missing a generic feature can cause some confusion and frustration in users, especially those not savvy enough to completely learn a new system. Generic features, such as the copy/paste that the article mentioned, provide a consistent change of environment for the user to adapt to.


Comments

Calvin Lin - Jan 21, 2010 05:20:05 pm

I think we are supposed to use the Google spreadsheet form for submitting our reading responses.

Bjoern Hartmann - Jan 22, 2010 05:24:28 am

Calvin is correct - please use the "Submit Response" link which directs you to a Google form. I have copied the link onto this page underneath the reading links to clarify.

Daniel Ritchie - Jan 22, 2010 09:19:46 pm

A couple points of confusion:

1) Must we address the two "Discussion Questions" listed above, or are we free to discuss other points of interest? Information on the Wiki seems to suggest the latter, but I wasn't able to find a really definitive answer.

2) Seeing as we have two reading selections this week, should we address both (i.e. write two paragraphs), or should we post only one comment/question?

Daniel P. - Jan 24, 2010 08:13:26 pm

If you check under "Announcements" on the main page it should answer your questions regarding posting a response. I'm getting an "Authorization Required" when I try to view the Kelley reading. Any thoughts on what user/pass I should be entering to access this?? It doesn't work with my wiki user and pass.

Daniel Ritchie - Jan 24, 2010 10:00:42 pm

Yeah, the profs just added that info. Just in time, too!

The user/pass info for the readings is in the slides.



[add comment]
Personal tools