The Design Cycle and Brainstorming

From Cs160-sp08

Jump to: navigation, search

Lecture on January 24th, 2008

Slides

Contents

Readings

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?

Maneesh Agrawala - Dec 23, 2007 09:11:32 pm

Lewis and Rieman suggest plagiarizing as a way to start solving a design problem. Similarly Kelley suggest piggybacking on the ideas of others during brainstorming. Building on and extending the ideas of others seems like a common approach to generating new ideas. This is also a common approach to doing scientific research. Kelley also suggests some other ways to spur creativity. Are there other techniques, beyond those that Kelley discusses, to help people generate new, creative ideas?

Diane Ko - Jan 22, 2008 10:17:35 pm

Lewis and Rieman present the same basic design cycle of design, prototype, and evaluation presented in class. The main difference really comes from the more detailed explanation of the design element. Lewis and Rieman's approach to task-based design has developers use existing tasks to shape the development of the task at hand. While this does allow for better ease of use, it seems to limit the level of creativity in products. Lewis and Rieman mention that if a certain aspect of a task has no connection to a larger representative task that it should be tossed out. However, this can be problematic if a client chooses to have a unique way of interfacing with customers.

Brian Taylor - Jan 23, 2008 01:14:46 am

Lewis and Rieman's approach to development seem to differ from Kelley's approach. Lewis and Rieman suggest starting with a product that already exists and has some of the desired functionality and working from there. Not only do they bring up the ease of using previously-developed features such as cut and paste, they also encourage developers to follow well-established practices used by other products that the end user will commonly use. Kelley, on the other hand, seems to encourage starting from potentially random and ridiculous ideas thrown out during brainstorms and honing the more popular ones into possible results. I found that contrast in perspectives a little interesting and think that Kelley's approach would be a more popular way of beginning projects today.

Jason Wu - Jan 23, 2008 10:46:02 am

Lewis and Rieman also use prototypes, evaluate them, and iterate that process. However, their real insight comes from their design stage. It seems like a great idea to 1) start with tasks in mind during the design phase 2) start with successful, previously existing interfaces This will keep the thinking focused and structured and is great as long as it doesn't create a creative mental block at the same time. I suppose at the very worst you create a product that is on par with past products.

Another advantage is building a product that customers are already familiar with, with features that customers expect and therefore desire. I believe this is most often a good tactic when looking at customer satisfaction, but perhaps is not necessary when you're trying to design an interface to a product that isn't really analogous to past products. If there are past features that aren't really relevant to the new system's functionality, it may be worth it to rethink those potentially awkward features.

Glen Wong - Jan 23, 2008 11:48:03 am

Lewis and Rieman describe a design cycle that seems to be a further developed version of the three stage (design, prototype, evaluate) cycle described in class. While I agree with most of the concepts and steps presented in their design cycle, it seems to me that it is a bit overcomplicated and unreasonable. The level of interaction between the designer and the user described in this process with a close and consistent communication between designer and user is very difficult to realize in reality. Also the article talks about the importance of having centralized management which sounds good on paper, but leaves the question "What happens when the team consists of thousands of people working on a gargantuan project?" How does a centralized management deal with such a large number of developers while still maintaining the close communication between different parts of the team? My take on the suggestion that a system should include features that a user expects but that are unimportant to the functionality of a system is that this isn't always true. Systems typically evolve over time to include new features and to innovate on older features. At some point it becomes too overwhelming for the user if new features are added and outdated ones still remain.

Eric Cheung - Jan 23, 2008 12:16:11 pm

The Lewis and Rieman design cycle is relatively similar to the three stage cycle described in class, except they seem to go a little beyond that by mentioning design tracking after the design has already been considered finished. This is sort of like an extra evaluation phase after the cycle has finished and before the next cycle begins. Their suggestion to include generic features all the time is not necessarily true, if for example, those generic features are so far removed from the main functionality that the user gets confused as to why they are included and how they are supposed to be used. Plagiarizing may not be the best approach in all situations, especially if you want to differentiate your design from all the other ones out there. Just because something is already being used (or over-used) doesn't mean that it doesn't require further tweaking. It may have been designed a long time ago to meet different needs.

Scott Crawford - Jan 23, 2008 01:26:19 pm

Kelley gave some lip service to 'where to start' when creating your own super-charged brainstorming group (i.e. his comments about what to do to engage people who aren't used to regular brainstorming sessions), but his overall description of a 'good brainstormer' seem idealized to how he developed his brainstorming sessions. My question to him would be, what are some natural progressive steps for taking an entire team, none of whom are used to 'good brainstorming', and foster these practices - squashing skepticism about the process as a whole among other things. Another thing I would like to know is how do you 'recover' from a brainstormer? That is to say, once you have all these ideas, do you just let everyone go to what they think needs to get done, or does the team get coordinated to focus on certain tasks (perhaps a little of that is supposed to happen during the brainstorming session but it was unclear)? It seems to me that some kind of management needs to take place in order to utilize the results of a brainstormer effectively. With regards to why the two articles depict relatively different approaches to team problem solving, it seems to me that the two processes are meant for teams that tackle different types of problems. However, it seems that brainstorming sessions could be integrated into at least some of the Lewis & Rieman steps (like 1.5: Think About It; particularly the 'cognitive walkthrough' part could be done as a brainstorm).

Benjamin Lau - Jan 23, 2008 01:45:15 pm

The task-centered design process seems to be a specific instance of the design-prototype-evaluate cycle described in class. In Lewis and Rieman's case, the design involves figuring out the requirements of the system by focusing on what the user ultimately needs to accomplish. From the representative tasks, an eventual mockup is created. The prototyping stage involves "plagiarism"-- basically using existing paradigms that are familiar to the clients. The evaluation stage in Lewis and Rieman's process utilizes direct user testing to ensure that the product meets the user's needs sufficiently. After user testing, the feedback is used in the next iteration of the cycle. I don't think that plagiarizing should always be done. The context might be too different, and the cost might not be worth it. For example, in most computer games, they disable the copy function for text in the game. It's usually not worth supporting it, as the user has no particular need to copy in-game text and it can ruin the experience to be reminded you might have real actual work to do.

Gerard Sunga - Jan 23, 2008 01:25:37 pm

Lewis and Rieman's design cycle seems to be an extension upon the basic design cycle, in the sense that the design stage is more fleshed out and has a strong task-oriented focus. This task-oriented approach works well for basic applications such as those listed within the article, but doing so considerably hinders creativity and innovation. The suggestion of plagiarism, which is a good idea on the surface in helping to maintain the status quo of used software expected by most clients, suffers from the same problems of bringing about an atmosphere of not encouraging any innovation (such as extending upon such features and adding new ones). On the other hand, Kelley offers interesting ideas on using brainstorming to solve this problem of innovation. The suggestions found in the article seem to be great ways to encourage out-of-the-box thinking to extend upon and create new ideas, with as few restrictions as possible. However, I would have liked to have more tips given on how to best use the ideas generated.

Jonathan Chow - Jan 23, 2008 02:12:10 pm

It is interesting to compare the more free-flow style that Kelley proposes for Brainstorms with the much more structured Task-Centered Design Process discussed by Lewis and Rieman. Kelley favors a more free environment that encourages creativity, even if the idea seems absurd. On the other hand Lewis and Rieman suggest just "taking" ideas that have already been implemented and integrating them into the solution. They say this because solutions using features that have already been implemented have a less likely chance of failing. Kelley does not discourage looking at current products for answers, but he likes having a large quantity of solutions to sort through, even if they are not easily implementable. I think that in some respects, Kelley's brainstorming can be integrated into Lewis and Rieman's ideas to have a structured process that allows room for innovation and creativity.

Bruno Mehech - Jan 23, 2008 02:41:39 pm

Lewis and Rieman's design process seems to be the same as the design prototype evaluate process discussed in class, except in more detail. But Lewis and Rieman method seems way to strict by encouraging designers to use existing conventions and designs when they already exist instead of trying to possibly find a better design as Kelley suggests. Lewis and Rieman seem to believe that it is better to use something that users are familiar and comfortable with rather than try to find a new solution that is more intuitive and easier to use. Lewis and Rieman's method could probably easily be adjusted to include Kelley's ideas by adding a brainstorming phase early on in the design process instead of just plagiarizing.

Reid Hironaga - Jan 23, 2008 03:32:33 pm

Kelley presented and developed an inspiring image of what an ideal brainstorm session would include. The focus on mental conditioning for efficient and focused creative thinking emphasizes a need for a comfortable yet stimulating environment. Kelley includes guidelines for organization that seem more targeted toward a manager position than a typical engineer. Lewis and Rieman present a development paradigm that acts as well documented common sense. There is emphasis that a clear layer of abstraction should exist between the clients and the interface, but the interface has a very strong interdependence on the underlying software. For example, interface design options may be predetermined by use of a preexisting implementable paradigm.

Bo Niu - Jan 23, 2008 04:36:49 pm

The process that were given in Lewis and Rieman's Task-Centered User Interface Design are pretty standard and intuitive, and most of the procedures are similar to what we have talked about in class, especially on the iterate cycle. The only addition was the plagiarize section, which was very interesting to me. It effectively pointed out the advantage of building UI based on already established design and the risk of developing novel designs. Kelley has presented many interesting and useful tips which make brainstorm more effective in The Perfect Brainstorm. Out of all the ideas, the warm-up method was very refreshing and yet useful.

Juan Padilla - Jan 23, 2008 04:29:26 pm

It seems to me that their design cycle is simply a more detailed version of the one we discussed in class. I think this is a fairly standardized and mechanical way to approach a project and is intended as a guideline and not an end all way of designing every application. For example, the suggestion to include generic features seems to be a way for them to affirm that it is important to keep things similar in applications for the user; but it does not really make sense to include them in an application that does not utilize them. Furthermore, as someone becomes more experienced in design, he or she will be able to make these decisions on their own instead of following this pattern.

Chris Myers - Jan 23, 2008 04:54:30 pm

The plagiarism step is particularly important, especially when we are dealing with what users are accustomed to. People feel comfortable with consistency and familiarity. I would argue here that plagiarism is the wrong word. We are building a new interface from an old one, and that will change over time - so I think remix is better suited.

Generic features are important because they allow programs that perform different functions to interact in a similar manner and share information easier.

Khoa Phung - Jan 23, 2008 05:57:27 pm

The task-centered design process from Lewis & Rieman seem to be very close to the design, prototype, evaluate cycle with the difference that Lewis & Rieman went into more detail when describing how to create a design. Similarly, both design processes encourage several iterations before releasing a working version, but it seems that Lewis & Rieman approach also encourages customers to be actively involved in the design process.

I think generic features that a users expect are very important even though they may be small. One can see that for example that the popular copy and paste shortcut is being used among almost all programs (Office, Html browsers, other programs). Emacs with its different shortcuts causes a lot of users to avoid using the software. Therefore, you have Emacs lovers and people who don't use Emacs, but can use almost any other text editing software.

Gary Miguel - Jan 23, 2008 07:29:55 pm

I really liked the combination of the two readings. The task-centered design process gives us a general outline of the whole design and implementation process, broken down into its major phases. The reading on brainstorming describes what might be a good method for making breakthroughs within those various phases. For example, during the testing with users phase the team may discover problems with their original design. In trying to come up with a new solution to the problem, brainstorming might help.

Yang Wang - Jan 23, 2008 08:16:04 pm

It is not surprising to see plagiarize as a major procedure in developing User Interface. A good User Interface need to be familiar to users and easy to use. Follow a general standard is very important. For example, most software follows the same hot key combination. Thus when users pick up a new software they can get used to it rather quickly. Brainstorming is also very helpful addition. I think plagiarizing can also be consider as a part of brainstorming as it is taking ideas from past experience. Successful or not, it could be very helpful in developing an effective design.

JessicaFitzgerald - Jan 23, 2008 09:01:17 pm

The Lewis and Rieman design cycle is very similar to the one discussed in class as it emphasizes creating a design, prototyping it, and then improving upon and testing that design. What I found very different from the cycle discussed in class is that Lewis and Rieman suggest looking at already existing designs and modeling your design after them. This seems like a method that will yield ideas that aren't new, fresh, or innovative, but instead minor improvements in the designs that already exist. It forces designers to think along the lines of how things are now and how to modify them, instead of creating something completely new that no one has ever seen and is much better than anything currently in the market. In response to the question of including generic features when they don't play an important role in the functionality of the system, it seems to me that if a feature is not important to the overall functionality and is not something that will help the user then it should not be added for familiarity's sake. Otherwise you the design will have a million features that are there for no good reason and don't contribute to the completeness of the overall design.

Hannah Hu - Jan 23, 2008 09:06:38 pm

The Lewis & Rieman procedure is the same as the cycle discussed in class, the major difference being a more subdivided workflow in the L&R case. The L&R case actually seems less like a traditional cycle, in that instead of iterating to the "beginning" of the procedure (the design stage), it would loop to some point between the design and prototype stages (if there exists such an in-between).

The Kelley approach, unlike the L&R approach of "plagiarizing", takes on a throw-the-cards-in-the-air schematic. If one wants to argue which approach is better, really none of them prevails over the other. It depends on a taskforce's goal: create something new, or improve on an existing idea? The latter might be more pragmatic, on the assumption that an existing idea indicates a need for that idea. Creating something new carries the added risk that the idea, while innovative and/or interesting, might not be pragmatic in the real world.

Zhou Li - Jan 23, 2008 07:07:16 pm

Lewis and Rieman believe that understanding of the users themselves is important. When the software is meant to used by common computer users, its interfaces should have simpler menu items that are intuitive and easy to undersand. But when the user group consist only experts in a certain field, then the menu items can be much more technical. That's why disigners need to be aware of users' backgroud knowledge. Having a set of tasks that cover all functionalities of the system is also important. The idea of plagiarism suggests that building on top of existing paradigms is more effective and less risky for interface designs. The task-centered design process puts a lot of weight on steps before the actual interface coding phase to remind designers that they should have a throughly formulated prototype before continuing on.

For a better brainstormer, Kelley suggests spending time to come up with a good problem statement. Some simple tricks such as numbering the ideas can be very helpful. A good brainstorming session has ripple effect, leading people to actively thinking and discussing the problem afterwards.

Hsiu-Fan Wang - Jan 23, 2008 09:42:29 pm

I think the use of the word plagiarize is primarily meant to be attention getting, and so like Chris Myers, I agree that taking note of existing designs helps to design interfaces that users are more comfortable with, and acts not so much as a way to generate new ideas but instead serves to ease users into improved interfaces. While an interface may be superior in performance to another interface for new users, familiarity and past experiences make it unlikely that users _will_ be new. By artificially restricting changes, improvements are made iteratively, allowing users to learn in a more natural manner.

I think the concept of piggybacking in brainstorming (though I admit I don't recall the specific use of the word) is different. In brainstorming, using others' ideas as a springboard seems more an encouragement of a deeper "search tree", so to speak, and not so much an affordance to the user. This concept more closely matches the mentioned approach to scientific research, and seems to be an improvement to the process and not the resultant product.

William tseng - Jan 23, 2008 09:33:49 pm

The Lewis & Rieman design cycle is basically an elaboration on a specific version of the three stage cycle described in class. Specifically, L&R's article chooses to focus on the how to "design" aspect of the three stage cycle. L&R suggest that one should identify a number of tasks that collectively define what the final product is. In this respect the approach described by L&R feels very bottom-up. In the examples used by L&R such as spreadsheets and wordprocessors, the bottom-up approach is fine because those programs are essentially just a collection of tasks anyways. In other interfaces however such as a webpage for a movie for example, while there are still certain tasks which must be implemented, an overall theme or feel is just as important as the implementation of the individual tasks.

As much as L&R differ from Kelley in their view on how to design and come up with ideas, it is interesting to note that both stress the importance of prototyping. Both articles emphasize the need to draw, scribble, jot, and make visual representations of ideas/implementations.

Joe Cancilla - Jan 23, 2008 10:28:49 pm

Both design cycles are very similar. The 3 step process mentioned in class (prototype, design, evaluate) can be mapped onto the 11 step process described by Lewis & and Rieman. Steps one through five of the Lewis and Rieman article (1. "task and user analysis" 2. Representative Task statement 3. reference existing paradigms 4. create rough design 5. review analysis) correspond to the design phase, step 6 corresponds to the Prototype phase, then step 7 is where the evaluation starts and then begins to loops back to (8) redesigning (Iterate), (9)re-prototyping (Building the design), and reevaluating as the software enters the work world (Track the design).

No, generic features that don't play an important role in the system's functionality can be avoided in certain cases. If one is porting a program from one platform to another, say from the desktop to a cellphone, there are going to be space limitations (both on the screen and in storage) that will require the programmer to make important decisions about which generic features to leave out, while still maintaining a close similarity to what the intended user is comfortable with.

Richard Lo - Jan 23, 2008 10:41:57 pm

The cycle described in the reading is pretty much the same as the cycle discussed in lecture. The design portion of the cycle is fleshed out into multiple steps and considerations, but the prototype and test portions are the same. The iteration leg of the cycle in the reading indicates that the flow of the cycle is circular, just as the cycle in the lecture was circular. Lewis and Rieman's discussion about including non-essential generic features probably isn't true in all cases. When the interface being designed will be mainly utilized in some luxury system or purpose, it may not hurt to throw in some extraneous features just to perk the user approval. However, when the interface is being designed for a specific and important use, such as the navigation of a plane which determines the lives of many people, luxury features such as auto-complete may cause more harm than good.

Michael So - Jan 23, 2008 10:51:58 pm

The Lewis & Rieman design cycle seems like it could be considered as the three stage (design, prototype, evaluate) design cycle. You can group the steps into each of those three stages. Several steps can be grouped under "design", several under "prototype", and the rest under "evaluate". The designing steps in the Lewis & Rieman mentioned about how to always keep the users in mind. I think that is important to do and seems like common sense since the users are the ones who are going to be using it.

Lewis & Rieman suggest that a system should include generic features that users expect even when these features don't play a significant role in the system's functionality. I think it makes sense to do that because I think it would provide comfort for the users. If the users have something they are familiar with in a new system, the users would have a comfort zone and be less afraid to learn to use new features because they have the comfort zone to fall back in.

Besides the ones Kelley discusses, I think there are other ways to help people generate, creative ideas. Watching a movie, reading a book, and taking a walk does inspire people. I just think there are people who already have their own ways to inspire themselves that Kelley did not mention.

Nir Ackner - Jan 23, 2008 11:09:21 pm

While the Kelley and Lewis/Rieman approaches vary in their focus on user needs versus tasks, they do have several key commonalities. For instance, both focus on defining who will be using the product. Kelley uses the example of bike commuters who drink coffee rather than "spill proof coffee cup lids", while Lewis/Rieman describe "awareness of the users' background knowledge" and differences between users as important. Both also have a focus on the use of quick sketches and mock-ups in the early phases of design, before investing heavily in one idea. Kelley writes "[y]ou don't have to be an artist" when sketching out an idea, and Lewis/Rieman have as a key step to "Rough Out the Design" (Another similarity is the aforementioned copying of ideas) Ultimately, both methodologies seem to approach the same goal, but seem focused on slightly different stages in the process. (Kelley on a totally new problem, Lewis/Rieman more on improving existing designs)

Katy Tsai - Jan 23, 2008 11:21:29 pm

While Lewis & Rieman's design cycle follows the premise of the more generalized three stage cycle described in class, the design stage of their cycle revolves significantly around identifying and "plagiarizing" systems and products that are already in place. However, I think their process in really examining how existing products work and what people are used to is a key point in designing products that work for users. Going off of that, there definitely are certain commands and features that people expect. When they aren't there, users grow frustrated when they need to change their habits to accommodate to a new program, but designers also have to figure out when to refrain from adding more than necessary. Certain features that we use all the time may be completely irrelevant to the purposes of whatever they are designing, and adding extra functionality may just add more confusion and more work.

Andry Jong - Jan 23, 2008 11:45:38 pm

Both articles, I think, evolve on design process, both for new products or existing ones. The first article by Lewis & Rieman was very closely related to the discussion we had in our first class about iteration. A part of this reading where it talks about plagiarizing other existing products that the users are used to using seemed to have triggered a controversy. However, I am quiet agree; even though, I have to say it is not the only way to make a new product favorable for the users. While Mac users might not want to change to PC because they have to relearn every feature, a lot of Motorola users (for instance) would change to iPhone in an instance even though they have to...well... relearn every feature. I think the most important thing is to keep the users excited about the new product, or the new series of product that we make. And this brings me to the second reading about brainstorming. Kelley asserts that with brainstorming, companies can come up with wild idea that might be useful that might even be able to solve problems that cannot be solved without creative thinking. However, the fact that Kelley does not put any downside of brainstorming gets me to think about it more. Does it really worth to "practice nearly every day" (p. 55-56) just to listen to some wild ideas that might not even come to anything at all? I am not all against brainstorming at all, since I have done it so many times already, and I know how important brainstorms can be. However, I do not personally think that we should treasure it as much as Kelley suggests.

Jonathan Wu Liu - Jan 23, 2008 11:26:50 pm

Lewis and Rieman's design process is a more elaborate version of the cycle discussed in class. As for plagiarism, certain designs have key principles that are worth plagiarizing such as color schemes or word placement, but we should never plagiarize a design exactly; it reeks of un-originality and laziness (eg. AOL's home page with Yahoo). I also think certain generic features users expect should always be there if only to look legitimate and professional; for example, if we are talking about a company web site, each site should contain an "about us" or "contact" page. I'd also say one of the best ways to spur creativity is by knowing human nature. Most problems are very big and abstract. Just knowing specifically what we need/want can in and of itself reveal the workable solution to the problem.

Yunfei Zong - Jan 23, 2008 11:53:20 pm

Generic features and what L&R classifies as "plagiarism" should go hand-in-hand in every product. No end user wants to read manuals and learn a new way to do the same thing for every new product that he/she has to work with. Especially if the product is replacing something that has been in use for a long time; the end user would find it more inefficient to learn the new way than the time it saves. However, I'm not saying that innovation should never occur. Instead, newer products should have a switching option that allows it to be backwards-compatible to older product users, ie, with multiple ways to perform the same task. One example is the Vista control panel. Personally, I think it's a piece of crap and impossible to find the setting I want to change, but with a click of a button, I can switch it back to classic view.

Alex Choy - Jan 23, 2008 11:55:55 pm

Lewis and Rieman's design cycle is a more detailed version of the three stage design, prototype, and evaluate cycle described in class. The most noticeable difference is the borrowing of ideas from existing interfaces. Plagiarizing can be an effective way to speed up the design process because current users are already accustomed to the interface. As such, it provides an opportunity to study an already effective design. However, it is only a starting point and the designer must deviate from the previous model in order to create something new and innovative. Kelley's brainstorming approach is very open and can be very effective. I believe that having fun and not thinking that what you are doing is "mandatory work" can produce creative and good results. This approach is less structured than Lewis and Rieman's design cycle, and can be just as effective. Nevertheless, it can be less productive if a few individuals are more outspoken than others. I believe that generic features should be included in the system's functionality because a small minority of users may want to use this feature. In order to "make everyone happy," it is important to do so (especially because those who do not use the small feature will not be limited by this).

Jeremy Syn - Jan 23, 2008 11:36:38 pm

The Lewis & Rieman design cycle is very much like the three stage cycle described in class. The Lewis & Rieman design cycle can be outlined in the same way but it can be seen as a more detailed approach to the design process. Designing, mock-ups/prototypes, and evaluating are all important parts of the Lewis & Rieman cycle. Each of the tasks are doing exactly one of those steps.

Although many users would expect generic functionality, I think that it won't have much of an impact on the user's ability to use the product if we do improve a minor function that seems a bit less familiar to the user. People can easily adapt to new situations and so the users will be easily able to get used to the new functions provided.

Michelle Au - Jan 24, 2008 12:32:31 am

Lewis & Rieman and Kelley both emphasize the importance of the user throughout the design process. Lewis & Rieman focus on the importance of the having the users involved throughout the initial design and prototype testing, as well as after the implementation to keep up with the user's changing needs over time. For brainstorms, Kelley suggests using topic statements that focus on customer needs instead of corporate needs. He uses the example of improving customer searches via dial-up as a good customer-focused topic statement. This example is also very similar to Lewis & Rieman's idea of representative tasks. However, they differ greatly in the way they come up with ideas. Lewis & Rieman suggest "plagiarizing" while Kelley has more of a free-thinking approach to ideas. Lewis & Rieman's methods are more structured and better suited for established designs while Kelley's are more free-flowing and seem better suited for new designs.

Siyu Song - Jan 24, 2008 01:03:06 am

Lewis and Rieman discussed the design process in relation to a client, while Kelly focused on the task of brainstorming in order to gather ideas and innovate. Both articles say to use existing objects and interfaces as references for new ideas. I believe this would work, but they don't mention the possibility that designs would get trapped in existing paradigms and they don't discuss a way for true departures from existing innovations to be created. In the Lewis and Rieman article, they almost discouraged departing from previous inventions because it would be too costly with high risk.

Andrew Wan - Jan 24, 2008 12:49:27 am

Given the range of potential UI projects, it seems that the Lewis/Reiman article describes a more pragmatic general approach to design. In most circumstances, the steps outlined in the design cycle are fairly self-evident: define the problem and needs, intelligently create a prototype, test, and iterate. I tend to think the word "plagiarism" is misused in the context of the reading; Lewis and Reiman simply encourage looking to existing interfaces as a source of inspiration, which makes sense when creating related UIs. There's no point reinventing the wheel.

Kelley seems to takes a more idealized view of development, arguing for more brainstorming and creative process. While this could potentially create new, better solutions, the success of the approach is more dependent on the project and team. At some point, especially in larger organizations, brainstorming has the potential to waste time better spent prototyping and iterating. The creative process Kelley describes seems like it would be most useful somewhere within the more general, modular Lewis/Reiman design cycle. Brainstorming is useful in effective teams, but does not always scale well for large projects.

Johnny Tran - Jan 24, 2008 01:07:30 am

The Lewis & Rieman cycle and the design-prototype-evaluate cycle both follow the same basic principle: design something, make it, test it, and repeat. Each emphasizes a user-centric approach, with the L&R approach going deeper into detail and making explicit the user involvement at each step. The design phase takes into account the target audience and use cases, and produces something that directly follows from these requirements (to the extent that L&R advocate plagarizing existing designs that may already solve these requirements, because they are proven solutions that will be the most familiar to users). This is then followed by making it concrete, by roughing it out, doing preliminary evaluation, and prototyping. This serves to give the user successive "rough drafts" of the final product, facilitating accurate feedback. Finally, each iteration ends with testing and evaluation: the current design is tested against users to ensure that it is always within user expectations. L&R also takes the design-prototype-evaluate cycle a step further and suggests that iteration ends when all (user-determined) objectives are met. Furthermore, to cope with possible future changes, the software is built with change in mind, allowing iteration to continue when necessary.

What results from either cycle is software that is strongly aligned with its users and very adaptable to change. Because of this constant feedback loop, developers have a concrete idea of what to build, and customers are allowed to give regular input and receive a product that is built just for their needs. In addition, when requirements change (which will happen many times in the real world), the product will easily be able to change and adapt with them.

It is not surprising that L&R would advocate "plagarizing" generic features, even when the role they play is not significant. These features were present in previous systems and thus users are familiar with them, to the extent that users will expect these features to be present. Meeting user expectations creates ease-of-use and leads to the most intuitive interface. Of course, there are also caveats; "feature creep" is a common pitfall that should be avoided, as each additional feature adds additional complexity. Features may also clash with more significant features of the system. In these cases, a cost-benefit analysis (hopefully incorporating user feedback) should be performed to determine the value of the feature in question.

Edward Chen - Jan 24, 2008 02:00:48 am

With the expansion of the 3-stage cycle described in class, it's easy to see that the design cycle presented by Lewis and Rieman is a more thorough breakdown of the individual steps required to build a user interface. Main emphasis that the L&R design cycle focuses on and elaborates more on is the design aspect. They detail more into how the design should be formulated, considering the users of the interface, the tasks that need to be done, and how the design should be laid. It goes more in-depth into what should be done and what shouldn't be done. Given just the 3-stage cycle, one could just make that diagram showing the cycle, but with the detail that L&R go into, one could make a flowchart out of it.

Another aspect that L&R talks about that one would never think of from just the description of the 3-stage cycle is plagiarizing. However, it makes sense to copy what works. Not only has it been tested in the past by previous generations of user interface designers, but it is likely to be low risk to use such a user interface. Furthermore, the users will be accustomed to a familiar user interface, reducing the learning curve of a new application.

I think generally users who are accustomed to getting generic features even when the features don't play an important role in system functionalities will continue to still want to have those same generic features. While those features may not be missed very much if they were removed, it can be also very frustrating to certain users who attempt to do something that they're used to, yet be unable to do it.

Kai Man Jim - Jan 23, 2008 11:36:11 pm

The idea of Lewis & Rieman design cycle is very close to the idea of three stage cycle that we covered in class except that the design cycle covers more things in detail. Both cycles need people to design and brainstorm first, may stretch the idea/picture on a piece of paper, then start coding after the draft is completed. Then they both need users and testers to try out the UI (iteration), and if they find something is wrong, they need to go get it fix. It is then go back to the cycle of design a new fix, test the code and eval. Therefore, I think both design cycle and three stage cycle are pretty much the same thing.

I don't think it is true for Lewis and Rieman's suggestion about generic features in a system. True, copy and paste is a good example that we should be keeping in our design, but we should also throw out those minor features that people don't even use them since it is a waste of code and it causes limitation on brainstorming new features because there are so many old and minor features that has already been inherit from the old programs.

Gordon Mei - Jan 24, 2008 02:45:55 am

Lewis & Rieman design process focused on understanding the user's needs in the tasks they perform, with an emphasis on "plagiarism" of the best time-tested, familiar methods that are known to work well. The problem lies in the creators' propensity to confine their thinking because of a need to stick to an excellent system they grow to believe cannot be improved any further. For example, hypothetically, an industry may be so absorbed in building upon a mature 2D computer desktop that relatively few people pursue something like a 3D desktop (again, hypothetically assuming that this was supposed to be the future). It also encourages ideas gathered in the style of user focus groups. It addresses the needs of the user, but the users don't always know which method is the best, or what they really want, until the designer does the out-of-box thinking for them.

This is why creators should NOT always include the mass of generic features that users expect even when these features don't play an important role in the system's functionality. Remember when the first iPod came out in 2001? Look at all the naysayers pointing out a lack of features and tech specs and predicting the doom of such a device. The now quoted, "No wireless. Less space than a Nomad. Lame." comment sums up many of their general sentiments at the time. Or perhaps you'll have more modern complaints about why a certain device is destined for failure because a designer intentionally left out an infrared port, or some other feature considered to be part of the original generic set, and subsequently expected to be thrown into the existing feature list. Otherwise, you'd never know how much you could alter anything from the form factor to the power consumption to the general phasing out of older technologies.

Fan Yang - Jan 24, 2008 03:20:04 am

Lewis & Rieman's design cycle is very similar to the three stages described in class but goes into more detail. It splits up the design and evaluate stages into many smaller stages. It also adds on an extra stage that involves a different type of evaluation in tracking the design after it has been released for use, this can be important because many products on the market are not static and always updated to fit the changes that happen to the environment in which the product uses. I agree that using "plagiarism" is a good way to design your system especially since many common place UI features are considered to be default by the end user. If the product uses a whole different method of copying and pasting (instead of the standard ctrl shortcuts) then they might end up being frustrated by having to relearn what should be a simple task, or just frustrated that it isn't what they're used to.

I think including generic features that users expect is a good thing, because more often then not, people will use the product in ways that the designer never expected. If somebody wants to copy a piece of text out of whatever your interface presents, then it should allow the user to copy and paste, even if it has nothing to do with word processing

Paul Mans - Jan 24, 2008 09:14:21 am

While it is true that Lewis & Rieman's "Task Centered" design process fits inside the classical three-stage cycle, Lewis and Rieman nevertheless argue that they are doing out with the old in that they place paramount importance on the user. As others have previously commented, it is the user-task based approach used in the "Design" stage that makes the Lewis & Rieman process different (or possibly just more flushed out) then the standard Design-Prototype-Evaluate cycle that was presented in class. Instead of designing products with tasks that the design team think are important in mind, Lewis and Rieman make it clear that the user is king by designing from the user perspective.


Should a design team always include generic features that users expect even when these features are central in the systems functionality? No, not always. It depends on the audience or target market population for the product. With a product geared towards a youth market which perhaps is a population that embraces change and streamlined products then it might not be a good idea to include superfluous "comfort features". However with a product aimed at appealing to a diverse market population, maybe including some generic and familiar features will lure in customers in a way similar the way comfort food restaurants, like Applebees, draw in customers off the highway.

Pavel Borokhov - Jan 24, 2008 09:17:36 am

The L&R design cycle is very similar to the one presented in class; its main difference is that the design stage is broken up into more detailed stages, some of which might only happen during the very first iteration of the interface's design. For example, figuring out who's going to use the system should hopefully be a stage performed only at the very beginning of the design cycle.

I think generic features should always be included to the point where they still make sense. In the cut & paste example, you should certainly provide this functionality if, for example, your application contains editable text fields, even if its primary goal is not text editing. However, there is absolutely no need to provide such functionality if there is realistically nothing to actually cut & paste. At the same time, careful analysis must be performed to make sure that this is actually the case. For example, a calculator probably will not have any fields that look like editable text fields. However, having copy & paste functionality in a calculator would be very useful as a way of input (with pasting numbers) and export (with copying the result of a calculation).

A quick note about the brainstorming reading: it seems to exemplify the typical "startup" attitude and is probably a great way of coming up with product ideas and improvements. It seems like a real shame that in more bureaucratic companies, these sorts of "brainstormers" would not be truly possible.

Roseanne Wincek - Jan 24, 2008 09:50:42 am

After reading The Perfect Brainstorm, I think the idea of facilitating the creation of new and great ideas is kind of strange, although obviously important. I've definitely had active, stimulating conversations with friends where great ideas are pouring out, everyone is really excited, and it's brainstorming. I suppose that at this point in my life, this type of conversation or interaction happens spontaneously and is about random things that aren't related to a company that we all work for. I think that in a corporate environment, people can get so focused on their piece of the project, that they don't often step away from it and truly examine the overall goals and purpose of the project. All in all, I think that what is important in a brainstorm is that spark or excitement that opens the floodgates for ideas. I think that this article is aimed at helping managers create an environment where that intangible spark can take off.

In Lewis and Rieman, I really like the idea of bringing in functionality and interface that people are familiar with, even if it doesn't relate directly to the functionality of your own system. They use the example of cut and paste. I think that users get frustrated if they can't perform tasks that they generally rely on. We discussed this a little in class, and I think that a low learning curve is important for users to adopt a system. Lewis & Rieman's idea of 'plagiarizing' is like this, if the interface is simiiar to something that people are already familiar with from other systems, I think that the learning curve will be lower.

Adam Singer - Jan 24, 2008 10:04:12 am

Kelley's article on brainstorming really opened my eyes to the fact that what I have been doing all this time wasn't exactly the best use of time and resources. It is very interesting that IDEO, one of the world's leaders in 'funnovation' (as I like to call it), has boiled brainstorming down to a science. In the startup I worked for, we often had brainstorm sessions that lasted for hours, with nothing particularly productive coming out of them. Looking at their list of 7 do's and 6 don'ts of brainstorming, I can tell that our organization hadn't been brainstorming effectively. Particularly, we lacked focus in our sessions: we would often touch on many issues at once, which resulted in not making progress on any of them. Second, the boss always set the rules of the session, which hindered everyone else's creativity.

Next time I have a brainstorming session (or 'brainstormer', as they call it) I will definitely heed these suggestions and hopefully we'll be able to get ideas flowing better!

Henry Su - Jan 24, 2008 09:23:12 am

The Lewis & Rieman design cycle places more emphasis on personal interaction with users. It also describes itself as "task-centered": that is, the design process is focused on building an interface that is able to support a user-specified set of tasks. Although this isn't the case with the three stage cycle described in class, the two design cycles do have some things in common. Namely, both are true cycles, in which prototypes are created, then evaluated, then improved, then evaluated again, etc.

Lewis and Rieman seem to place a lot of importance on designing a familiar interface. Is is probably because of this that they recommend including generic features that users expect even when these features aren't really important in the system. This may be true to a great extent. For example, if a design reorganizes all the menu options to something that the designers deem more coherent, but that deviates significantly from the designs of the past decade, the users of the new interface may not be too happy.

Pauling describes the priciples of a proper "brainstormer", and I agree with most of those ideas. However, I do think that a good brainstorm is only the beginning step in developing/improving products. As good as it is to let minds wander without restraint, developers do eventually have to account for cost, practicality, and consumer demand.

Megan Marquardt - Jan 24, 2008 11:03:02 am

The task-oriented design process seems to incorporate the three stage design process in a few iterations. The basic 'design' portion of the three stage process is incorporated in several steps of the task-oriented design process, where the design is evaluated before it is concretely prototyped. Lewis & Rieman describe how the design is formed based on a specific listing of user tasks, and this must be laid out using sketches without the use of the computer. The simple sketches need to be evaluated and redesigned even before the actual prototype comes about. The prototype is then tested against users and evaluated, and then this process iterates. Lewis & Reiman also describe how the iterations need to keep going even after the software is on the market to evaluate how the general user public and to use that information for designing updates for the program.

Jeffrey Wang - Jan 24, 2008 11:25:13 am

The Task-Centered Design Process is similar to the design, prototype and evaluate stages discussed in lecture. Lewis and Rieman's design cycle begins and end with users. It is important to understand how the product will be used. The authors also put an emphasis on building off old ideas. I believe the authors' intent of plagiarism is to brainstorm of new designs based on what worked or not didn't work in the past. I do not think it is appropriate to copy another's work in its aesthetic sense. However, it is common to see products to provide the same solution functionally.

Also, I do not think that generic features that users expect should always be included. Just because users have become comfortable and familiar features doesn't mean it is the most effective solution. I believe it is easy for an applications if there are too many unimportant features.

Maxwell Pretzlav - Jan 24, 2008 12:06:59 pm

It seems to me there is a danger with the Lewis and Rieman "Task-Centered Design" process that they did not deal with -- that of over-fitting. If one is designing a piece of software around an available example of a specific task, one must be certain that many different variations of this task, such as would be used at different organizations or in different fields, will all be satisfied by the same piece of software. This is a problem that I have seen in Microsoft software's "Wizards" where a dialog steps a user through a specific set of tasks that the user seemingly wants to accomplish. Unfortunately, 80% of the time, these Wizards are too specific to a certain variation of the task, and must be bypassed. When using task-centered design, I imagine it is very important to maintain a certain generic-ness of the task, to account for all the small variations needed by different users.

Robert Glickman - Jan 24, 2008 12:05:46 pm

Reading both of these articles has helped me reflect on my own thought process, design process, and brainstorming. Lewis and Rieman help point out the areas where I have failed in the past with regards to the planning and design process. When I fail to spend enough time on design, including failing to draw out a design on paper, I often find myself running into dead-ends where I must scrap the structure of certain modules because they don't interact properly with the other modules.

I found that the IDEO article helped point out some interesting ways to brainstorm ideas when trying to come up with new project ideas. In the past, I would have proceeding with very little direction and this often led to frustration.

Tam La - Jan 24, 2008 12:29:42 pm

Lewis and Rieman present the same basic design cycle of design, prototype, and evaluation presented in class. However, the design cycle is more developed then the three stage cycle talk about in class. Lewis and Rieman seem to believe that it is better to use something that users are familiar and comfortable with rather than try to find a new solution that is more intuitive and easier to use. For a Better Brainstormer, Kelley does not discourage looking at current products for solution, but he likes having a few solutions to sort through. Kelley also suggests spending more time comiming up with a good problem statement before spending time on the design process.

Brian Trong Tran - Jan 24, 2008 01:00:20 pm

The Lewis & Rieman design cycle differs from that mentioned in class in the manner that the Lewis & Rieman design starts out based on what already exists and improving upon that. Otherwise, they are very similar. It is not always a good idea to have a system include generic features that users expect because different users expect different things and fulfilling all those expectations would result in a very clunky system.

Cole Lodge - Jan 24, 2008 01:05:38 pm

The Lewis and Rieman articles design cycle reminded me a lot of the XP design cycle I learned about last semester in CS169. Both heavily depend on the input of the user and attempt to have several iteration of development. I do believe that all generic functionality expected on a system should be implemented; this allows the user to feel more at home in a new application. I find, for myself, that when I run into an application that has moved everything from where I am used to and functionality is not there that I expect, I become far less productive.

Jeff Bowman - Jan 24, 2008 12:48:55 pm

Lewis and Reitman seem to recommend keeping consistent design elements, but it's easily to see places where they just don't fit. For instance, putting "copy" and "paste" in a computer game is silly, if applicable at all. However, even there the rule isn't hard and fast: an MMORPG may require you to type in a description of a character or item, and I can see how users would be instantly frustrated with the thought of transcribing several paragraphs longhand.

The point seems to stand in two forms: One, users that are used to interface conventions will probably expect that there is an easy way to solve the same problem, like the copy and paste feature above. Two, users are less disoriented when they see familiar things, like Copy and Paste, the same way people are less disoriented when they look at a room and see power outlets about six inches from the floor. To some degree, the concept of consistency is comforting, even if you don't necessarily have a cord to plug in, or any text to copy/paste; also, the learning rate is much quicker, because people already know how to interact with the interface at some level.

Seeing some of the reasons for consistency—the need for simple solutions, and the need for comforting familiarity—helps tease apart what those consistent features actually accomplish, and when that rule should be kept or broken.

Ravi Dharawat - Jan 24, 2008 12:58:17 pm

The method Lewis & Rieman suggest is essentially a fleshed out version of the method described in class with two very important emphases: it focuses on the evolution of the product over iterations and the inclusion of the user into the design process.

Generic functionality should definitely be left out where it impedes more important features, does not make sense, and/or obfuscates the interface abstraction. Otherwise, for familiarity purposes, it should be put in. Of course, this is subject to change given the opinion of the user.

One thing I noticed was that the Lewis & Rieman process does not allow for very much innovation, due to its emphasis on sticking to familiar patterns. Replacing the step of copying existing paradigms with some brainstorming may foster better paradigms. Familiar may not always be better.

Daniel Markovich - Jan 24, 2008 01:17:20 pm

The Lewis & Rieman design cycle is very similar to the three step design cycle that we learned in class (design, develop, test). One of the other very important steps in their cycle that was not talked about in class is the "Track the Design" step. Although a product might already be finished and distributed to users, it is very important that you continue to get feedback from them. With feedback from the "real" users, future revisions of the application can be released fixing missed problems, new or better ideas can be incorporated into other products, and similar mistakes can be avoided in the future.

Lita Cho - Jan 24, 2008 12:45:17 pm

Lewis and Rieman went over the same process - design, prototype, evaluate - as we did in class. However, they went more in dept into the design process, making sure to keep the user in mind as well as the task at hand. Lewis and Rieman also go into plagiarize other designs and suggest conforming to the norm for the ease of the user. I do believe that following the general convention rather than creating a more efficient method creates ease for the user, since people like familiarity. However, this doesn't really promote change or innovation. I believe a design that is completely different from the norm can still be easily accessible to users.

I really enjoyed the idea of having fun with brainstorming in Kelly's article. Kelly claimed that the brain needs to warm up and bring out some silly ideas to get the creative juices flowing. Also I agree with Kelly recommendation with building on top of ideas and coming up with different problem questions in order to keep the brainstorm flowing. I also believe that making the brainstorming physical and visual helps with the out-of-the-box thinking. I would have liked some examples of good problem questions or warm-up equations to start of a brainstorm.

Randy Pang - Jan 24, 2008 01:33:23 pm

Lewis and Rieman simply expand the three stage cycle described in class into more detailed steps. For example, "design" is expanded to the following steps: figure out who's going to use the system to do what; choose representative tasks for task-centered design; plagiarize; rough out a design.

I don't believe that a system should always include generic features, but I believe it may be benificial. This goes along with Lewis and Rieman's first design step, in which you "figure out who's going to use the system to do what." If I know for sure in advance my users are not going to use a specific feature, then it will be of no use to include extraneous features. However, our foresight is never perfect, so in leaving out generic features you risk the loss of a need arising for those features or possibly in leaving out a user that you didn't predict using your interface. At that point, it becomes merely a predictive cost/benefit analysis of the ammount of work neccesary to implement the features versus the possibility of their usefulness.

Andrei Scheinkman - Jan 24, 2008 01:18:25 pm

Kelly argues that a problem statement for brainstormers should be tangible without being too narrow. As an example, he suggests "helping bike commuters to drink coffee without spilling it or burning their tongues." This problem statement fits well with Lewis and Rieman's advice that designers focus on representative tasks that the system is meant to accomplish.

Since the representative tasks from the task-centered design process seem to satisfy Kelly's criteria for good brainstormer problem statements, perhaps Lewis and Rieman's process could be modified by adding a step after the representative tasks are chosen in which the tasks become problem statements for short brainstorming sessions.

Jiahan Jiang - Jan 24, 2008 01:43:21 pm

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

Lewi & Rieman's design cycle is much more in-depth and incremental in comparison to the design, prototype, and evaluate model. It includes works that must be done before the designing stage such as determining the user and collecting specs; it is also more iterative in its implementation and testing steps, which is a more realistic approach.

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 don't believe that is always true, it really depends on the specific product functionality, the particular customers and their needs, as well as the time and resources that's available.

Raymond Planthold - Jan 24, 2008 01:41:49 pm

I don't think the Kelley reading presents contrasting ideas to those in the L&R reading, so much as going into detail for one part of the design process, namely coming up with ideas. The L&R, on the other hand, is an overview of the entire process, including implementation.

As far as "generic features" are concerned, I find the example of cut and paste a bit odd, at least as it is presented in the article. Accepting a mouse click probably isn't part of a database program's "main functionality" either, but it is an integral part of the basic interface (a computer) that the program is targeted towards. Similarly, cut and paste is an integral part of text display and entry on computers, so there shouldn't be any question of whether to include it or not. Maybe that's their point, but if so, they could have expressed it more clearly.

Also, just as a nitpick, I really didn't like Kelley's use of "Brainstormer." I kept thinking he was referring to a person, i.e. someone who employs brainstorming well. In a way, it makes me less likely to put stock in what he has to say about interface design, since he has taken a common element with an established meaning (the "-er" suffix) and changing it for no good reason that I can see.

Jun Kang Chin - Jan 24, 2008 01:48:22 pm

Lewis & Rieman augments to the three phase model an emphasis on considering user tasks and emulating successful interfaces during the design process. They also mention that designers need to take into account the habits of its users, for example frequently used keys or conventions, while emulating other interfaces. Hence they should implement the generic features user expect in the first version of the interface, but should be removed if user-evaluation studies show that they're relatively unused. However, if the interface is meant to be heavily optimized, and the additional features will affect performance and user satisfaction, then those features shouldn't be implemented.

Mike Ross - Jan 24, 2008 02:15:11 pm

Lewis and Rieman definitely outline a more fleshed out system of development, but I don't think it prevents the use of any of the ideas discussed by Kelley, as some have suggested. Kelley's message was about finding a the best solution to an obstacle, not about the entire design process. The task based approach outlines a method of designing and implementing an interface, and it seems brainstorms would be critical in developing improved and novel designs. The goal is not to end up with a bunch of wild ideas, the point is to come up with an idea that works better than any other and might be even more intuitive than existing products, and if unconventional ideas aren't necessarily always the solution, they can be stepping stones for getting there.

As for whether or not generic features should always be there, I know I'm always annoyed when things like cut & paste are missing, but I think depending on the project, as long as it's not a huge complaint from testers, they can be sacrificed if you can implement them within budget.

Zhihui Zhang - Jan 24, 2008 02:20:50 pm

The L&R design cycle and the three stage design, prototype, evaluate cycle both follow a similar progression of planning out an initial design, producing a workable (although not necessarily fully working) model and then evaluating and improving upon the model in a series of iterations. L&R highly encourages the designer to view the project from the user’s perspective, such as by analyzing other possible products the user might use to look for common interfaces that the user might have been accustomed to. L&R further points out that although a design decision might be more ‘efficient’, it might make more sense to instead go with what the user already knows and is familiar with. Furthermore, after the initial design & prototyping, it is important to gather feedback from your perspective users. One might observe a user as he walks through a typical use case to determine if too much time is spent to accomplish a relatively simple and common task. After revaluating the design, further improvements are made, as L&R seems to suggest a somewhat agile style of development. As L&R points out, the purpose of testing is “not to prove the interface, but to improve it.” Kelly further expounds upon the process by providing a technique to get the ‘creative juices flowing’ so to speak. He emphasizes the importance of a good brainstorming session to generate ideas and suggests techniques such as having hands on materials (such as Styrofoam) to aid in the design process.

In terms of L&R’s suggestion that a system should include features that users expect even when these features don't play an important role in the system's functionality, I think it is highly dependent on the target user and the functionality of the application in question. For example, if the application is very field specific and existing applications in that field all follow the same convention it might be a good idea to include those features that the user has come to expect. However, if adding such features detracts from the application’s original purpose, then such features should be put off.

EricChung - Jan 24, 2008 02:17:25 pm

To answer the first question, L&R's list of things to do is basically the three stage cycle except with more specific instructions on what to do in each stage, with an explicit step of "iterate". Secondly, it is probably almost always good to have things like cut and paste functions in applications made. However, I can imagine in certain instances where a generic function is never used (such as in an application where there's only read-only functions and paste is somehow included).

Harendra Guturu - Jan 24, 2008 02:23:23 pm

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

The Lewis and Rieman cycle (LRC) is similar to the three stage cycle describe in class, but it has steps that can be classified under one of the three steps from the other cycle. The first 5 steps from the LRC can be placed under the design portion of the 3 stage cycle. The prototyping from the LRC falls under prototyping in the 3-part cycle. The evaluate portion of the 3 stage cycle nests the remainder of the LRC. The LRC does seem to include future modifications besides the initial release when compared to the 3 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?

No, I do not think this is always true. Some times including generic features may get in the way of making critical features more accessible to the user. For example, a lot of password entry boxes do not allow copy and paste to prevent the password from being copied to clipboard.

Max Preston - Jan 24, 2008 02:45:21 pm

I had a somewhat surprising realization after reading that article about brainstorming. Specifically, I haven't once had a brainstorming session this entire time I've been at Berkeley. If brainstorming is such an important skill, shouldn't we do things like that in discussion sections? Really, discussion sections tend to be more like recap lectures for people who couldn't figure things out the first time. There is normally little if any discussion involved. Brainstorming or other fun activities could also likely be integrated into lectures. Really, I'm tired of every class being taught the exact same way. Switching things up a little could have extremely positive results.

Jesse Albini - Jan 24, 2008 02:52:00 pm

The design cycle offered by Lewis and Rieman strongly echo the cycle presented in class. Each stage (design, prototype, evaluate) has been expanded into many individual steps. This expansion makes the cycle less abstract and more like a step-by-step protocol to follow.

L&R's suggestion to include generic features infer that a familiar environment is more important than an efficient environment. I agree with the general platitude, but in some cases, specialization should take precedence over uniformity. Also, while familiar interfaces may be the best for pleasing much of the general public, they stifle the evolution of new creative UI designs and encourage the preservation of useless UI artifacts.

Timothy Edgar - Jan 24, 2008 02:46:08 pm

Lewis and Reiman present a rather similar process to the model discussed in class. It follows designing, prototying and evaluating. It's a lot more rigid in defining goals and structuring the process than the more high level model discussed in class but fundamentally is the same thing. You start off with a goal to accomplish with a design, and through feedback you improve it. It keeps the cycle in mind for the implementation of the UI as they advocate high modularity. Standards change often and the UI ought to be flexible to adapt with time. While the cycle may "stop" when it is released, the way it has been built and the interaction with customer feedback creates a higher level cycle for the next version.

Lewis and Reiman present an idea of plagiarizing common components. While it is good to start off on the shoulders of others, it seems every few years there are major leaps in UI thought. Disruptive technologies are common and perhaps are necessary to break the mold of being familiar with a previous UI concept. The simplicity of google and the ribbon of office are two concepts that really aren't based off prior thought (perhaps they weren't the first who created it, however they differed significantly). If 90% of the functionality of the UI can be understood within the first 10 minutes, I believe it's worth taking the risk of introducing new ideas. It's a matter of balancing improved functionality with time to learn the functionality.

Lastly, not all UI designs are based upon functionality. Some have other goals in mind, where it might be to have the most ad click-throughs on a website for example.

David Jacobs - Jan 25, 2008 08:45:39 pm

Lewis and Rieman's suggested design process is essentially a fleshed out version of the three step cycle described in class. Stages 1-5 of Lewis and Rieman's process correspond to design, while stage 6 maps to our prototype step, and stages 7 and 8 match up with evaluation. Though Lewis and Rieman also include additional steps for creating the final product and updating it, these steps are really just extensions of the prototyping and evaluation stages this time being performed with real products. Given that the two approaches are roughly equivalent, I think that the simplicity of our three step cycle is preferable. The complicated stage names in Lewis and Rieman's article don't add enough descriptiveness to be worth the extra difficulty in remembering the process.

I wouldn't go so far as to say including generic interface features is always a good idea, but I think it more often helps than hurts. As Lewis and Rieman bring up, users (myself included) expect certain functionalities to be ubiquitous, such as cut and paste. The bonus of such a philosophy is that interface paradigms can grow beyond their originally intended domains. Initially, cut and paste really was only used for text editing applications. However, some clever designer decided that it might be interesting to include the same interface in non-text environments, such as image or file system manipulation. The result is a more consistent user experience. That said, if an additional, rarely used generic feature clutters an interface and makes it more difficult to perform normal tasks, it should be omitted.



[add comment]
Personal tools