The Design Cycle and Brainstorming
From CS160 User Interfaces Sp09
Lecture on January 26th, 2009
Readings
- The Task-Centered Design Process. Task-Centered User Interface Design. Chap 1. Lewis & Rieman
- The Perfect Brainstorm. The Art of Innovation. Kelley.
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 - Jan 20, 2009 11:17:06 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?
Nicholas Kong - Jan 20, 2009 11:56:16 pm
Lewis and Rieman's approach and Kelley's approach are two quite different design processes. In task-centered design, the designer works from a concrete set of operations to create an interface, iterating with user feedback. In Kelley's brainstorming approach, the designer starts with an overarching goal and generates ideas until a set of these ideas fulfills the necessary operations. As such, Lewis and Rieman's "plagiarize" step is slightly different than Kelley's "piggybacking" step: the "plagiarism" comes from appropriating interfaces that perform common operations, while "piggybacking" involves a refinement of a fellow brainstormer's idea. In what situations do you think one approach would be preferred over another?
Adam Kauk - Jan 21, 2009 07:44:01 pm
I think that the Lewis and Rieman product life-cycle description could be improved by intregrating Kelley's brainstorming process. The brainstorming step would go in between steps two and three of the Lewis and Rieman process (choosing tasks and plagiarizing). Once you know the tasks, that is the perfect time to brainstorm. After you brainstorm, when you figure out how you will innovate, you come back down to earth and figure out where you will be traditional (plagiarize). A product needs to have newness, or else no one will buy it, but it needs to fit with the stream of what has been happening, or else no one will understand it.
Jeffrey Patzer - Jan 21, 2009 11:23:57 pm
In response to Nicholas question I think that the situation seems to be the deciding factor for which method is used. The brainstorming method seems like a great strategy when starting from scratch on an idea or when trying to solve a problem during a process for which you have hit a road-block. The task-centered method offers excellent process structure though. I think it would be a good idea to have the task-centered method to help guide the design process and give it overall structure, then use brainstorming to solve issues (depending on their severity) as time goes on. Using a structured process coupled with cooperative problem solving environment would probably prove a good way to keep people on track but to also ensure the team stays able to communicate with one another effectively.
Chang Su - Jan 22, 2009 03:01:07 pm
The act of creative copying, be it called "plagiarizing" or "piggybacking", is certainly fundamental to the development of all human knowledge. But although the approaches by L & R and Kelley are similar, their motivation and objectives are quite different. L & R suggest referencing others' work so that our own work would comply with current convention. It will then be easier for users to learn and interact with the interface we design. Kelley, on the other hand, recommends exploring existing ideas first as this improves both the quantity and quality of the ideas we will formulate. Therefore, one seeks to conform and the other to innovate. They are both vital and there is no saying which is "better".
Sean Kim - Jan 22, 2009 08:33:01 pm
In the Lewis & Rieman design cycle, I think that the steps are categorized by four group;
- Analysis users and tasks
- to know how much users are used to any UI and make a task representive
- Plagiarize
- to get UI users already get used to use
- Iterate (rough design -> think,evaluate)
- Build UI, considered with Revision
- to start making a real UI, after iteration of rough-design
For getting more usability from UI, it needs to be more familiar to use(e.g. generic features)
Carol Chen - Jan 23, 2009 05:02:21 pm
Beyond the techniques that Kelley suggests for spurring creativitiy - numbering, getting physical, taking advantage of spatial memory - brainstorming groups can also get the juices flowing by throwing completely different concepts together and drawing ideas from the resulting juxtaposition. For example, if you are attempting to come up with a new product idea, have everyone in the group write words (verbs, nouns) on post-it notes, collect the post-it notes, pick two randomly, and start throwing out ideas that connect the words on the notes. Chances are that the two words picked have not been considered together before, and interesting and wild ideas will emerge.
As for as whether a system should always include generic features that users expect, I think it depends on the likelihood that the user will come to rely on those features when using the new system. 'Cut and paste' and 'undo' are both features that users modifying any type of content will appreciate reliably having on hand; if these features are absent, the users will be thrown for a loop. A feature that is perhaps less critical would be the function key on Macintosh computers that gives users a view of a calculator, the weather, and the current time. This is a OS-specific feature that, though very handy on a Mac, would not be realistically expected to exist on other platforms.
Saung Li - Jan 23, 2009 05:18:46 pm
Some generic features that users may expect do not have to be included in the system if those features are not important or less used, such as the windows key. Users for a different system most likely wouldn't expect this key, as this function isn't needed or can be done through other methods that are easier or don't take too much more time, such as simply clicking the start menu. Though the L&R and Kelley approaches are different, they can be integrated to create an innovative yet structured design process. After task and user analysis and an establishment of overarching goals, brainstorming can be used to drive the designing to the prototype phase. Brainstorming can be used during each iteration step as well to deal with any issues brought up. How else could combining the two processes help the design cycle?
Kevin Huey - Jan 23, 2009 08:00:36 pm
While building and tracking designs in the L&R approach is a great method, designers could save themselves some time on user ideas by polling the public beforehand on new features that they would love to have in an upcoming product. Although many ideas will be outlandish, some will have merit and can be applied to existing paradigms as an update. Designers should still continue to create their own ideas, but also integrate them with user ideas before building a mock-up. Once the design is ready for testing, all types of users should be targeted in order to provide the best product for the widest range of customers. A designer could test his/her own product as a user as well, but that may be a waste of time because of direct familiarity with the design.
Gregory Leshner - Jan 23, 2009 11:39:44 pm
The Lewis & Rieman design cycle is really a detailed version of the summarized design, prototype and evaluate cycle that was described in class. The L&R process really breaks down each step and gives helpful approaches to this somewhat magical process of creation. One of the most interesting comments, and probably the one that will be least used, is videotaping the tests of actual users testing the design and subsequently analyzing the errors, comments, surprises, and “think-aloud statements” that were made. Videotaping uncovers many subtleties that often go unnoticed during the actual test as the designer’s minds are often consumed. In the real world, videotape also provides compelling substantiation to justify expenditures on future design changes to management. Somebody has to come up with the money … and they usually aren’t at the test.
Stephanie Shih - Jan 24, 2009 11:36:13 am
Lewis and Riemann mention including generic features that users will expect, even if they're not important. In other words, they're implying that familiarity should take precedent over efficiency. Suang mentions above the use of the Windows key, which for Windows users its sole purpose is to open the start menu (which can also be accessed using the mouse and clicking. it is, incidentally, also slower to do the latter). Many familiar keyboard shortcuts are often not necessary or important, but nonetheless should still be kept. The only case where this shouldn't be the case is when the relevant features are so outdated that there are other better and easier methods that the client user can be weaned onto to replace said features.
Nalditya Kusuma - Jan 24, 2009 04:34:10 pm
User Interface is the most crucial part of most programs. Imagine a sophisticated program that can do lots of things but does not have a good interface; users might end up not putting any interest on it because they think the software is shady and not capable of doing anything. Thus the company which sponsors the program might not get enough sale to cover the expenses spent to build the software, and the development of the company is hold back--and if you're the programmer, you might lose your job :(
The L&R provides some suggestions in overcoming this problem. Some important points from the readings are: [1] Knowing the needs of the users ; [2] build an interface that users are familiar with ; [3] Create designs and prototypes ; [4] Get as many feedbacks as possible ; [5] Maintain communications b/t developers, users, and both. The L&R Reading also suggests that every programmer should be wary of rapid changes during development; some specifications might become obsolete after some time and some new features might have to be added to meet new users' expectations.
Kelly's "The Perfect Brainstorm" also gives suggestions on how to get fantastics ideas to overcome problems through brainstorming. The methods that appears on the reading can be used by the GUI team to design front-end prototypes of the software your company is building. Although some of the methods listed might not be surprising and is obvious, they are the most basic rules that brainstormers should be aware and exercise in every session. Some of these methods are: [1] Be super-focus on the issues raised ; [2] Keep track and number the ideas ; [3] If stuck, then go to the next topic that's related and go back later ; [4] Put the ideas on a huge board/walls so everybody can see ; [5] Do some visual research (or other warm-ups) about the topic before the session.
Chris Lindsay - Jan 24, 2009 06:26:44 pm
Overall, Lewis and Rieman's task-centered design cycle is very similar to the three stage cycle described in class. The biggest difference is that the task you're designing for is much more specific in the task-centered design process. Instead of thinking about a very general task, such as word processing, one is thinking about a specific scenario, such as "transcribing a memo and sending it to a mailing list." This gives a much more concrete method to evaluate an interface. It's possible to simply try to execute the specific scenario, and see how easy and intuitive it is to do.
Although users will often expect certain generic features, this doesn't mean that it's appropriate to include these features in every situation. Consider for example drafting an email in an email application, and the "Save As..." feature. This is a generic feature that people expect to find in the File menu. However, allowing people to save drafts of their emails with whatever name they want might not be the best UI. It might be better design to always save emails named by the subject of the email, even if this removes a feature that the user might expect to find.
Yin-Zen "Johnny" Hwang - Jan 24, 2009 05:33:09 pm
L&R seems to have simply subdivided the three stages into many more stages. For example, under Design falls:
- figure out who's going to use the system to do what
- choose representative tasks for task-centered design
- plagiarize
under Prototype falls:
- rough out a design
- think about it
- create a mock-up or prototype
while the rest are evaluation stages:
- test it with users
- iterate
- build it
- track it
- change it
So it's pretty much a difference of opinion between lumpers and splitters, as my biology textbook puts it.
discussion question 2:
I think that this is just to keep things consistent with the OS or whatever that the software is built for. To me, the most important thing about UI design is to keep things simple. The less the user has to consciously learn about the UI, the simpler it is to use, and consistency helps keep the learning curve shallow.
As for brainstorming, I like it when we do that kind of stuff in discussion. That would be a great way to segue into projects and stuff like that.
Meiying Li - Jan 24, 2009 07:56:12 pm
Lewis & Rieman design cycle can be divided into three groups which correspond to the three stage cycle described in class: Design =>
- figure out who's going to use the system to do what
- choose representative tasks for task-centered design
- plagiarize
- rough out a design
- think about it
Prototype =>
- create a mock-up or prototype
Evaluate =>
- test it with users
From personal experience, I have seen some very-well-written software (in terms of both quantity and quality of its functionalities) lost their market to their competitive but not-so-well-written peers. For example, when I started using online IM at seventh grade, China's IM market is basically dominated by two IMs: OICQ and NetSprite. I personally preferred NetSprite because it takes less system resource to run and provides easier-to-use functionalities (I don't remember the details now, though). In my own definition IM is used for chatting and I hate IMs that take much system resource providing other services like online games, computer generated profile picture etc (especially while these services are not free). But OICQ finally took the market (and became QQ when ICQ suited it), with the help of generic features like customizable emotions, online games and QQ show (a animated figure that represents its user and the user can buy and put clothes and makeups on it). Although as a CS student I personally like software that have fewer bugs and take less system resource, experience has proven that most users care about the software's performance even less than the appearance of it. Generic features might be just a complement of the main functionality, but usually they are the ones that actually win users, especially non-computer-expert users.
Mark Dhillon - Jan 24, 2009 08:22:03 pm
Something that instantly jumped out at me from the Lewis and Rieman article was the initial need for task and user analysis. The authors suggest that the only truly effective way of designing a system is to sit down with the users and hammer out all of their needs in regards to the product. It has been my (limited) experience that this is all too implausible. Unless one is funded by his or herself and has no market deadline to meet, I can't envision a situation where this can happen. Thankfully, the authors seem to agree with me, and say that "Effective task and user analysis requires close personal contact between members of the design team and the people who will actually be using the system. Both ends of this link can be difficult to achieve." I imagine that when the initial design of the product by the developers occurs, then a time with potential users can be commissioned, but not at every step along the way.
Shoeb Omar - Jan 24, 2009 08:49:33 pm
I think that the L&R design cycle is very similar to the three stage cycle described in class, however its almost like the three stage cycle done with constant feedback and thought paid to the users. The three stage cycle is really simple and doesn't really focus on user input until the iteration phase. The entire purpose of the L&R task oriented approach, however, is to design things from a user's standpoint from the very beginning. Although keeping the user's in mind when designing may be a given in the three stage cycle, it is not as firmly grounded in an actual user's view. For example, the L&R approach stresses founding the entire interface on a base that the user may already be familiar with--the plagiarize phase. By doing this, the users are centered in an environment they already may be familiar with, not a contrived one by a designer. By then developing an interface from a base, user's gain their task's functionality without having to learn too much, making the process seamless. However, L&R also 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. Although I think this is mainly true, I do think there is a line to be drawn. Standard features should not be included if their inclusion will cause more confusion that it is worth. For example, including a copy paste feature in a media player that copies the title of the currently playing track is not intuitive. When pressing "copy," a user will not be sure what they're getting. They might be trying to copy the entire video, and end up confused when they only get the title. Thus, features should only be included when their inclusion enhances and does not inhibit the system's functionality and intuitiveness.
Timothy Yung - Jan 25, 2009 03:43:56 am
The Lewis & Rieman design process seems to be a particular adaptation of the more general three (design, prototype, evaluate) stage cycle discussed in class. I stress that the Lewis & Rieman design process is a process, rather than a cycle, because it seems to be less "agile" and more "waterfall". The "cycle" portion of the Lewis & Rieman design process occurs only at the iterative step, allowing more thinking to be done separately from the rest of the process and thus allowing managers to more easily make business decisions on whether or not to continue iterating. The three stage cycle is more versatile and allows an entire project to be completely rethought and redesigned (i.e. more open-minded). There's advantages and disadvantages to both and which should be used depends on the business model and needs of the design team.
The Lewis & Rieman design process also specifies the way in which "evaluation" occurs after the product has launched (i.e. keeping in contact with the users to revise the design), whereas the three stage cycle generalizes the life of product design after launch as an evaluation in another iteration of the cycle.
Finally, the Lewis & Rieman design process focuses more on creating a user interface that has a high likelihood for success, whereas Kelley's brainstorming process seems more focused on introducing innovative ideas that would go against Lewis & Rieman's "plagiarize" step. I do not believe that generic features that don't play an important role should always be included. Generic features that users come to expect but play no important should be present only if their absence would confuse users or make it more difficult for them to use the design. Like many modern designers, I believe that simplicity tends to lend to ease-of-use. In general, if its presence does not add clutter to the design (that may complicate the experience for users), then the generic feature should be included.
Chunwei Lai - Jan 25, 2009 12:20:31 pm
The Lewis and Rieman favors working out the details of the project with the user before the actual building/implementation occurs. Similar to the three stage cycle but with focus on the user's feedback to insure that the design stays true to what the users want. In addition to feedback from the users, the designers should also try to understand from the perspective of the users to insure that features not explicitly planned out can be implemented as well.
There are sets of generic features that one comes to expect from using an application - such as highlighting text and being able to copy it or keyboard shortcuts. Typically these generic features facilitate the use of the program and should be implemented. However, one should not implement so much feature that the application is bloated with countless features that have nothing to do with the purpose of the application.
Henry Sanjaya - Jan 25, 2009 06:13:21 pm
L&R's design cycle is basically the same three-step design cycle as described in the class. The first 5 steps in L&R processes are the steps that would combine together to make up for the design process. 'Plagiarize' is an important step in which no illegal moves are made, but this step is to follow the previous conventions so that resources are saved. Why? Because if a program is created with a particular characteristic, that means that the program has tested that it is one of the most efficient ways in making the program successful. Instead of testing and wasting resources to get the same fact, a new program that is going to be created might as well take the already accepted template and start improving from there.
The prototyping step is the same in L&R where prototypes are made to mostly represent the representative tasks and tested by users. The evaluating step means that the test conducted by the user must be then evaluated to gauge the performance of the interface and modifications must be made to improve the interface. This is pretty much the last 5 steps in L&R.
The emphasis in L&R is in the prototyping and evaluating step, where changes are constantly made using feedback from real-live testing from users. This is a good way, but very resource-consuming. Kelly's extract suggests that the process of brainstorming and thinking about the problem is also important because it may lead to more creative ideas and less resource consumed.
Including generic features that don't play an important role is not always true. As far as I'm concerned personally, I think the purpose of an interface is to make everything as simple as possible and as user-friendly as possible, so a few tutorials here and there about the generic issues would probably be nice. But when it gets too much and too much unimportant functions are being tutored, users may get annoyed and may start to wonder what the real purpose of the created program is. A few tutorials certainly would not hurt, but tutorials should still largely be focused on the main function of the program.
Rohan Dhaimade - Jan 25, 2009 04:32:21 pm
L&R design cycle is very similar to the one in lecture. Both cycles require user feedback, both require a design and both are required in every stage of the cycle constantly updating and improving on the design. L&R though goes into more specifics on how to set and define the goals. By creating a task system, you create a clear checklist of goals and narrow down the features that you would want implemented in the system. It also mentions that you should build on previous designs, "plagarize" in order to improve user usability.
I don't think that features that users expect should always there be. First of all, if the design really does have nothing to do with the program and would take considerable effort then it might not be worth the cost. If the implementation is not complicated and doesn't make things too difficult then it would be fine to implement it. It depends on a case by case basis on how hard it is to implemented generic features.
David Jiang - Jan 25, 2009 06:14:14 pm
The Lewis & Rieman design cycle is very similar to the one discussed in class, but the Lewis & Rieman seems to be a lot more detailed. Yes, I think 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. For example, shortcut keys for tabs (ctrl+tab to switch), I feel, should always be included because so many users are used to using them on a regular basis. If it doesn't hurt to add the feature and if it doesn't take up an enormous amount of time to implement, then I say, add it on. Some users might not even use it, but some might feel hindered without such features.
Chris Thompson - Jan 25, 2009 08:13:25 pm
It seems to me that the L&R approach is geared toward usability whereas the Kelley method is focused on innovation. Both are important aspects to a project -- if there's no innovation, then the product probably shouldn't be made, but if it's too unconventional to use then only the most dedicated of individuals will stick with it. So the question then seems to become when to use each method. Brainstorming seems like an important way of figuring out what you want to do, and solving specific, unique problems that may occur. But once a clear goal has been brainstormed, then I think the task-oriented design is a better choice for reaching that goal. As for plagiarizing, I think that it should be done to a reasonable extent if you're working on the conventional aspects of your project, but when working on the creative or unique aspects of the design, piggybacking allows for greater improvement and innovation.
Denise Ngai - Jan 25, 2009 08:50:05 pm
The Lewis and Rieman design cycle is very similar to the three stage (design, prototype, evaluate) cycle described in class. In fact, it follows this three stage cycle rather closely. In the reading, under the "design" category is figuring out who's going to use the system to do what, choosing representative tasks, plagiarize to get basic design features that people will be familiar with, rough out the design (on paper), and thinking about the design. In the "prototype" category, Lewis and Rieman specifically say to create a mock-up or prototype. They then proceed to suggest "evaluating" the design by testing it with users, iterating, building the actual design, and tracking the design for further evaluation. Through this evaluation process, the designer can then change the design based on the results. Although Lewis and Rieman describe their cycle in more parts, it is quite clear that it basically simplifies into the three stage cycle mentioned in class.
Timofey Titov - Jan 25, 2009 08:56:13 pm
L&R gives a reason to why iteration is required. If there is a change in one component, the whole user experience changes and you have to reintegrate everything.
I believe generic features should always be included where they are expected. L&R's cycle is centered around interface and audience. If a user is familiar with such features, then they should be included in order to avoid contrast. This is more of a conservative approach to interfaces.
Ultimately what counts in ideas is the quality. In the excerpt Kelley does not emphasize the distinction between idea generation and evaluation. I believe one should adhere to such discipline. Research shows that individual brainstorming before pooling of ideas brings better results than just group brainstorming. Mindmapping would be a perfect technique to apply here as well in order to keep brainstorming focused, and extend or abandon certain "trains of thought". Alan Kay mentions in "Doing with Images Makes Symbols" (@1hr06min) that a point of view can make a crucial difference in how one solves a problem. This supports Kelley's rule of "getting physical" - more visualization will result in non-traditional solutions, because the right half of the brain, which is more subconscious, is involved.
Alan Young - Jan 25, 2009 09:01:01 pm
I feel that the Lewis & Rieman design cycle is essentially the Design, Prototype, Evaluate cycle described in class, only more detailed and breaking some phases of the cycle into smaller sizes. For example, "test it with users" and "iterate" are not explicitly said in the class cycle, but is implied by the Evaluate-Design connection. In addition, the Lewis & Rieman design cycle makes explicit some things that I believe were implied by the cycle described in class, such as: management decisions, costs/benefits of iterations, and whether specific usability objectives have been met to a level that may outweigh the costs of additional iterations. I think those implicit points is the result of taking a concept or idea from theory and applying it to a real world situation. Another important point to mention is that the Lewis & Rieman design cycle explicitly uses the task-centered design process rather than traditional processes that produce a general specification of a system. The cycle in our class gives no such specification. While Lewis & Rieman suggest that a system should include features that users expect even if those features don't play an important role, I feel that it is not always true because there are many situations where it will just not be practical or too costly for the time or resources to add unnecessary features, especially if there's an impending deadline. In addition, just because users expect features doesn't mean that those users would not appreciate a simpler system with the tradeoff of better performance or pricing.
Salman Rahman - Jan 25, 2009 10:49:40 pm
L & R present a very detailed implementation of the "design, prototype, iterate" scheme to UI design that we learned in class. If you look at the steps that are suggested in UI design by L & R, one finds that the 'design' step to have been broken up into many concrete steps. L & R's approach to UI design revolves around a task-centered design process where representative tasks are brainstormed and then implemented. Developing a solid list of the tasks gives the design process the structure and impetus to move forward into the prototyping phase because those tasks are real-world applications for the UI.
As to the question of whether familiar tasks should be implemented, i.e. cut / paste, when the function of such tasks is unnecessary, I believe that it should be done. If these familiar tasks are able to be carried out by the user, he or she will feel comfortable using the interface and will be more prone to using the application, rather than shying away from performing complex tasks.
Hari Ananth - Jan 25, 2009 11:49:32 pm
In answering the second discussion question, L&R 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, but I do not think this is always true. At this point, the designer is simply adding features for the sake of adherence, not for of functionality. These features, rather than make the design more usable, may in fact cluster the design, be redundant, or simply be not wanted by the user. I enjoyed the Kelley reading because it provides some contrary-to-belief suggestions to the design process--ideas that are not included in our 3-step process or the L&R technique. It seems that a combination of the systematic approach we see in the 3-step/L&R process could be improved with Kelley's ideas to perhaps produce a better design.
Victor Lum - Jan 26, 2009 12:15:32 am
I think that Lewis & Rieman's idea for plagiarizing is a pretty good way to allow users to quickly learn to use something new. If several features are there that users have come to expect or are in similar products, people can just jump right in, doing things the way they’ve always done them. There’s no need for any complex tutorial or anything. But constantly doing things one way can hamper creativity and stifle innovation. It may even prevent people from coming up with better ways of doing things. For example, many video games stick to certain genres and the conventions that they entail, allowing players to quickly pick them up and play, but this has created a lot of games that feel just like rehashes of games we’ve already played before.
Eric Hernandez - Jan 26, 2009 12:13:07 am
The three stage development cycle is essentially a generalization of the L&R process for development. Certain steps the L&R describe, such as plagiarism, are really just elaborating on one of the three general development steps by including more real-world knowledge on how to efficiently create/design systems. In regard to always including generic features, well, there is nearly always an exception to the rule. For example, a very simple application does not need to support the standard "F1 Help" button if it has only one well understood feature.
Michael Cao - Jan 26, 2009 01:50:42 am
After doing the reading, it's pretty easy to see how the Lewis & Rieman design cycle is very similar to the three stage cycle described in class. The L&R cycle is just a much more detailed version of the design, prototype, evaluate cycle from class. The L&R cycle steps included in the design cycle are to figure out who's going to use the system to do what, choose representative tasks for task-centered design, plagiarize, rough out a design, and thing about it. The L&R cycle step included in the prototype cycle is just the create a mock-up or prototype step. Finally the L&R cycle steps included in the evaluate cycle are everything else. This includes test it with users, iterate, build it, track it, and change it. Also I agree with L&R 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. But only if the feature doesn't somehow make the system more difficult to use. I feel that if users expect it, including the feature gives users the impression that the system is more complete and what they are used to. And if they feel like it is what they are used to, they'll be much more willing to use the system.
Cuong Ngo - Jan 26, 2009 02:00:01 am
Having read the chapter, I notice that Lewis & Rieman design cycle and the 3 stage cycle described in class both emphasize the very crucial step in user interface design: task analysis. That is, analyzing what tasks to be performed, then choosing some of them to be representative. However, one thing that the in-class design cycle didn't point out but Lewis & Rieman did is the continuous involvement of the users after the final product is delivered. For instance, tasks and users change over time, and thus designers needs to be aware of those changes in order to update the product accordingly. An example is the Ribbon interface that Microsoft introduced in Office 2007. Realizing how difficulty it is for a user to quickly format a word document, they grouped formatting buttons into ribbons such as text-formatting, aligning, object-inserting and so on.
I couldn't agree more with Lewis & Rieman suggestion on generic features that a system should always include. An example from the chapter is copy and paste. This feature might not be as important as others in the system. However, its usage frequency, say for a word processing application, is relatively high. Therefore, its inclusion is crucial as well.
Anatol Tsang - Jan 26, 2009 02:31:50 am
At a bird-level view, the task-centered design process is identical to the design-prototype-evaluate process discussed in class. Both focus on a problem, develop a solution, and repeat testing cycles to improve upon the solution. As for including user-expected features in a design, it all depends on cost-benefit. It seems that user-expected features should be put into a design most of the time. However, if the implementation of a feature is at some huge cost, a loss in efficiency for instance, then maybe the feature should be left out. Sometimes, the user may have unrealistic expectations.
To comment on Professor Aggrawala's comment on new ideas, I think that coming up with new ideas is a matter of luck that could be improved with practice. Building on others' ideas (including that of nature) is the best way to come up with things (especially for people who like to follow rules and formulas). However, some of us are given the talent of being able to think of ideas very well, and it seems like something that can only come with talent or practice.
Are there other techniques, beyond those that Kelley discusses, to help people generate new, creative ideas? Free-writing: This technique is used in the humanities to pump the creative juices. By continuously writing in a stream of consciousness style for a minute or two, you literally force yourself to start/keep thinking. One idea then leads to another, and by the end of it, the number/quality of the ideas you come up with will surprise you. Sometimes it is good to think individually before you discuss with the group so that you don't get swayed by other ideas before you even think of some of your own. Questioning: Sometimes ideas arise as responses to specific questions. Though a concrete issue may have been identified at the start of the brainstorm, addressing it from varying perspectives will facilitate the generation of new ideas. We might even consider ideas as responses to questions a sort of piggybacking.
Szu-Chun Mao - Jan 26, 2009 02:48:53 am
L&R design cycle seems to be an extension of the design-prototype-evaluate cycle described during class. It contradicts to the theory of traditional waterfall design. Task-Centered design process starts from focusing on what the system can do from users’ perspective. Then Lewis and Rieman suggest plagiarizing as a start to form a solid base in design stage. It seems like a reasonable and efficient way to approach the project during design stage; however some user interface designs have superior outcomes by not plagiarizing. Similarly, a system should not always include generic features that users expect even when these features are not that important in the system’s functionality. In contrast, I think Kelley’s approach would be more suitable way to start projects in today’s completive world.
Anjana Dasu - Jan 26, 2009 02:50:11 am
Are there other techniques, beyond those that Kelley discusses, to help people generate new, creative ideas? (Professor Agrawala's Question)
Free-writing: This technique is used in the humanities to pump the creative juices. By continuously writing in a stream of consciousness style for a minute or two, you literally force yourself to start/keep thinking. One idea then leads to another, and by the end of it, the number/quality of the ideas you come up with will surprise you. Sometimes it is good to think individually before you discuss with the group so that you don't get swayed by other ideas before you even think of some of your own.
Questioning: Sometimes ideas arise as responses to specific questions. Though a concrete issue may have been identified at the start of the brainstorm, addressing it from varying perspectives will facilitate the generation of new ideas. We might even consider ideas as responses to questions a sort of piggybacking.
David Burban - Jan 26, 2009 02:39:50 am
The L&R design cycle is more complete and thorough than the one described in class. The description of the cycle in class starts off with one's own design, whereas the L&R cycle has at least four more stages before the design is even put on paper. L&R encourages the designer to look at other people's work and consider the representative tasks, and make those easy. L&R delves deeper into the design process even after the design has been put on paper; L&R wants the designer to test the design with users, make adjustments, test it again for as long as needed, and only then evaluate the design with the published program. Essentially, the L&R cycle is not a "complete cycle", it is a process that has a cycle within itself. Even though the L&R design cycle is more complete than generic cycle we learned in class, both are strikingly similar in the goals and ways of achieving the holy grail - a well functioning user interface that is tailored towards its customers.
The statement to leave generic features cannot be always true. For instance, if someone has written a unique piece of javascript code on her or her website, it is in the author's best interest to disable right click functionality for the site. Of course right clicking on a website to either save pictures or view the code is a generic feature that users expect from browsers on all operating systems.
Brian Jue - Jan 26, 2009 02:41:15 am
I think to a large extent a system should always include generic features like Lewis and Rieman suggest. I can see how there could be some outlier cases where it might be beneficial not to include some feature, like having a save as feature for email as someone mentioned above, but for the vast majority of common sense cases, users expect features to be there and for the most part have a legitimate expectation. I've experienced the frustration of searching for some generic feature that should be there only to find that its not after some detailed searching and googling. It makes sense to include these features because designers may not always foresee all the ways users could use features, even if its not essential to a system's functionality. It likely doesn't cause to much a problem to include it, but it could turn out to be very useful to some subset of users. Since the users are the ones using system, it probably is better to err on the side of caution and include the feature.
Ling Chen - Jan 26, 2009 03:19:03 am
I think after reading through the article, we can all agree that the Lewis & Rieman design cycle is really a more detailed description of the "Design-Prototype-Evaluate" cycle mentioned in class. This approach is very much task centered and emphasizes on the iteration process. It focuses a lot on what the users want and how they would be using the system. That's why L&R believed that we should test design with users (analyze and get important clues for errors), fix the problems (without compromising functionality), and iterate the process till usability objectives are met.
One thing I thought was interesting on the Kelley article was the last way to kill a brainstormer: write down everything. I guess there is a difference between writing down your ideas and writing down literally EVERYTHING. Because then your attention does shift towards recording rather than innovating. I am not sure if there are other ways of coming up with new ideas other than brainstorming. Sometimes people could look at an old design and try to improve upon that. However, that still requires some forms of brainstorming, whether it's brainstorming by yourself or with others.
Adit Dalvi - Jan 26, 2009 03:48:21 am
The Lewis and Rieman cycle is practically the same as the cycle discussed in lecture with more details relating to real world scenarios. It focuses on a task centric design process and emphasizes the use of plagiarising i.e. building on previous designs to improve stability and usability. I do not agree that generic features that users expect should ALWAYS be included. However, I do feel that generic features should be given high priority because users have high expectations when they are comfortable using programs in a certain way and if resources are available, then generic features should be included to keep users comfortable.
Chao Michael Zhang - Jan 26, 2009 09:58:51 am
The Lewis and Rieman seems to be a more thorough way to accomplishing the same goals as the cycle described in class. The L&R method allows for rapid prototyping to quickly get designs out, and polishes the designs over time by allowing them to be thoroughly tested and improved (based on feedback) as it is being actually used. This seems to mirror different philosophies in software engineering, such as the waterfall method or extreme programming. While features that users expect should be included in the final product, including these features should not be given higher priority over developing the core features first.
Prahalika Reddy - Jan 26, 2009 03:50:58 am
Lewis and Rieman add a couple of steps in the brainstorming cycle. First, they suggest creating a standard for evaluating the product later by choosing representative tasks. Then they suggest, before starting your own designing, look for interfaces that already exist for products similar to yours. Then they enter the design, prototype, evaluate cycle we learned in class. However, between designing and prototyping, they suggest that you really think about the design and whether it will be good and cost-effective enough to build a prototype.
Lewis and Rieman suggest adding generic features that are expected. I believe this is true most of the time, but not always. If your product is lacking the basic features that the users have come to expect in other products, I think it's likely they won't want to switch products. Therefore it's good to put in expected features most of the time. However, if there aren't foreseeable situatons that the features would be used in, it might make them useless to put in.
Daniel Kinder - Jan 26, 2009 04:36:07 am
Lewis and Rieman mostly point out further details on the carrying out of an iterative design cycle. They include things like how to begin(focusing on the user group), when to move along to different things, and what to avoid. This is essentially the typical design cycle, but with details to guide those who want to design iteratively, but might be too perfectionist or uneasy about doing things differently.
Moonway Lin - Jan 26, 2009 04:40:33 am
L&R's design process is a more elaborate version of the three-stage cycle, with 11 steps instead of 3. However, the fundamental principles are exactly the same: the "plagiarize" and "think about it" steps are part of the design phase, while "creating a mock-up" and "testing the design" are part of the prototyping phase.
I agree with L&R about generic features when customer satisfaction is an important metric in the end product. Otherwise, if said features truly are not necessary, they could be replaced by alternative features or omitted entirely, and users will eventually adopt to the changes.
William Cho - Jan 26, 2009 02:16:33 am
The three-stage design cycle described in class just appears to be a simpler conception of the the task-centered design process described by Lewis and Rieman. I did appreciate the added detail in L&R's description of the cycle and the excerpt about how Kelley ran his brainstorming sessions and gave tips on what to do and what not to do. Although I do agree that using generic features for users is a good way to make an application more familiar, especially the often-used ones such as undo (ctrl+z), I feel that those features should not be included if they do not serve a clear-cut purpose in the application.
Phiroath Chan - Jan 26, 2009 05:52:27 am
I feel as if Lewis & Rieman focused mainly on the full design process itself from idea to creation. Whereas if you were to add Kelley into the the discussion, it focused more on the brainstorming and coming up with ideas and solutions. Kelley discussed the correct and incorrect ways of brainstorming for ideas and solutions and i think that can be incorporated into Lewis & Rieman's Task-Centered Design Process. Lewis & Rieman mainly hit on the what to do if you want to have a product or service be successful. If Kelley's "7 secrets of better brainstorming" is somehow incorporated into the Task-Centered Design Process then i feel one would have a more complete Task-Centered Design Process.
Matthew Can - Jan 26, 2009 06:04:15 am
The three stage cycle described in class is essentially a distilled version of the L&R design cycle. The L&R cycle is, at heart, the iterative three stage process, but with additional prep work and follow up before and after the design, prototype, evaluate loop. And there is no doubt that those additional stages are important. Since software is designed for humans to use, it's a valuable experience for the designer to communicate with will-be users of the software and to observe how they use their current software offerings. The research material forms the basis for the early design stage. And since most software goes through some sort of release cycle, the designer's job is not over once he finishes with one version or edition. He still has much to learn about the usability of his software from the market's criticism, and this information will feed back into the design process for the next version of the software.
Lewis and Rieman make a good point that users often want to see new software that behaves like the old software that they were used to, but a system should not include features from old software solely because users expect it. This is backwards thinking that slows down innovation by inhibiting the designer from reaching toward the edge of his creative horizons. Without the pressure of incorporating old features, a designer can freely explore unique UI possibilities that may yield higher levels of satisfaction to the user. Imagine how the iPhone would have turned out had Apple's designers felt they should make it more like a RAZR.
Shendy Kurnia - Jan 26, 2009 08:18:01 am
Even though Lewis & Rieman design cycle has more steps than Kelly's, basically, the two are the same. It is just that L&R's design pattern put more details on the design step and on the evaluate step. However, I think the difference between the two design cycles is that Kelly's design cycle asks more creativity, whereas L&R's method suggests to plagiarize.
Answering the second discussion question, I would say it is not always true that a system should include generic features that the users expect even when these features do not play an important rule. I think L&R gives an example of why newer version of Mac should include cut and paste because older Mac has it. In that case, it is true that cut and paste should be preserved. However, for some applications, one of the form of a change is to eliminate some feature. Otherwise, features and new features will always build up and clutter the system.
Jason Lo - Jan 26, 2009 04:47:03 am
The Lewis & Rieman is fairly similar to the three stage cycle described in class. The main difference is in target audience. In a more academic environment where innovation and new ideas are required, we don't look at what the user expects and instead focus on how to make improvements in interfaces that others may follow. The Lewis and Rieman chapter focuses on enterprise software created for an end user that is usually using the software for productivity reasons. I thought it was interesting in academia, time usually limits the projects, while in enterprise, management controls the time, limiting the number of iterations.
I agree with Lewis and Rieman that when making software for consumption by outside parties, sticking to what those people are familiar with is usually most successful. Unless significant savings in time or effort, or the software functionality is relatively new and untested, the learning curve for new interfaces often puts off users.
Teddy Allen Quan - Jan 26, 2009 09:02:47 am
The Lewis & Rieman design cycle compares to the 3 stage cycle in that they both follow proposed steps in designing an interface in a sequential manner. Both stress that it is necessary to spend more time with prototyping a rough design first, rather than spend hours hard-coding an interface only to find it's flaws and start over. Both also stress that testing is a key aspect and should be done repetitively, but both methods point out that no interface is perfect (there will always be some flaws).
In regards to whether a system should include generic features that users expect; it depends... Although, I agree that users will be more comfortable to use a pre-existing generic feature, I believe that if a proposed feature is more efficient than the pre-existing feature, it should be implemented in its place. Although this may introduce a slight learning curve, people will become accustom to new features eventually (it just takes time). Of course it is important to note that something really generic such as saving/opening will almost always be necessary.
Alexander Cho - Jan 26, 2009 09:56:48 am
Lewis and Rieman mentioned "plagiarizing" other common user interfaces that users are used to in order to make it faster for them to learn how to use the current product. This is an interesting idea that never really occurred to me, but I wonder how limiting this technique can be. To make a further connection with the Kelley article, I wonder what Kelley would have to say about integrating this "plagiarizing" as a requirement for the product during brainstorming, as he seems to promote allowing any wild idea during the brainstorming process. It would seem that "plagiarizing" would restrict the creative process for brainstorming, confined by many features already offered in products in circulation. Although Kelley suggests not imposing any restrictions during the brainstorming process, it seems that employees will wise up to suggesting anything too "far out" after seeing their ideas rejected during the evaluation stage. Perhaps lots of caffeinated and sugary energy drinks would assist in these brainstorming sessions.
Sum Sum Wong - Jan 26, 2009 10:00:27 am
I think Lewis & Rieman design cycle is just a more detailed version of the 3-stage (design, prototype, evaluate) cycle described in class. The L&R design cycle actually helps us to make good user interfaces by providing us hints on how should we design, prototype and evaluate rather than just give us a vague idea. An important idea introduced in L&R design cycle is "plagiarize", which is a good way for us to learn from other people's design. About the generic features, I actually agree with what L&R said. If we didn't include in our interface something that users always expect/get used to, users might feel uncomfortable about that although the function is not really that important. Also, it doesn't hurt to add those "traditional" functions in my opinion. By the way, I was impressed by the quote in Kelly's article. "The best way to get good idea is to get a lot of ideas -- Linus Pauling"
Shimul Sachdeva - Jan 26, 2009 10:20:15 am
The process described by Lewis and Reiman is similar to the the 3-stage process described in lecture in essence but explores greater depth into the design part. It delays the building of a prototype/mock-up and justifies the delay with respect to the effort that goes into prototyping. Although plagiarizing has been recognized as an essential part of the process, I feel there is always scope for innovation. In more concrete terms, the features of a UI can be broken down into very basic features and while the commonplace, fundamental features can be plagiarized, the rest can and perhaps should be left open to creativity.
Joseph Tsay - Jan 26, 2009 10:09:24 am
The Lewis & Rieman design cycle is pretty similar in general order to the three stage cycle described in class, but it breaks it down into more detail and adds a few key steps. The Lewis & Rieman design cycle adds a few planning steps to the design stage, in which the designer figures out specifically what is needed by whom, and lists out the representative tasks. This helps greatly later with deciding whether or not the system is complete. The L & R design cycle also stresses reusing aspects of similar programs that work well, basically going with the convention unless there is some extremely compelling reason not to do so. In the L & R cycle, instead of merely evaluating, the designer should test, improve, and then test again, continuing until a system that meets the standards is completed.
I think that a system should definitely include generic features that users expect. Certain features are seen as universal, such as copy/paste functionality and their hotkeys. Even in a Microsoft's calculator program, users are able to copy and paste the numbers being input and output with the ctrl x/c, ctrl v hotkeys, which although doesn't necessarily play an important role in the system's functionality, provide users a convenience they have come to expect.
Sean Ahrens - Jan 26, 2009 11:00:31 am
My curiousity arises to the subject of how task-centered design relates to user-centered design. After reading the article on task-centered design, I was left with the understanding that "tasks" in this process are derived from how the user uses the system (ie. what tasks they perform). In this sense, it seems to me that task-centered design does in fact originate with the "user". Given this line of thought, in what way is user-centered design different that task-centered design, and i suppose, in what way is it more "centered" on the user?
The brainstorming article was thought-provoking. I have read a number of articles on brainstorming, needfinding, and idea generation, and the strongest unique take away I got from this article was the "build and jump" technique. It seems to me like it could prove vital to continuing momentum in brainstorming sessions -- something that can be difficult for, for example, a student to do in student groups.
Hongcheng Chang - Jan 26, 2009 11:25:30 am
Lewis and Rieman discussed how important task-centered design process. The process is structured around specific tasks that the user will want to accomplish with the system being developed. These tasks are chosen early in the design effort, then used to raise issues about the design, to aid in making design decisions, and to evaluate the design as it is developed. The steps in the task-centered design process are as follows: Sometimes it is ok to steal ideas at the beginning, but first need to decide what to design. Rough out the design, test and iterate until satisfied.
Dwijgarg - Jan 26, 2009 11:26:41 am
In my opinion, L&R have devised a way that is basically more in-depth and thorough than the 3 cycle steps of design, prototype, and iterate. For design, L&R ask developers to look at other interfaces - plagiarize - and also point out who exactly will be using the interface as well. For the prototype step, L&R suggest that it is beneficial to rough out a sketch and then after thinking about what to keep, what to add, and what to take out, the developer should create a mock up of the design. These steps take care of the "prototype" step of the 3-step cycle discussed in class. The next steps in L&R of testing the design with users, iterating through it, and actually building and tracking the design make up the iterate step. L&R encourage the developer to keep "iterating" through testing and building the design, each time making the necessary changes to make the design better than its previous state.
Karl He - Jan 26, 2009 01:06:41 pm
1. The Lewis and Reiman article uses an 11-step process. However, it is essentially the same as the 3-step cycle. Steps 1-5 can be seen to correlate to the "Design" part of the 3 step cycle, step 6 correlates to the "Design" part of the cycle, and steps 7-11 correlate to the "Evaluate" part of the cycle. The Lewis and Reiman cycle simply fleshes out the general ideas, giving more details as to how each step should be done.
2. The only reason for generic features to exist is to give the user a sense of familiarity in an otherwise new UI. For example, when Microsoft introduced Internet Explorer 7 which lacked the File menu, they still built in the ability to access the menu because many uses may become lost in the new interface, then become frustrated and switch to a competitive browser. This is a habit that Microsoft built into its own userbase, however. Over time, they may be able to ween out the archaic UI elements. On the flip side, UI's should be more or less intuitive, if the "generic feature" is actually something that is quite natural for people to do without some sort of pre-training, it is probably something that should be kept in the UI.
Stephen Wu - Jan 26, 2009 02:29:54 pm
1. The L&R's process appears to me to be a more elaborate view of cycle discussed in class. Since the 3 step cycle iterates itself multiple times, it can cover the same ground as the L&R does over time. The 11 step process simply identifies steps during the 3 step process where the implementation has evolved to a certain point in time. Roughing out, prototyping, and final product are all parts of the evolution of the product, but not necessarily a very different activity for the group. Likewise, while sources of ideas may differ, the end process of analysis and idea generation is still repeated throughout the task-centered design process. The expanded ideas are helpful, but not fundamentally discrete.
2. Generic features as mentioned by my peers do help new users from familiarizing themselves with new iterations of a program or a competitor, but their inclusion should depend heavily on how cluttered the new interface is. If the functionability is there without including old features and the new features already require a complex work panel, the additional items may simply generate clutter and daunt the user. However, if the new interface does old things in a way that may be confusing and complex, including the generic might be beneficial, but if that is the case, why is the new interface implemented in the first place? It depends heavily on the context of the problem, but there are situations where including generic if less powerful elements for familiarity and times when their removal encourages end users to explore and learn the new interface.
Raymond Young - Jan 26, 2009 03:48:42 pm
I think the Lewis and Rieman task-centered method can be very useful, but alone it seems quite limited. What I mean by this is that it doesn't leave much potential for expansion or evolution of the initially proposed ideas and expectations of what tasks the system will perform. In general, the task-centered design could really be supplemented by a strong Kelley-style brainstormer to kick things off. Task-centered design as described in the article, in my opinion, allows an interface to be designed in a very focused way, but it concentrates on quite a static set of ideas. Might as well get the best of your ideas with a brainstormer and then go down the very focused task-centered design method. I think it's also really good to be constantly brainstorming in the back of your mind; checking not if new ideas conform to the initial set of tasks, but how the new idea will change the tasks the system has the potential to perform, either now or in some further, more evolved implementation down the road (one of your future iterations). A wider perspective is required than the task-centered design method as it stands alone; mainly by focusing not just upon a static list of tasks but on the dynamic evolution of your list of tasks, and how it maps across time.
Andrew Shu - Jan 27, 2009 02:16:02 am
All this talk of plagiarizing and piggybacking reminds me of obsessive artists/hobbyists. It reminds me of Renaissance Art, which has an element of conscious, symbolic interface with its users--the viewers. It reminds me of Renaissance art because of all the recycled Christian motifs used by the artists to tell the story as easily to the less educated audience. The detailed process described by Lewis, Rieman, and Kelley follows the process of these artists more closely than the typical programming project. The subjective nature of physical layouts and the abstract usage patterns rely on case-by-case analysis of the displayed subject, and the target audience. These Renaissance artists spent their lifetimes analyzing the psychology of putting people in groups of three, to arrange objects in triangles, single vanishing points, etc., all for the sake of rearranging good art to create a more powerful experience. This observation reflects what the L., R., and K., say: each project has its own circumstances. It is by focusing on the case-specific user needs (by plagiarizing from other artists, and by incrementally improving by running through the design cycles), that a good implementation of user interface comes about.
Aaron Hong - Jan 28, 2009 12:15:52 pm
"The Space Remembers" is one of the most interesting and initially enigmatic statement. It in itself is a User Interface design, a way to interface with the ideas generated during brainstorming. That exposes an interesting aspect of UI, which is exploiting how people naturally are. The idea of "The Space Remembers" uses our spatial memory and organization to better interact with the idea, not necessarily as a tool to "generate" ideas. Something pretty profound, that I would not have immediately thought of.
