The Design Cycle and Brainstorming
From CS160 User Interfaces Fa06
Lecture on Aug 30, 2006
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 - Aug 27, 2006 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?
Jerry Yu - Aug 27, 2006 10:36:05 pm
One might think of design processes as ways to navigate through a space of design possibilities while trying to find a design that satisfies certain goals. A task-centered approach, which emphasizes goals like designing for representative tasks, may be seen as one set of steps for navigating this space. The Kelley piece on brainstorming shows another process (or part of a process) that the task-centered approach does not cover in detail and represents another way to approach the design space. How might these different approaches lead to different or similar designs? Thinking about other approaches to design or problem solving (perhaps from other fields), how could one modify the task-centered process?
Davidsun - Aug 28, 2006 02:19:05 pm
Example comment here
Hiroki Terashima - Aug 28, 2006 09:15:29 pm
I agree that a system should include generic features that users expect, but I don’t think that they always must be included. Perhaps the triviality of the functionality and the difficulty of implementing it might not make it worthwhile; the design team should discuss whether or not they have enough resources and reasons (benefits) to include them.
Aside from brainstorming, another way to come up with ideas is to take a break from thinking and go do something ordinary. When I worked in groups on projects, some of our best ideas came out during lunch/dinner outings, when we would leave the lab and go to Asian ghetto (gathering of mostly Asian restaurants on the south side of campus). Maybe waiting for food/chit-chatting made us think in different ways? The group members and I have also come up with “creative ideas” while watching TV, playing with rubrics cube, and taking a shower.
Andrew Hao - Aug 28, 2006 11:35:15 pm
It is my observation that the "brainstorming" process path as described by Kelley encourages much more openended creativity - with the emphasis of quantity over quality whereas Lewis & Rieman's approach is a systematic, directional approach that violates Kelley's "The boss gets to speak first" tenet.
Personally, Kelley's approach seems somewhat directionless and banks on the certainty of a golden egg among the duds. However, the real world is full of specs and non-negotiable requirements that may best be attacked with a task-oriented approach providing the necessary orientation to start the design team on the right path.
Patti Bao - Aug 28, 2006 11:54:44 pm
The argument that Lewis and Rieman make in favor of including generic features sounds fairly convincing: users are accustomed to performing tasks in a certain way, and that way seems to have worked well, so why change it when performing the same or a similar task? But if those generic features were once designed for a specific purpose that no longer exists, then keeping them seems rather redundant to me. And if there is a novel interaction that works better, then why shouldn't we try that interaction instead? To be sure, taking advantage of people's existing paradigms will inevitably lead to greater ease of learning, but unless these paradigms are the best ones possible, I don't see why designers can't make room for improvement. Every "generic feature" was once a novel feature that had to be introduced, and given that multiple iterations are a good thing, doesn't it make sense that designers are allowed to reinvent what's generic?
Alex Wallisch - Aug 29, 2006 11:37:22 am
The Lewis and Rieman reading suggests adding functionality to a program based on what the user expects. However, there are times when it is not clear what the user would expect. Imagine a shell that was intended to be used by newbies. What should happen when the user presses ctrl-c? Should it copy the selected text, or should it kill the process that is currently executing? What about ctrl-z? Undo or suspend? In general, should programs try to make their interface streamlined with other programs that the user might be using, or should they copy the interface of similar apps?
I'd personally advocate the former. Think about the shell example again; I'm used to how a shell works, and I'd scream just as loudly as anybody else if they suddenly changed what all my commands did. However, I use at least 10 or 20 programs on my laptop on a regular basis, and only one of them is a shell. If my shell started using a standard set of shortcuts, I could just forget about the standard shell commands, because I wouldn't have to use them anymore; however, the way things are now, I have to remember both the standard set of shortcuts and my shell-specific ones.
The Kelly reading seems fairly useful, but it seems a bit hypocritical. On one hand, the author tries to get the point across that you can't make rules for brainstorming; everything has to be as open-ended as possible. On the other hand, he puts forth several restrictions such as a time limit or the exclusion of your boss. I understand what he is trying to say, but it seems sort of wrong to me to try to teach people how to be creative. Creativity is one of those things that can really only be gained through experience. That said, it was an interesting read and I did enjoy it.
Jack Yeh - Aug 29, 2006 12:18:19 pm
The cycles suggested in the task centered approach is oriented around all the tasks necessary to the user and how each task interact with another. On the other hand, the 3 cycles covered in the class is geared toward general UI where observation (catering to client's need) and change (to prolong product's life) happens in the evaluation phase or the next cycle.
As for the features that the user is accustomed to should be included only when it is possible to perform the same behavior the user has come to expect. If after quite some times, the standard has changed UI designers can try to improve these features instead of just tossing them away. (the underlying functions have been written already)
For brainstorming, I often sit down and just draw what comes to mind for a few minutes. Then, from the abstract design(ugly drawings) I try to picture them with more details added and write those details down. (text with an arrow pointing to ugly drawings) Most of the time, better ideas come after outside impressions that seemed unrelated (the media, internet)
- fixed for real name
Vahe Oughourlian - Aug 29, 2006 11:02:09 am
The task-oriented design method proposed seeks to work from the user backward, and this is the proper way, in my opinion. However, just as the previous design method focused too much on the designer's preferences, this view tends too far towards the the other end of the spectrum, especially in regards to the statement "what the user is used to." I agree with the observation that one should be mindful of the operating system enviornment of the user, but rehashing tired old interfaces can become a crutch. In most programming designs, this allows for speedier development, since these designs, such as a set of menus near the top of the screen or a set of buttons on a toolbar, have worked in the past. However, in some programs, where screen space is a premium, or would offer a more real-world related experience (a word processor with a full sheet of paper and no menus or buttons is an example), one could use right-click, radial menus, a la Neverwinter Nights. However, since the convention is menus in a bar on the top of the screen, that's what we'll often see. The problem, however, with a radical design is that it often becomes a battle between form and function, and the form part usually wins. In any event, few companies have pioneered the idea of multiple possible user interfaces that may appeal to different users. However, with the move to 3D desktops (or, at least, 3D-powered 2D desktops) such effects may prove easier to implements, as Expose was in OSX.
The brainstorming discussion validates the brainstorming idea to those who might have thought it a waste of time, and refines it for those who have made it a waste of time. I am somewhat amused, though, at the somewhat hypocritical way it is written; for instance, it advocates free thinking, but puts a time limit on brainstorming session. In my expereince brainstorming tends to occur in a situation where the people involved are comfortable. Though the brainstorming discussion does mention giving people the tools to brainstorm (giant Post-its, whiteboards), one of the things it didn't mention is a comfortable enviornment: plush chairs, couches, maybe a pool table.
Tabassum Khan - Aug 29, 2006 12:34:57 pm
The Lewis & Rieman design process is task-centered whereas the three-stage cyle described in lecture is user-centered. However, they both are iterative.
As suggested by Lewis and Riemen, I agree that a system should include generic features that users expect because it eliminates confusion and generate more prospects. According to Dr. Jakob Nielsen, the Web's usability czar, users spend most of their time on other websites (Jakob's Law). Therefore, users are accustomed to certain kinds of standardized features. If these features are absent from a site, users get confused and take their business somewhere else. In a research into Web-wide user behavior done by Dr. Nielsen, users left websites after 1 minute and 49 seconds on average, concluding in that time that the website didn't fulfill their needs.
Techniques to help people generate creative ideas: 1. Be Curious - ask questions : What? Who? Where? Why? When? How? 2. Take a long warm shower : Believe it or not, it works. I always get my best ideas and epiphanies in the shower.
Kang Chen - Aug 29, 2006 10:34:46 am
Lewis and Rieman's task centered is just a more specific version of the design-prototype-evaluate cycle presented in class. When we talk about design, it often includes stating and later building on a predefined goal. The building part would likely include steps such as "plagiarize" or learn from others so we don't reinvent the wheel.
As with the issue of including generic conventional features that users have come to expect from certain types of programs, I feel that this is a necessity. As a user first introduced to a new product, the usability and learning curve is crucial to your first impression. Users will likely get turned off if they have to check the manual or search online for help for every single task they are trying to do. This will ultimately drive users away. Quoting from class, a 5% change in user satisfaction can result in 85% change in profit. Therefore, it's probably not wise to put users through radically different designs.
Just to be fair, innovation is also important. If the designer has some grand ideas in mind, s/he should offer the option for the user to select from. An example of such case would be the designer and coder interface layout in dreamweaver where the first time user is prompted to choose what's more comfortable for them.
CharlesLeung - Aug 29, 2006 01:40:49 pm
Well, it isn’t always true that a system should include generic features just because a user expects them. As with many things in life, we need to weigh the costs and benefits of including those generic features and proceed accordingly.
In the Kelley reading, the author states that silly ideas should be accepted and is a necessary part of the brainstorming process. Although I really enjoy relaxed and easygoing meetings, it seems like those meetings just turn into a socializing sessions and end up taking a lot more time than they really should have.
Bowen Li - Aug 29, 2006 02:19:18 pm
In the first section, Lewis & Rieman specify the importance of having a deep understanding of the users of the system, and for the programmer to have interaction with the user. They also mention that several iterations of the design cycle are needed. However, in the real world, this kind of close interaction with the end-user isn't always possible. They don't address the fact that in many conditions, the programmer may be physically or socially separated from the end user. In these conditions, it may not be feasible for such interaction to occur.
On the point of including existing funcitionality that people come to expect, I agree that basic functionality should exist. As people have come to live with and use those items, they have modeled their computer usage around those functions. If one program among an assortment of programs differs vastly in basic behavior, then it will suffer. However, I think when changing the behavior of some function in favor of a better function (their example of hitting 'Return') I think it isn't a bad thing to introduce something new. This way progress can be made and future programs may even follow your better design.
Kelley's article seems much more open-ended. The idea of having free brainstorms and then focusing those thoughts down may not always work. Lewis & Rieman's method of using an existing system seems to almost always work. The end product may not be as creative or may not be a best 'fit' for the situation, but for companies it seems more realisitic because there some assurance by relying on existing ideas.
Roland Carlos - Aug 29, 2006 04:10:58 pm
I feel like the tasks described in the Lewis and Rieman reading are more specific than the 3-step method we were given. This is mainly due to the number of tasks we were given, and as people have said before, the Lewis/Rieman method is more task oriented, content to assign to step each different task, while the 3-step method leaves it in larger groupings.
In regards to the question of leaving generic functionality, Lewis and Rieman make a very strong point towards leaving them in. Basically, if something has become an accepted standard, forcing people to learn your "new" way will probably rub against the grain of many users (to many, change is bad) and you could potentially lose a large amount of your customer base from that fact alone. However, I don't think it should always be the case. In fact, if your product can produce a new way of doing things that could increase efficiency/ease of use by a large enough factor (that it would be called "revolutionary"), then by all means, the design team should try and introduce it, in hopes of their new method becoming the new standard. But as it was stated in the reading, designing something new is commonly fraught with failure, and time used to remedy the growing pains may not be available if there is a fierce push to release the product on a tight schedule.
Tony Yu Tung Lai - Aug 29, 2006 04:45:49 pm
I believe that for a system to include generic features that users expect is a good idea in most cases, mainly to make the user feel comfortable using the system. However, since each system was created for a specific purpose and specific type of users, not all generic features, especially the ones that don't play an important role in the system's functionality, would improve the users' experience. It is a policy that should be followed if it doesn't make the use of the system too complicated.
Anirudh Vemprala - Aug 29, 2006 04:35:59 pm
The three step process appears to be a more generic method for solving design problems than the task-oriented process. The latter looks like a helpful tool in evaluating and designing user interfaces.
I believe there is value in having certain generic features placed in a system even if they're non-important. e.g. a very simple file-sharing tool might not necessarily need to have, say, an Edit menu, but it is important for the application to have it there because users expect to see one.
Kelley mentioned a related idea in the article, but, the use of contradiction maps (the idea of laying out ideas and then thinking of the opposites of those ideas) is a pretty interesting one.
I also found a Wikipedia article on Creativity techniques that I thought might be an interesting read.
Daniel Stanfield - Aug 29, 2006 04:37:39 pm
I think Lewis and Rieman's comment about the inclusion of generic features users have come to expect is generally a good idea, but the decision to do so is dependent on just how entrenched those features are. As a case in point, I type using a Dvorak keyboard layout as opposed to the standard qwerty layout established as in the late 1800's. Despite the Dvorak layout's improvement over qwerty in terms of efficiency and ease of use, Dvorak users remain an exteremely small cultish group, and computers continue to ship with qwerty keyboards. Why? Most people who have taken the months of work to become proficient on one keyboard layout have little interest in committing more months of work to become proficient on another when the gains are so small. The existing interface is just too entrenched to warrant a change.
Ming Huang - Aug 29, 2006 05:07:12 pm
Although the Lewis & Rieman design cycle does not exactly match the simple three-stage cycle discussed in class, they both represent the same idea of any good software design apporach: one must always test and verify the effectiveness of their designs, and to do so continually and efficiently.
I am a firm believer of innovation. It is what made me choose computer science as my field of study and it is what is driving the industry's explosive growth. The "plagiarizing" step described in Lewis & Rieman makes me feel like UI design is much more constrained thinking than it needs to be. It is true that designers should have a very good idea of the state of things and what users already know. However, what the user expects may not be what the user finds most intuitive. As noted in class that there is more than one good design and a lot of poor ones. Systems and users change over time. For some of the so-called "time-proven" designs/products, people use it not because they are used to it, but because there is nothing that does the job better. Chances are that the result of a radically new design may have had more success. I would say that in the prototyping stage where change is easily affordable we should concentrate on surveying the design space to avoid what has not worked with users, but at the same time be brave to explore and be creative.
Tak Wong - Aug 29, 2006 07:02:40 pm
I agree that using the existing design is useful since some people don't want to get used to a new interface (especially those who can barely use a computer). You are also likely to get less resistance that way. For improving the interface, maybe it's more meaningful to have the user send the programmer an email if s/he needs a functionality. This guarentees that this functionality will not be wasted when implemented and should work well if the user is patient and both the user and programmer group is small.
In brainstorming representative tasks, it's probably easier to start with how the task is currently done. Go ahead and start a demo. We can see immediately what funtionalities are important and what's not through the demo. This is probably better than discussing and imagining what one needs to do to complete the task.
Andrew Tran - Aug 29, 2006 07:11:47 pm
I believe Lewis and Rieman's Task-Centered Designed Process is the same as the design-prototype-evaluate cycle as described in class, but just a bit more technical. Technical meaning it was more detailed and indepth as to what we learned with the design-prototype-evaluate cycle. Their 11 different steps to take can each be categorized under design, prototype, or evaluate.
Regarding the generic features question, i don't know if these should ALWAYS be included even if it doesn't play an important role in the system's functionality. If users never touch certain features, then it is ok to be removed. However, if users are already accustomed to some of these features, then the features should not be neither changed nor modified. If the users already expects these features to be included, then i don't think its ok for these features to be altered, even though not a lot of users use it and its not so important. Who knows, maybe sometime in the future there might be some boom and users everywhere are hastily in need of that feature. Wouldn't it be better to save that feature and not have to put it back in?
Johnathan Hawley - Aug 29, 2006 03:02:19 pm
Lewis & Rieman's design cycle follows the three stage cycle described in class pretty well I think. Task and user analysis and plagiarizing falls in line with design, roughing it out corresponds with prototyping, and iterating and tracking the design relates to evaluation.
Including useless generic features is not always necessary. They stated that it depends on how often the user will be running your system compared to how often they will be running systems they already know.
I'm sure there are other ways to create new ideas than what Kelley has suggested. All of Kelley's brainstorming techniques were centered in a group collaborating environment. Getting a chance to break away from the group can help solve any stumbling blocks involving too much "group think".
Julius Cheng - Aug 29, 2006 08:24:22 pm
Lewis and Rieman's plagiarization and Kelley's brainstorming can be seen as opposing philosophies. Whereas Lewis and Rieman are just short of making copying tried-and-true methods a cold hard rule, Kelley's brainstorming allows for more "wild" ideas to be considered. Whether to imitate the appearance and functionality of interfaces users are used to or to design something unique will probably be a question asked for all of time. Aside from the burdensome cost of designing something from scratch, the designers must ask, "Would this design be cognitively intuitive and efficient enough to force users to learn it?"
In most cases, what people are used to is good enough, and any supposedly better interface is just not better enough to justify the cost of making it and forcing users to learn it, so all Windows applications look the same, and so on.
This can be a dangerous mental trap to fall into, though; revolutionary ideas can often be the most profitable ones. I'd be quite sad if 50 years from now we had the same menu bars, the same monitors, the same mice, and the same keyboards, but it will be the case if all wild ideas were quashed.
Eric Yoon - Aug 29, 2006 08:57:12 pm
Lewis and Rieman's suggestion that a system should always include generic features that users expect is applicable in some cases, but may inhibit creativity in others.
It really depends on the effectiveness and "stickiness" of the generic feature in question. For example, there are many alternatives to the QWERTY keyboard, but generations of people have invested a great deal of time and energy into that interface. It would be costly and painful for people to change their ways. Morever, the keyboards works relatively well for what it does. Generic interfaces with these qualities probably should be kept.
On the other hand, if the generic feature in question has its weaknesses or if people can change their expectations with minimal effort, then it might be worth it to explore new avenues. A great recent example of this phenomenon is the controller for the Wii, Nintendo's next generation game console. It was a radical departure from what most people grew to expect from game controllers. Rather than using the more traditional joystick or gamepad, Nintendo based their system around a motion-detecting wand, which could be waved and swung to imitate a tennis racket, fishing rod or sword. Nintendo realized that video games have failed to appeal to many groups, and a wanted a device that would break that trend and allow its system to reach previously uninterested consumers. The new controller became the darling of the industry's most recent game convention, and now has people excited about Nintendo's once neglected system. Sometimes it's worth it to toss what is expected to pursue new markets and better functionality.
Rayhan Lal - Aug 29, 2006 09:02:59 pm
Lewis and Riemann provide an excellent outline on giving the end-user what he or she wants. (That is of course when they know what they want). I wanted to point out that like many others I find the critique of innovation a little restrictive. Microsoft Word used to have a spell checker based on the old design of a separate tool utilized once the document was constructed. Anyone who uses the new right-click interface probably appreciates the design but can still use the old version if they like. I suggest something similar: if one has a novel interface add it in, but retain the functionality the user knows. That way those who want can take advantage of it (and increase productivity), while others can stick to what they know.
A study done at the University of Madrid lends support to Kelley: [1]. During 20 minute brainstorming sessions groups were asked to create a finite number of ideas for "possible uses of a tin can." As the number of ideas was increased linearly the number of quality responses also increased (non-linearly). Because the increase is exponential we can conclude that this is not simply because a fixed fraction of all ideas are good.
(By the way, I owned one of those Wiggle Writers).
Udam Saini - Aug 29, 2006 09:44:55 pm
The Lewis and Rieman design cycle is very similar to the three-stage cycle described in class. The main difference is that the Lewis and Rieman cycle goes into a bit more detail concering the design, prototype, and evaluate stages.
A system should not always include a generic feature that a user expects that don't play an important role in functionality. It is true that these should be there in most cases, but a project always needs to take into account other factors besides the user. If adding in the generic feature that a user may not use too frequently (but would expect the program to have) proves to be too costly, or it would add extensive code/compromise the actual system functionality, there is a good argument for leaving the feature out of the product although this may inconvenience the user.
Another way to spur creativity is to have a session to relax people's minds. Throwing out ideas in a brainstorm is great, but I often feel that I get an idea only after many of the ideas have already been thrown around, and there is a moment of silence for me to relax my mind while the previous ideas (and new) are in my mind subconsciously (I am not actively thinking of them). It might be better to take breaks from brainstorming, at least for some people.
Melissa Jiang - Aug 29, 2006 09:53:21 pm
Like some others have pointed out already, the Lewis and Rieman design cycle appears to be a more in-depth version of the design cycle presented in class with many of Lewis and Rieman’s steps being able to fall under one of the three stages presented in class. However, the three stage cycle described in class can be applied to other UI interfaces whereas the Lewis and Rieman focus more strictly upon task-centered User Interface Designs.
As for the generic features, the idea of not incorporating any generic features seems impossible. Simple and universal features like cutting and pasting have become so ingrained in most users’ lives that not including it seems almost preposterous. Also, by simply including simple and universal features, the designer can lull the user into a sense of comfort while presenting them new and better features as well. Even if the new feature betters the prior one by 100x, users will still need time to adjust. Having that old generic feature acts like an insurance and will allow the user to more confidently test out the new feature without losing what they are already familiar with.
As for the brainstorming task, as opposed to what Kelley stated, thinking of a really broad topic related to what the original topic is can be helpful at times. By having that really broad topic in one’s head, I can jot down anything that comes to mind and those things may lead to a whole different approach that I would not have otherwise thought of.
Maksim Lirov - Aug 29, 2006 10:25:31 pm
The Lewis & Rieman design cycle appears to be a more detailed version of the three stage design cycle that was presented in class. The L&R design cycle is more specific than the three stage one and is almost like a step-by-step guide to designing a product. Steps like "plagiarize" in the L&R design cycle are not implied by the three stage design cycle, but most if not all steps in the L&R design cycle do fall into one of the three cycles of the three stage design.
I do not think that it is always true that a system should include generic features that users expect when these features don't play an important role in the system's functionality. I think that when the system to be designed is something that is different from any existing systems, then it is important to include generic features that users expect in this system. Generic features will provide a certain comfort level to the users and will serve as sort of a hook to continue using this system. If there are no generic features present, then the users may feel daunted to use the system and may not feel that their time to learn how to use the system's all-new features is worthwhile. In later editions of this system, I feel that it may be a good time to lessen the number of generic features and start putting in more innovations.
As far as brainstorming goes, I think that group sessions are definitely a good way to come up with creative ideas, but I feel that one should think about possible ideas alone also. When I take the time to think alone about a certain topic or idea, I feel I gain a deeper understanding of the topic/idea.
Bryant Yu - Aug 29, 2006 10:43:53 pm
The design scheme posed by L&R et al is very similar to the one described in class. Perhaps L&R went further into detail than our esteemed professor. For instance design = "choosing tasks","plagarizing"; protype = "roughing out ideas", and "thinking about it"; evaluate = testing and thinking abou it. Both stress the importance of improvements with iterative design.
Very rarely is something always true. This is no exception. Sure copy paste commands are always important to have not because these are functions ppl expect and are trivial but because this helps satisfies some baseline requirement of the software. (ie the software shall have the functions that allow the use of cross applications) I think I will actually say that no feature should be implemented unless it is used to satisfy a requirement of the software made from a technological and business standpoint. Now it's important to think about what these requirements are, how they're made, and why they're made. If the average consumer expects there to be a dog walking service attached to ur fishing pole site, you're not gonna put it unless u expect the revenue generated by that addition is gonna be greater tahn the effort put into adding that dog walking service. It's all about adding value to ur software. Quantize the amount of revenue it will generate and decide if the revenue is worth the cost of coders, servers,time, potential maintanence, possible down time, and other bad stuff that can happen.
I think hiorki is defintely right when he said that some of his greatest ideas are came after decompressing in Asian ghetto. Sometimes decompression is what you need to loosen the bits you need to connect 2 ideas together. Furthermore, I find that one can find great ideas by applying another field to our situation. By using concepts of business or everyday life with friends we can apply them to engineering.
Edward Karuna - Aug 29, 2006 10:21:01 pm
Like others, I believe Lewis and Rieman's design cycle is very close to the design-prototype-evaluate cycle presented in class. What I find interesting about it, however, is if you start categorising each step in the task-centered process in terms of the three design-prototype-evaluate steps, you find that Lewis and Reiman actually (discounting the iterate step, which of course repeats) have created a design process that integrates at least two or more complete design-prototype-evaluate cycles, emphasising the cyclic nature of design.
What I've noticed about generating new ideas is that if I think too much/too hard about one thing, my brain gets locked onto an idea and refuses to move on. If I forcibly disengage (e.g. play something, take a shower, work on something else) when I come back to brainstorming, my mind is able to generate a more diverse set of responses.
Natalie Nguyen - Aug 29, 2006 09:58:47 pm
The task-centered design process described by Lewis and Rieman comes off sounding very traditional and methodical; it is itself task-centered on successfully designing and delivering a UI in a timely, cost-effective fashion, taking as few risks as possible. However, the contrast between the two readings is interesting. Even the tone of Lewis and Rieman is dry and methodical, whereas Kelley is inspiring and energetic.
I do not feel that the default action should necessarily be conforming with the users' expectations; just because this has been the way it has always been done, doesn't mean this is the way that it still should be -- and I think that this goes for adding pointless features just because the user expects it (depending on the feature -- the wording of "even when these features don't play an important role in the system's functionality" is a little ambiguous to me). Not conforming, to be sure, is the unsafe route; however, if your innovations are still (or more!) intuitive to your user base, then you may be looking at a great competitive edge. I think many times with computer interfaces, I feel like I've gotten used to things not because they're arranged in a way that I want them, but because I didn't really have any other choice ... this entire past decade or so.
Scott Friedheim - Aug 29, 2006 11:04:47 pm
The three stage cycle described in class is just a high level view of the stages that were outlined by Lewis & Rieman. The three stage cycle is good in that it encompasses the essence of what UI design is; the L&R stages are the how-to's and step-by-steps. An point I found interesting in L&R was that things that users do normally can be incorporated into your design to make them feel more comfortable interacting with your design. As UI designers, rather than redesign the spell checker in a software package your building, it just might be better from a user satisfaction stand point to leave the same old design in place.
Generic features to be included on a system just because they are features seen on other systems is bad design. If making the user comfortable is the only purpose for add a feature then it just might clutter up the system while possible making the system more error prone. I've used many products that were filled with features because it is the norm for that type of product to have however, it bugged me that I had to deal with all these features just to get the product to do what it basically was meant to do.
Robert Taylor- Aug 29, 2006 11:34:17 pm
In response to the second prompt, "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 actually do think this is a very good idea. Often programs written without the common menus feel amateur-ish, even alien. If a user is just using a program for the first time, I think it's best for them to feel like they are in a familiar and comfortable environment when they start to learn how to use the program; a whole host of menus the user doesn't recognize can seem daunting.
While useless features obviously aren't such a good idea, it seems prudent to try to stick to a familiar menu layout, ie File/Edit/View/Tools. The contents of those those menus doesn't have to be the same familiar (and contextually useless) features; one could try to put useful features into familiar menus. At that point the challenge is making sure the features fit the "familiar" menu, but of course there will always be challenges in UI design; the issue is making sure the challenges yield a useful and intuitive result. I think finding ways to put useful features into familiar menus and interfaces is not only a good challenge but a good compromise on the L&R postition.
Perry Lee - Aug 29, 2006 11:11:38 pm
I am not sure if I agree with Lewis & Rieman's claim that "more often than not, the best answer is to stick with what the users know, even if it does require an extra keystroke or two." I understand that taking the plagarism route is safer in most cases; however, how can there ever be substantial innovation if we more often than not err on the side of "what is known" rather than what may be a better solution?
Although I agree with a lot of what Kelley had to say, I think he missed the type of brainstorming that occurs subconsciously; I've often come up with my best ideas after setting aside the problem. Sometimes that epiphany comes when you least expect it (and while you're doing something completley unrelated).
Heung Tai - Aug 30, 2006 12:18:22 am
I like the fact that Lewis and Rieman encourage plagiarizing. This "technique" is efficient because it prevents the problem for reinventing the wheel. Once a good interface is wide spread and adopted by many people, it just doesn't worth the time to create another interface. However, I doubt the practicality of getting different people with different skills into a meeting for the interface. I wonder how much it costs to get techical writers, marketers, programm engineers, some managers, interface designer together. I think a better way is to provide enough user-related education to the interface designer. Then, the meeting may only require interface designer and technical writers, it can save a lot of company's resource.
Kelley points out the importance of brainstorming but I think she goes too far. Brainstorming should be individual's activity. Where there is a meeting, all suggestions should be well-formulated and support by some evidences. It is a waste of time to get people together and let them throw out random thought, because it will go forever without any good conclusion
Sung Yi - Aug 29, 2006 10:40:16 pm
Lewis and Rieman design cycle talks more specifically about the three stage cycle (design, prototype, evaluate).
I don't think a system should always include generic features that the users expect if the features are rarely used or are obsolete. It may be that the users are expecting those features not because they are convenient but only because the users are used to using them. After an extensive study and survey, including a better alternative feature would be risky but much more prolific than sticking with the generic features.
Lastly, in the The Art of Innovation article, I think narrowing down the problem statement is not always a bad idea because although it can distract members from the general purpose, it can actually help them focus to solve specific problems.
Michael Moeng - Aug 30, 2006 12:06:00 am
It seems as though Kelly's definition of "brainstorming" was somewhat narrow. The second article states that one cannot brainstorm something with a narrow focus, like the spill-proof lids, but many of the ideas Kelley puts forth require at least a decent amount of direction in the first place. Kelly frequently talks about the brainstorming method as solving a problem at hand--sometimes there is no specific problem, like "What should I write about in my next essay?" for a writer or "What kind of a game should we make next?" for a game designer. Kelly's brainstorming seems to be more focused--examples Kelly uses are brainstorming on "applications of specific new technologies to the toy industry" or "aternative wine beverage containers." Kelly goes into the brainstorming sessions with a good idea of what is needed, which isn't always the goal when brainstorming
Cheng-lun yang - Aug 30, 2006 12:34:40 am
Any programs written are not generic, the programmers copied parts of the code from previous programs. It is part of programming just as quoting when writing essays. Plagiarizing is essential and unavoidable in Computer Science field these days. The cycles described by Lewis and Rieman is just a more detailed division of the three cycles, design, prototype, and evaluate. Section 1.1 to 1.5 is the designing phase. Section 1.6 is the prototype phase. Section 1.7 to 1.11 is the evaluate phase. I believe that every system should include the generic functions all the time. It is the basic idea of modular design, make it easy to modify and reuse. Even when the basic functions are not used, they should be included for possible future edits. No one can never predict whether the piece of software will ever be modified to use the basic functions or not.
Patrick Rodriguez - Aug 30, 2006 12:52:56 am
I have to agree with Prof. Agrawala's assertion that L&R and Kelley both favor building upon established ideas. There are very few truly revolutionary designs; most are simply evolutionary. Pick any technology, and you'll find that it's usually just something that's faster, cheaper, or easier to use than what has come before. Of course, over time, these little steps forward add up. Compare what we have today to what we had just 10 years ago. It seems like a big difference, but it's really just incremental change. Thus, you're better off trying to improve on something than starting from scratch. And even if you think that you've come up with something radically different, chances are good that something half-way similar is already out there somewhere.
Collaboration, such as brainstorming, is a good way to build ideas through incremental change. One great example would be Wikis. These sites can basically be 24/7/365 brainstorming sessions. I can post one thing and watch as how other users add/edit/remove to transform the post into something different (and hopefully better).
Jonathan Yen - Aug 30, 2006 12:36:23 am
The Lewis & Rieman design cycle, like many others have noted, appears to be very similar to the 3 stage cycle discussed in class. If we eliminate many of the steps in the L & R design cycle, we could very well obtain the 3 stage cycle from it.
As for including generic features that users expect, it is probably not always necessary. But as mentioned in the L & R reading, it will happen more often than not that using the generic features is better. An example in which it is not necessary to have the generic features may be an instance in which information in a document is provided as a dynamic application intended for viewing constantly changing information rather than a static document, in which case it might be irrelevant to have the ability to print or perhaps save the document.
In regard to the Kelley reading, it is interesting how IDEO considers brainstorming to be an activity that requires skill and that can be refined. The suggestions that are given for improving brainstorming productivity seem almost obvious, but they are definitely not consciously in one's mind when approaching a brainstorming task. There seems to have been a lot of studying done on the task of brainstorming, as there are many things that I did not realize about brainstorming, such as the number of ideas that can come up in a typical brainstorming session.
I find it also interesting how there are ways to kill a brainstormer. When looking at brainstorming, it is usually viewed from the perspective of gaining more ideas, but Kelley observes the potential hazards that may arise while brainstorming as well. Though it is likely not a thorough list of brainstorm killers, it seems to hit the basic ideas.
Jae Chang - Aug 30, 2006 12:44:34 am
The Lewis & Rieman design is more specific and extensive than the three stage (design, prototype, evaluate). The L & R design emphasizes to focus on users because software designers can be more focused on task and technology than users' experiences or needs. Testing the design with users is a crucial role of the evaluation in the cycle. Also, I belive that including generic features that users expect is a good example of the user-oriented design process. By including the features, even if the features don't play important role, users can be comfortable with a new design easily so that they can adopt the design faster.
Yimin Yao - Aug 30, 2006 01:21:04 am
Lewis & Rieman design cycle seems compatible with the three stage design cycle covered in lecture, except they have broken down the three stages into many more details processed that people can follow to carry out the mission.
As to the argument 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, I believe that this should not necessarily be the case all the time. Yes, people are more comfortable with familar features, but they would only look for those features when they need to use the functions those features provide. I think having a similar overall visual layout for the interface is necessary and sufficient to reduce users' initial panic in using a new software, but a long term goal should be guiding users towards a better, sufficient interface, if one exists and is different from the current design. However, it is probably a good idea to avoid a new feature with the same name as an old feature with different functionality. If one really wants to reduce the discomfort that Lewis & Rieman are concerned about, the obsolete features can be evaluated for their importance in the users' daily operations, then very selectively incorporate them in the new interface.
Simon Tan - Aug 30, 2006 01:13:43 am
In a way, I was surprised when I read Lewis & Rieman's suggestion that it is almost always wiser to hedge a safe bet by creating an interface that "plagiarizes" common elements from existing interfaces. As people have commented, this implies that innovation is not really encouraged. This is why the same keyboard shortcuts, the same menu bars, and the same window configurations are still around after more than a decade of UI development.
However, upon further thought, I believe that we must stick to the ultimate goal of user interface design - that is, focus on what the user will experience and how the UI makes a user's *tasks* easier to do. If the user will fumble over the fact that CTRL-C does not execute a copy, that is a failure in task-oriented user interface design.
Case in point: The Opera web browser, with its latest release, changed the keyboard shortcut for "new tab" from CTRL-N to CTRL-T, to better match the existing experience of people migrating from the Firefox web browser. People are thus more comfortable using the browser right off the bat, without enduring frustration about why "their key binding" doesn't work.
David Eitan Poll - Aug 30, 2006 01:26:03 am
It did not come as much of a surprise to me that Lewis and Rieman would suggest "plagiarizing" when it comes to interfaces. This is something people do every day when it comes to interactions. When I give a handshake to a person, I make sure that it's a firm one. Why? I think it's because I've felt others with weak and firm handshakes, and firm handshakes make me more inclined to want to interact with that person. I've seen an interaction that was effective, so I choose to copy it. I can pretty safely assume that others will interpret a firm handshake in a positive way, so this process makes me a more effective greeter. The same thing seems true with software UIs. When an interaction is comfortable, it's worthwhile to stick with that model of interaction to maximize your UI's effectiveness.
As for brainstorming, the thing that stuck out most to me was the importance of not turning a brainstorming session into a meeting. I can see how making the session into a meeting could stifle the creative process. At the same time, there's a certain amount of power and productivity inherent in a meeting that I don't think should be discounted. Meetings can provide a structured forum for ideas that enables effective communication of those ideas. I just hesitate to criticize meetings as being anti-creative when I think there is a lot of potential for wonderful ideas to come out of them. True, the ideas aren't free-flowing, but why is that necessarily a good thing? I would be worried about how scattered and disorganized the products of the brainstorm might be, regardless of how many gems of ideas have been discovered.
Antonis Mannaris - Aug 30, 2006 02:33:30 am
The three step cycle described in class, seems to be missing a very important step that is included in Lewis and Rieman's design cycle. That is step 5 where you "think about" your design. I believe that too often, when designing a system, we get caught up in the details that we miss the big picture. So an evaluation of the design itself after it is completed (or even while it is being developed) may help save a lot of time and effort. In my personal experience, I spent a lot of time designing a feature as part of a larger project which I then realized was not necessary! A sort of similar argument applies to brainstorming. I am repeating my classmates on this, but taking a time-out after brainstorming is finished to reflect on the BIG PICTURE often leads to incredible innovations.
Finally I would like to say that the idea of plagiarism is indeed very important and helpful. What is not mentioned though, is that perhaps you should also look at the pitfalls of existing systems, and put some effort into fixing them in your own. This will make the user appreciate your design even more. For example, I would love it if future releases of Word didn't send a document directly to the printer when the taskbar "print" icon was pressed. This is just my opinion but I would like the ability to change settings, just like when you do when the menu "print" is selected. An other great exaple is tabs in Web Browsers. Obviously, someone already thought about this!
Chen Chang - Aug 30, 2006 01:58:45 am
I think the Lewis & Rieman design cycle is an expanded version of the three stage (design, prototype, evaluate) cycle described in class. For instance, L&R essentially separates the design stage into five smaller stages of a) figuring out who's going to use the system to do what (the main user base) b) choosing representative tasks for task-centered design (real tasks that users have actually faced) c) plagiarizing (effective copying re-usable exisiting paradigms) d) roughing out a design (drawing out the design with pen and paper) e) thinking about it (figuring out strengths and weaknesses before building the UI)
As for Lewis and Rieman suggesting that a system should include generic features that users have come to expect even when these features don't play an important role in the system's functionality, I personally think this is true simply to preserve the habits of users developed over time as each person does something their own way and thus this would minimize confusion and havoc. An example that comes to mind would be the straightforward MS windows popup confirmation dialogs on application exit, with users coming to expect the left button being "Save changes" and right button being "Cancel and quit" or something along these lines. However, if a new application suddenly decided to reverse the order of the buttons, many users may get "tricked" into a quick button press which could cause important changes to get tossed. Basically, keep it "standard" and don't go against the grain.
In regards to brainstorming, my best sessions have always been in the shower. I don't know the reasoning behind this, but I recommend trying it out if you have trouble coming up with ideas through other methods. If it works, you get a two for one deal in getting clean as well as having your ideas layed out in front of you.
Michael Mai - Aug 30, 2006 03:22:58 am
As many others have discussed, I believe that the L&R design cycle is almost exactly the same as the three stage design cycle. Although to make the image more complete, the L&R design cycle has User Input arrows flowing in every stage because the users are the people who define the tasks that the developers must create. From my personal experience and a somewhat obvious distinction to make about the cycles, is that after the initial creation cycle, the following cycles tend to be much shorter in order to keep the products competitive and up to date. The design portion of the cycle tends to shrink and the testing and problem fixing parts (evaluate) are expanded as the consumer base grows and the need to keep customers satified increases.
As for the generic features, I believe that if the customer is expecting it then it should most likely be implemented but I think it depends on what the developers are trying to promote. If they are just promoting an upgrade or improved version to an already old engine or OS like windows, then for the most part, the generic features should stay the same in order to keep the users comfortable. However, if the developers are looking to promote a new product, some of the features should remain generic but new features are just as important to set the new product apart from others, and hopefully give them a competitive advantage. This could give input on whether this new feature can one day become a generic feature. An example I'd like to bring up would be the new controller of the new Nintendo System, the Wii. Up until now, the gaming console controllers have all been connected sharing the buttons on one complete controller. Now the Wii brings two, keeping some of the generic features such as the Directional pad and the generic A&B buttons, but with a twist that isn't generic anymore. It's a big risky venture, but it may end up paying off.
Eric Vacca - Aug 30, 2006 04:25:59 am
In an ideal world, all computer users would be proficient and open to learning new UI conventions. In reality, we have a spectrum of skill levels and user needs that as designers we must attune ourselves to. The argument for generics is that revolutionary innovation will occur almost naturally when the public demands it or is ready for it, so the goal should be user functionality now. I believe the use of generics in UI design will always be useful, but as the software/computer industry progresses further generics will become less and less necessary and a brainstorming environment will make more sense.
I find it ironic that a consumer industry (Kelley) is the advocate of such an open brainstorming environment where as the tech and more specifically the software industry representatives (Lewis & Rieman) advocate a seemingly entrenched environment. I think this is because the Lewis and Rieman reading is dated and reflected the current state (pre 1994) of the software industry. In those days, home computers were still not completely excepted and so it was a necessity for designers to focus on not losing current users due to a UI design that MAY be more efficient, but the public is not ready for. As opposed to a more traditional industry such as toys or tool makers, most ideas have been exhausted for many years, and so innovation is a business necessity. This is true for any entertainment medium, where people crave the "new thing". Kids want the cool looking radio controlled air plane, not the metal fire truck. But since 1994, when Lewis & Rieman's book was written, the computer industry has grown and overall user savvy has increased. Also computers have started to become more like a toy industry, and design innovations are happening at an increasing rate.
Nintendo seems convinced that the world is ready for an overhaul of the game pad convention they introduced over 20 years ago. It seems like a brilliant design, simplifying the button scheme which has gotten out of control. Note that just as Lewis & Rieman suggested Nintendo is not attempting a complete revolution contrary to the systems ex-name. The system still has the generics from its original NES controller. I think its a move in the right direction and although it may isolate some diehard gamers most of these users have already migrated from consoles to PCs and the intuitive UI design will pay dividends. I see the entire computer industry migrating from buttons to interpreting motions in the very near future and Nintendo is (as always) surfing it.
Qingyun Tang - Aug 30, 2006 05:58:01 am
Lewis & Rieman suggests that in order to have a good design of the user interface, the design team must follow exactly what users need. This is sometimes uncertain to me. Some users with little imagination and creativity often come up with poor design schemes; while experts on design team can make a much simpler and faster-operated interface. However, this is going to benefit the users only if the design team has carefully looked into what the users need and improve the original interface based on the basic interface. Testing design with the users at the end is always necessary and the most important.
Kelley tells 7 secrets of brainstorming and 7 ways of killing brainstorming. My personal experience is that I do better brainstorming if people stack up their ideas. Even though it seems pointless, but new ideas do come out after a lot of ideas are put up together, thus making more progress.
Huangnankun - Aug 30, 2006 07:30:37 am
Lewis and Rieman talks about the task-centered design process. Their article talks about an entire approach about user interface design from start to finish. This design process is goal-oriented and the first step they talk about is to define this goal by finding out what users want. I think its also in the first step that the designers should take into consideration of factors like hardware/software limitation, which may affect the final design of the system. I feel the next 2 steps can run in parallel as when designers pick representative task which the system will carry out, he would naturally be looking at similar systems already on the market in order to see what are the current interfaces available and modify/improve/customize the design for the current application. I’ll add that I think also important during an object oriented design process to map out which UI objects would be created during this step in the design process. Many RAD environment such as the visual studio package or Delphi has many pre-packaged UI components which can be used, abundant use of these tried-and true UI elements will make it easier for users to interact with the system since they are widely available on other applications. The next stage described in the lewis-Reiman process is to rough out the design, I think this stage functions to refocus the design process on the goals since this is the stage to see list the solutions to the goals. The “Think about it” stage acts as a validation for the “roughing out” stage, I think in a typical design process, the design team would go back and forth between these 2 stages until a streamlined solution is finalized upon. Finally the prototyping stage shows the entire design team how the application will “flow” together. Finally comes the steps to beta beta-test, iterate and finally build.
In the brainstorming article, it gives users 7 ways of coming up with brainstorms. While brainstorming is usually a free formed process, the author gives many constraints such as “time-spent” and the “scope” of brainstorming. I do not like many of the methods advocated by this article. In my personal opinion, I feel its best to brainstorm while going along with the design process described by Lews an Rieman, at each stage in the design process as the system takes shape, new ideas will flow into the design team. I also do not think there needs to be specific “brainstorming sessions” since these ideas usually come naturally. However I do feel that its important that the design team need to validate their idea to see if they actually work towards the goal of the system ( the checklist in the “rough out the design” in the Lewis Reiman process). If not, the idea should be discarded.
Ramy Ghabrial - Aug 30, 2006 06:46:16 am
It seems to me that the main difference between the two approaches to design boils down to one line in L&R: "You might be able to create a novel interaction paradigm that's better suited to your application, but the risk of failure is high."
Hence the two approaches are reconcilable; brainstorming can be used and woven into a modified task-based approach, so long as risk is minimized. Looking at L&R, this would seem to work best in steps 1.2 (choose tasks) and 1.4 (rough out design), with 1.5 (think about it) serving to cull infeasible or ultimately useless creative ideas before they consume too many resources better used elsewhere.
Kimberly Lau - Aug 30, 2006 07:27:39 am
Lewis and Rieman's propose that a system should include generic features that users expect even when these features don't play an important role in fuctionality. Although this method is beneficial in that it helps users become more comfortable with a "new" product faster, I also think how much this method should be enforced in one's design should depend on what type of customer base the product is aimed at. For example, older generations generally have more trouble adjusting to completely divergent designs, while younger generations adapt to new features easier (and perhaps expect to see them more also). As such, should a product be geared toward the younger age, perhaps a few new features would be good and not hinder popularity or success.
The brainstorming process that Kelley described sounds successful. Encouraging everybody's ideas seems especially useful. Usually, unrestricted brainstormers will give insane ideas but with great functionality, and it is from those ideas that people can build upon to develop a product that will work while sustaining the core idea. One additional thing I think works for in brainstorming is to always push for one more idea, after everybody thinks they are done. When Kelley gave the example of 100 ideas per meeting, I would suggest to get that ONE more idea at the end, because it is often the best idea of the entire batch.
Suthee Chaidaroon - Aug 30, 2006 07:28:45 am
Task-centered design is similar to the three-stage cycle in a sense that they are both repetitive. The Task-centered design, however, have more steps on desiging such as making a user story.
L&R suggests interface designers to build interfaces based on the previous systems that users have worked with. This approach is useful for users who are not willing to learn new interfaces. However, implementing a new interface by borrowing an existing ideas might not be the most feasible design approach. From my experiences, to use Ctrl-C and Ctrl-v as a short-cut for copy & paste is common. But Emacs developpers does not "plagiarize" this commonly used short-cut. As an Emacs users, I found that using Emacs's short-cut for copy and paste are even faster than the Ctrl-C and Ctrl-V.
I think designing an interface is not about coming up with new ideas or innovation. We are simply trying to satisfy our clients. So if innovation can make client happier, then we should invest more money and effort onto it. Our clients does not care how hard we work anyway.
Joe Hart - Aug 30, 2006 08:38:51 am
The Lewis & Rieman design cycle seems to be a more "hands on" approach to the complete design cycle while the design, prototype, evaluate type design cycle is more generic. It seems to me that the d,p,e design cycle should occur at each stepdescribed in the task-centered design process. The task-centered design cycle is more centered on programs that are used to help users complete tasks... what about programs that have the purpose to market a product or a service? The d,p,e type design cycle seems to address a more wide range of programs that may be created.
In regards to including generic features, always is a strong word. While this statement is generally true there are always situations where the generic feature should not show up... like the ability to copy and paste passwords for example. Also, sometimes it is good for the designer to "create" an efficient workflow for users where previous applications failed. This may require simplifying standard generic features to a bare minimum.
It seems to me that the "rules" for brainstorming are not well defined. It is almost like there is a zen to getting in the "zone". How does one get there? I see this article says what not to do, but is a little vage on what TO do. Overall, I am very motivated by the knowledge that companies like this exist in the world.
Yen Pai - Aug 30, 2006 09:35:57 am
The Louis/Rieman design cycle can be characterized as a specific "implementation" of the Design-Prototype-Evaluate design cycle. It follows the same outline and suggests specific techniques for each of the steps. Sections 1-1.4 detail techniques for the "Design" part of the cycle; 1.5-1.8 detail techniques for "Prototyping" and "Evaluation"; and 1.9-1.11 deal with customer support and the future evolution of the product.
I think the suggestion to include non-critical "generic" features that may be expected because of the users' environment or current processes needs to be given with a big asterisk or caveat. Often, a new application is requested because a customer wishes to automate and/or improve efficiency of specific tasks. In many organizations, the processes targeted for improvement/automation are outdated, inefficient, and may rely on the undocumented knowledge of longtime employees or organization members. A user interface designed to closely mimic such existing processes may end up creating unnecessary confusion or interface inconsistencies for itself, as some real-life processes or familiar user habits do not translate well to an application UI. I do agree that a user interface needs to provide some level of comfort for its users but these "comfort" features need to be selected carefully.
I liked Kelley's ideas for brainstorming, about half of which are thinly veiled suggestions for ways to foster a creative, but focused work environment (and therefore improving the quality and productivity of brainstorming sessions). Warnings against only holding brainstorm meetings offsite, "overdemocratization (everyone gets a turn)", and the suggestion to open a session with a clear topic/subject are clearly aimed at changing attitudes towards brainstorming. Kelley suggests, that brainstorming should be and can be productive, fun, dynamic, and ingrained in to your organization. He tries to outline a basic structure for a brainstorming session that provides focus without imposing too many rules that may hinder creativity.
Both readings emphasize the importance of multi-disciplinary groups in product development. In particular, it seems crucial to avoid simple labeling people and expecting them to work within a restricted set of duties. The programmer should be good at coding, but he/she should also be familiar with the customer's needs, and how the client reacts to the product. At the same time, the marketer needs to fully understand the functionality of the program and its limitations. If group members are expected to have at least a functional understanding of other job roles, their performance is likely to improve.
The brainstormer reading also suggests that group hierarchies can hamper the free flow of ideas. The author warms against the boss starting a brainstorming session with rules or suggestions that could narrow the scope of ideas produced by the group. However, I believe that managers are still important in a business-wide context, due to their roles in motivation, assessment, organization, and even conflict resolution.
Robin Held - Aug 30, 2006 11:02:14 am
Both readings emphasize the importance of multi-disciplinary groups in product development. In particular, it seems crucial to avoid simple labeling people and expecting them to work within a restricted set of duties. The programmer should be good at coding, but he/she should also be familiar with the customer's needs, and how the client reacts to the product. At the same time, the marketer needs to fully understand the functionality of the program and its limitations. If group members are expected to have at least a functional understanding of other job roles, their performance is likely to improve.
The brainstormer reading also suggests that group hierarchies can hamper the free flow of ideas. The author warms against the boss starting a brainstorming session with rules or suggestions that could narrow the scope of ideas produced by the group. However, I believe that managers are still important in a business-wide context, due to their roles in motivation, assessment, organization, and even conflict resolution.
Aleksandr (Sasha) Ashpis - Aug 30, 2006 10:01:12 am
In Lewis and Rieman’s article it states that “a successful system has to merge smoothly into the user’s existing world and work”. Even though I would generally agree with this statement, it does not always apply, there have been many products that either didn’t work or are so revolutionary that users are willing to put up with difficulties due to benefits its brings, the best example is early Windows versions. In there article they also mention iterating to constantly improve ones product. My real world experience has taught me that, most companies would like to get their products to market as soon as possible to start making return on their investment and once a product is out, bugs are fixed but the UI rarely has major changes, displaying to me that not enough time is put aside for a role that will probably not see major alterations in future releases.
The brainstorming article is an interesting one and definitely relevant to our upcoming project. But it does take the act of brainstorming a little out of proportion. Don’t get me wrong brainstorming is important to any task in life and especially a large coding project, but I don’t think the excuse of we stayed all night brainstorming and look at this energy drink shot dispenser that we came up with instead of our UI project. Brainstorming has its place, but especially in a school/class setting when the semester is over relatively quickly, a group must properly balance and focus at their brainstorming sessions.
Utsav Shah - Aug 30, 2006 10:54:07 am
The task-oriented design suggests that we need to find out who are the users of this system that we're building and then design it accordingly. That's extremeley important in my opinion because ultimately the audience have the final verdict. It also suggests to design it, to create a mock-up and then test it and change it. I think this is the more detailed version of the three phase cycle mentioned in the class. As far as including generic features in the product concern, I think it's important to give the users what they are comfortable with. If you try to give them something extrodinary but hard-to-use, most of them will not use your product for long.
I found Kelley's article pretty interesting. As I was reading it, it occured to me that some of things he mentioned are obvious or soemthing we already know about but most of us still don't apply it when it comes to brainstorming. I also agree with the author on the 6 "Don'ts" he mentioned at the end as I've experienced some of them and didn't get too far.
Rory Martin - Aug 30, 2006 11:19:44 am
I agree with Lewis and Rieman that it is important to add features that a user would expect to find, such as copy and paste being ctrl-c ctrl-v. I am always happy to find that the interface from one program carries over to another. That being said, if we always keep using the same interface just because people are used to it, then we will take a long time to truly improve it. It seems to me that most great innovations are fairly different from their predecessors. I prefer solaris keyboards with the built in copy and paste buttons, a rather fabulous idea. I think that it is suitable to leave a common interface out as long as there is a distinct (and hopefully better) interface feature to take its place. I was a little confused when I switched from a PC to Mac because they both have a "control" button, but they don't work the same despite having the same name. This adjustment was acceptable because all Mac programs use "command" in the same way.
I also agree with Kelley that good brainstorming is essential in design. Last semester in cs162 my group would always spend the first hour of our meetings generating different ideas for how to write the code. We would make numbered lists and then weigh each one against the other. I found that this was the only way that we could come up with a decent design. I feel that Kelley perhaps lets his brainstorms become a little too loose, allowing "wild" ideas can often times be a waste of time as they are generally more difficult to implement. His brainstorms sound like free-for-alls in which there is no order, which in my experience can ruin a good brainstorming session by allowing the conversation to constantly bounce around from one idea to the next. I prefer to have a short discussion on each topic as we go along.
Heng Kuang - Aug 30, 2006 11:54:24 am
L & R’s design cycle is a more detailed version of the three stage cycle in my opinion. L & R also follow the design, prototype, evaluate steps, except that they emphasis more on design and evaluation stages. Also, the L & R instructions are more practical – one can easily find useful tips in their writing that would apply to whatever he/she is working on. Adding unimportant generic features is good if the features are truly expected by users. It could help users to adapt to new products. Anything that meets (positive) user expectation can’t be too bad, at least from the view point of sales and marketing people. However, knowing what the users do and do not expect is not as easy as tossing a coin.
Wai Jing Yu - Aug 30, 2006 12:06:35 pm
The Lewis & Rieman design cycle and the three stage cycle is very similar to each other. The only difference is that the three stage cycle is just the abstracted version of Lewis & Rieman design. Although, the Lewis & Rieman design has more stages in its cycle, it is composed with two cycle of the three stage cycle. The former cycle focus on task-centered design and the latter cycle focuses on other possibilities to improve the software.
I don’t think it is a good idea to always include generic features. Including it into the system or not should be determined by what feature it is and the system’s functionality. There might be generic features that have insignificant role and should not be included since the costs for time (implement and debug) and money it takes to make might not be worth it.
David Hoffman - Aug 30, 2006 11:49:36 am
The paper by Kelley on the perfect Brainstorm is interesting in that he really reccomends going into it unfocussed. I could easily imagine there being problems where we go into a situation thinking that we need to make some aspect of something better without considering changing the whole system around to eliminate the problem to begin with.
The Lewis and Rieman paper says that its a good idea to include familiar features even if they are non-essential. To some extent, its a good idea, in that it gives people another familiar way to use a new program, even if there is a better way of doing it. At the same time, from an engineering point of view, the further the design gets from the most simple state the more problems can occur. Including old features that are not really need for the new program may superficially work but have some functionality problems that are not immediately obvious. One way that some programs seem to balance this is that they include familiar objects in a grayed out state. That way they are available for orientation but they are clearly shown as being not needed.
Randy Hilarbo - Aug 30, 2006 12:28:16 pm
I agree with Lewis & Rieman about allowing the system to include generic features that users expect. But I think that this is not always true. Designers should also consider the cost of adding these unimportant features. Why bother adding unimportant features if it's gonna have effect on the system's performance, etc. I think that users are smart and they can always adapt to a design which lacks unimportant features that they are used to.
Kelley's take on brainstorming as a tool for generating creating ideas is pretty interesting. I think that brainstorming can be applied in any part of the design cycle (brainstorm, design, brainstorm, prototype, brainstorm, evaluate). For example, when you found a flaw on your design, brainstorming can be an easier way of finding a solution for that flaw.
Michael Udaltsov - Aug 30, 2006 12:21:13 pm
I think that the "plagiarize" step that Lewis and Reiman describe isn't named properly. What they really say is to look at existing ideas and implementations, and create something that will be familiar to users. And while they say to do it "legally," they don't explain what that means. While direct copying is of course out of the question, it's very important to determine what parts of an existing product are patented, in which case creating similar features or interface elements may be in violation of some patent. For example, even though a general idea of a menu isn't patentable, Apple and Creative are fighting over the menus in their portable music players.
As several other comments pointed out, the brainstorming ideas presented by Kelley are contradictory to looking at existing interfaces / plagiarizing. However, I believe that brainstorming always starts with existing products, ideas, and problems, so it's just another step in interface and product development. After you look at an existing product or problem, you brainstorm to find ways to improve the product or solve the problem - you can't just brainstorm without a starting point.
Tom McClure - Aug 30, 2006 12:32:51 pm
I would love to code in the utopian environment proposed by the Lewis and Rieman article. Despite my own efforts to champion many of the great ideas that they suggest, all too often the ideal environment is an inaccessible greener pasture, access to which is cut off by high walls like scarcity of resources. Scarcity of time, limited access to developers or designers who are overcommitted, no budget for videotape or user focus groups, etc. etc.
Sometimes -- despite setting aside these "best practices" -- you can still produce something that works, that's "good enough." Sometimes not. If the sometimes-not happened more often, these practices would be viewed by more as long-term time savers, but people get accustomed to "good enough" and they adapt to crappy software and give up on the feedback/iteration cycle. Sorry for the negative comments.
I liked the brainstorming article. I think one of the big wins of brainstorming that they couldn't say enough about in the article is the morale boost. This practice would have improved team morale in some of the darker moments of despair in the 11th hours of some of the projects I have worked on.
Leo Chen - Aug 30, 2006 01:21:02 pm
It always helps when designers learn from past success. Although, plagarize has a pretty negative connotation, in this case I do believe it helps to look at what has worked in the past. At the same time I believe it is very important to look at what has failed in the past, this way you can avoid making the same mistakes. By analyzing what works, and forming a framework of what has succeeded in the past, designers can gnerate new ideas that have a better chance of working out and succeeding.
Using generic features is safe, however being safe has its drawbacks. Interface developments like the Apple Dock and the Windows Start Menu give each OS it's own distinctive functionality. By being generic, you risk losing users to somebody else who pulls off the same generic features at a lower cost or more bells and whistles.
Dexter Lau - Aug 30, 2006 01:19:59 pm
The unique step of plagerizing is a very helpful step that many people already do, but don't realize it. It is an especially good thing because it allows people to recognize interfaces that they have dealth with in the past. For example, a simple login and password usually lets you just type, tab, type, and enter. If it were different, you might start accidentally typing your password somewhere else or something. For this reason, having the generic interfaces that were discussed by Lewis and Rieman are very useful. The other stages of the brainstorm cycle are logical and fairly widely known.
Siu Pang Chu - Aug 30, 2006 01:00:29 pm
Comparing to the three stage (design, prototype, evaluate) cycle, I would say Lewis & Rieman design is the instruction that designer can follow while the three stage is the higher level abstraction. Another difference is three stage is cycle processing, it is kind of a recursive process until you find the best design, while the Lewis & Rieman design is like a one way design, after 1.11 change the design, no more change can be made. It looks three stage is more flexiable, but that can more costly.
Leo Chen - Aug 30, 2006 01:32:12 pm
The Lewis & Reiman design cycle is very similar to the 3 step one presented in class. The L&R cycle goes more in depth, each step has a more specific outline. The 3 step cycle compresses many of the L&R cycle, it assumes the user already knows what to do when designing, evaluating and prototyping.
Jason Shangkuan - Aug 30, 2006 01:49:51 pm
Comment 1: How does the Lewis & Rieman design cycle compare to the three stage (design, prototype, evaluate) cycle described in class? The three cycle design cycle is a very general approach that can be implemented in different ways. The Lewis and Reimann design cycle is a task oriented version of the three cycle design process. The initial questions asking about understanding the user and their tastes apply to design. Plagiarizing, designing, and prototyping applies to the Prototype cycle. Testing and iteration applies to Evaluation. Building a production version does not necessarily fit in the cycle, but it is the end result of the design cycle. Finally, evolution restarts the entire the design process.
Comment 2: Lewis and Rieman suggest that a system should include generic features that users expect even when these features don't play an important role in the system's functionality. Do you think this is always true?
Lewis and Reimann advocate for generic features because of the ease of use and allows for the user to immediately navigate or understand how to utilize the resource the interface was designed for. Whenever I install a new software or application, the first hurdle to using the application is how does the application work (i.e. what do the buttons control, how do I get results, etc..) With every application, the preferences are adjustable, and I change the settings so that they in some way all applications are the same. However, having a standard generic set of features can also take away from the immediate understanding of how to use the product or resource. The extraneous features that do not apply to the application can cause confusion and misunderstanding of what the product can do. Sharing a generic feature set also takes away from learning and the unique identity of the product.
Comment 3: Brainstorming killing by the boss In the brainstorming article by Pauling, it mentions that letting the boss speak first kills the brainstorming process. I do agree that a boss brings a commercial and legal perspective to the conversation because he/she has to protect the best interests of the company. However, if the way the boss begins a brainstorm is managed effectively, it is of great importance that the boss begins the brainstorm. The boss is the interface between his/her employees and the customer or management. The boss understands the requirements and needs and will be able to direct which way a brainstorm should go.
Comment 4: The need for experts in a brainstorm It is also mentioned in Pauling's article that brainstorming is limited and restricted by experts. I do agree that people with extensive knowledge in a subject area do weigh and think about possible implementations, but adding this person's background is not necessarily a negative for brainstorming. If someone can foresee that an idea is completely not feasible then he/she has prevented the company or group from wasting time or going down a path that leads to a dead end.
Eric Yoon - Aug 30, 2006 09:35:06 pm
I was reading the brainstorming article, and there is much that is wonderful in it. But it does beg certain questions, too. For example, the first question I have is: how much must a boss restrain himself during a brainstorm? Although Kelley goes into this to a certain degree, I imagine you could write a whole book on it itself. On the one hand, it sounds wonderful and rather idealistic to imagine a world where there are no hierarchies in the firm and everyone holds hands and sings kumbaya. On the flip side, there are cold realities just around the corner of any brainstorming session: that one member, the boss, pays your salaries. That one member, the boss, can later fire you if work slows down. That one member, the boss, can choose to promote you and elevate your salary ... or not. So there is probably a set of attitudes and policies on promotion and HR that have to complement the brainstorming session, to make it truly effective and truly free-spirited.
The other question I have is -- in the end, SOMEONE has to say, this part won't work and this part does. I know that in the film shown in class, people put colored stickies on cool ideas and voted. Frankly, though, I don't see this being entirely practical in many situations. I mean, if there are 50 philosophy majors and one engineer in the room, the idea will likely veer toward the idealistic and away from technology or cost considerations. Some sense of expertise, training and so on will have to intrude on this pristine, egalitarian model. How exactly that process is structured would be interesting to talk about.
Bryce Lee - Sep 01, 2006 12:07:23 am
The Lewis & Rieman chapter does a good job in identifying the key elements in the design process, however the division of phases are too clear cut. There is a huge gap in between research into the application user and the time when the design is tested out. While the critical input of other design members help keep these in check, along with the mentioned task list, the design is moving forward without further user input during these stages. Also, while adhering to standard interface norms and practices is understandable, plagiarizing an interface may not also be wise. The presence of one design in a commonly used application does not necessarily correlate to a preferred interface.
I strongly agree with the separation of design and functionality as mentioned in step 1.9. The fact that design is so hard to get right makes this step incredibly crucial. Lewis & Rieman frame this step in terms of future revisions, but it also comes into play during team projects. The separation of a truly good interface means that it can be easily reused in another section without much trouble. At my work over the summer, both of these benefits (collaboration and future changes) were highly emphasized.
Bryce Lee - Sep 01, 2006 10:06:58 am
I've found that the effectiveness of brainstorming is removing details to ultimately get to the main point or objective. As "The Perfect Brainstorm" describes, one of the key deterrents against formulating ideas is pursuing one detail, losing sight of the overall picture. The article describes brainstorming as relatively freestyle and unstructured. However, I have found the most useful brainstorming to have come from approaching issues in some sort of ordered way - The ideas are still open, but the path to them and their overall justification are clearer.
Brainstorming's relevance to interface lies in the fact that this type of design is not governed by absolute standards. Human interface is dependent on the user and thus cannot be developed like functionality in a program. This fact makes things such as the "jumps" described in the article very important. This is parallel to searches in artificial intelligence, where a "jittering" effect is added in order to remedy the AI agent from going too far down the wrong pather. Similarly, an open mindset is necessary when thinking about interface, including questioning current norms and standards.
Keenahn Jung - Sep 04, 2006 06:16:58 pm
The Lewis & Rieman design cycle encompasses the three stage cycle fairly well but in more detail, and also adds some stages that do not fit. One part that I especially like, and which doesn't fit into the three stage cycle, is the idea of "plagiarizing." With this stage, Lewis and Rieman suggest that it is very rare for a design to be completely new and unique. Take for example the automobile steering wheel, one of the most successful user interfaces ever. Invented in 1899 (and remaining essentially unchanged for more than a century), the automobile steering wheel was built off of other previous designs such as the tiller and the ship's wheel. The ship's wheel was of course built off of the plain old spoked wheel and axle, which was built off of the solid disc and axle, and so on, dating back several millenia. It is difficult to find a design idea today that is completely original and without this key aspect of plagiarism. Lewis and Rieman acknowledge this, while the simple three stage cycle does not.
I have to agree with Lewis and Rieman regarding including generic features that users expect (even if they play minor roles in functionality) and that this is almost always good design practice. If a designer makes a new product that is visually and functionally quite distinct from previous similar products, then she may take more liberties with the implementation of these generic features. But as mentioned above, very few designs in user interface are truly earth shatteringly unique, and people expect systems that look the same to work the same. Because of this, behavior that is copied should work consistently with past versions "out of the box." Ideally, all UI's should be "backwards compatible" with similar existing UI's unless configured by the user. Take the example of the spell checker, where hitting enter uses the uncorrected spelling in one version and the suggested spelling in the other. This will be extremely confusing to someone who is accustomed to the old and "bad" system, especially if he/she is a fast typist. There is a very delicate balance to be maintained between adding new features so that users can tell that they are using a "new" version, and maintaining existing features so that the users do not have to be retrained.
Keenahn Jung - Sep 04, 2006 06:47:32 pm
Brainstorming is an incredibly useful technique in design for it generates tons of ideas. Having read this article, I intend to get a whiteboard for my room and a lot of scotch tape for attaching my ideas to the walls. One of the most valuable takeaways I got from this is that the space remembers, and that brainstorming is innately physical. All too often, we self-censor ideas, which then greatly limits the number of branches in our decision trees. It is ok to be overwhelmed in the beginning by crazy ideas because they are merely jumping points. There are many paths to the golden idea, but if we start out by censoring ourselves, we may never reach such a path. Of course, it is important to keep in mind that this is but one stage of the process. At some point, perhaps because of external forces (e.g. deadlines), designers have to start pruning the decision tree.
Michael Mai - Sep 05, 2006 01:33:52 am
"The Perfect Brainstorm"
The Dos: Reading over these secrets, I found number 1 and 5 to be the most time-consuming and important parts when I work alone or sit down with a group of people to brainstorm. The overall problem may already be laid out for the group like in school projects, however in order to brainstorm the group needs to discuss which methods they will use to approach the problem. In terms of space, whiteboards and chalkboards are ideal in terms of laying out ideas, so classrooms make great meeting places if you can find a room where you won't be disturbed. As for computers, I've found post it notes to be very useful in laying out ideas. I think you can find them here: http://www.3m.com/psnotes
The Don'ts: I agree wholeheartedly with most of the rules that Kelley brings up in this part of the article. However, I feel that in a group environment everyone needs to participate in all aspects of the project including brainstorming and thus everyone should get a turn. I understand that some people are better at it than others, but it boosts the group's morale if everyone is talking and bringing up ideas at the very beginning of a project.
Simon Tan - Sep 06, 2006 02:00:06 am
I like the fact that, in Section, we are practicing some of the techniques given in the Brainstorming article. Getting physical, playful, etc. Going outside and being competitive. I hope we continue to build on these aspects of good Brainstorming.
Yes, the L&R process is cyclical, which is what I believe we'll be practicing in this class. I'm glad we are, because I find this repeated cycle of getting feedback and improving to bear more fruit when it comes to highly user-oriented projects.
CarrellKillebrew - Sep 06, 2006 04:11:12 am
In response to Perry Lee saying "I understand that taking the plagarism route is safer in most cases; however, how can there ever be substantial innovation if we more often than not err on the side of "what is known" rather than what may be a better solution?" While your point is well taken, I think the point is that unless your system is a substantial innovation, and you think it significantly better than the current norm, you should stick with what the default is. Unless the user is going to find your new solution better and more intuitive to use, then they'll probably just make mistakes since it differs so much from the old system.
Regarding the Task Centered Design Process, I am unclear as to whether they are talking about designing user interfaces for just software programs, or are they talking about desinging user interfaces in general? Because there's a huge library of user interface elements you can use when you are programming a windows application, and they don't mention anything about using pre-existing user interface code. Do they recommend doing your own thing from scratch, or using whats already there? Or maybe use what windows, for example, supplies at first, then develop a more specialized UI?
I don't think they explain in enough detail what the task oriented design process consists of. And instead of saying that the waterfall method is bad, perhaps they should suggest some changes to in instead. As far as I can tell, the waterfall method is a fairly well known and used system, so instead of asking everyone to change how they've been doing things, it would be more useful to suggest additions to the waterfall system that would allow for better user interface creation, but still allow the rest of product creation to follow the traditional waterfall method approach.
About brainstorming, I wish the auther had more suggestions on some of the organizational aspects of a brainstorm. Such as, how many people is too many, or too little? If there's too many people so that not everyone gets a chance to talk everytime they have an idea, is that bad? Perhaps smaller groups should be split up then the ideas are all gone over later? And how big should a group be? I'm sure the auther has some helpful guidelines on good group sizes.
Jonathan Chang - Sep 06, 2006 09:34:20 am
The Lewis and Riemann design cycle includes more evaluation iterations than is suggested by the design-prototype-evaluate cycle discussed in class. Lewis and Riemann emphasize this cycling, treating the entire design process as a constant improvement process, until the ultimate goals of the product are met.
While I like to give users a little more credit, the value of a familiar user environment cannot be ignored. There is a definite psychological impact when a user, who may or may not be comfortable on a computer, feels thrust into a UI where nothing looks the same, and buttons or links that used to be in certain places are no longer there. For that reason alone, it would be important to consider how familiar an interface would be to users.
Yang Wang - Sep 06, 2006 12:06:00 pm
I just think the introductory part on "Figure Out Who's Going to Use the System to Do What " is very interesting. This reminds me of the summer internship that I have done. I have to develop a flash-based web tool for an online real estate company. I created a set of interface that I considered to be very easy to use, and at the same time, very slick. But when we meet together as a group. My interface got scrapped right away. The reason -- "our client will not know how to use it." It turns out that all our client groups are people from 30-50. For them, everything has to be very clear, ex: a button has to be be a gray box that pops out, links has to be blue and underlined. It is because that I didn't consider the target group that I wasted so much time designing an interface that is not usable
Yang Wang - Sep 06, 2006 12:11:40 pm
The second part I found very interesting is "Plagiarize", that it is actually strongly recommanded in the world of interface design. But rather than plagiarize, I suggest that we call it "following the convention". I have a deep interest in web user interface, and thus picked up a book called "Don't Make Me Think". In this book, it is also strongly suggest that we follow the convention of others. Just like the example in the reading regarding spell-check, user tends to think that bolded words are more important, indented lists are sub-category of something. I believe it is very true that we should "plagiarize" when design unless we have something brilliant.
Regarding the question about whether the design always have generic feature. I believe that is always true. Becasue if the feature is something that users expect to be there, it should be there, it will be very frustrating otherwise. For an user never looks through all the features before he decide to use a certain software or hardware. A good example will be apple's mouse. It should have a right click button. It might not be that important, it might be replace with a key on the keyboard, but it is something people expect to be there. And the fact that it is not there is, indeed very frustrating.
Charles Lee - Sep 06, 2006 02:23:31 pm
Task-Centered Design Comment 1: Plagiarizing as a start for a design is not as bad as it sounds. The fact that an interface already exists shows that the former design is at least functional, if not fantastic. Thus it is a good basis to extend from. The initial design was likely not so far off base as to hamper the basic intent of the interface. As well, this path takes advantage of the fact that some users have already "learned" and built expectations around the environment of the old design.
Task-Centered Design Comment 2: Regarding including generic, expected features, whether or not they are directly necessary: I believe this is a good design tactic. Creating a new, alien environment for the user is not making the most of the mental associations the user has already developed. Providing familiarity is part of providing "ease of use" to the user, and it prevents frustrated users from wondering where their missing feature is.
The Perfect Brainstorm Comment 1: I disagree entirely with the concept of a perfect brainstorm. In the same way that different people will approach problems in different ways, they will also develop solutions in different ways. Claiming that one method is better than another is intrinsically short-sighted and not conducive to creativity. It is true that times must be set to ensure progress, but defining hard limits seems silly to me.
The Perfect Brainstorm Comment 2: A main purpose of brainstorming is to quickly gather many ideas of different types. This is why bringing in varied experts with different viewpoints _is_ important, and insisting that everybody records their ideas is the way to get everyone's ideas before they are hindered or shaped by others', or worse, forgotten. Many of these tips seem nice, but i believe the important part is a discussion, then quickly recording all ideas from the individuals as they appear. Some of the other tips seem less important, in my opinion.
Anton Mikhailov - Sep 06, 2006 11:30:43 pm
On the topic of including familiar features, I believe there needs to be a ballance. In most cases, familiar and simple features are a good thing, but if a program is large scale enough and has more powerful/efficient methods of doing a task it is sometimes confusing to add simpler and worse features just for the sake of familiarity. Users may find themselves questioning why certain features exist, and get lost in a sea of choices where there shouldnt be any. In more sophisticated software, you must sometimes take a penalty in the learning curve in order to later get the reward for having a more efficient interface.
On the topic of brainstorming, I found that the biggest key is the proper atmosphere. Although I must say that it is hard to keep this as the company scales. I had the pleasure of working at Google before and after they went public and I definetly noticed an atmosphere shift. As the company grew, the teams were no longer as closely knitted and order slowly began to settle in. Dont get me wrong, the company is still much more loose than some others I've worked at, but the feel I got from the IDEO video was familiar to me from the pre-public Google, something which I feel now is fading.
Oh and by the way, the program I use for post-it's on my desktop is ATNotes. I prefer it over 3com's one because it takes less resources and is overall less intrusive and less prone to crash. Just my 2c though for anyone who likes these things...
Siyan Wang - Dec 07, 2006 03:04:54 pm
Task-Centered Design Process 1: These ideas seem so very obvious now that the course is over. Going back through them I realize how they really helped us develop our project. Although we talked a lot about the design process iterations in class, after having worked on it for an entire semester, I feel like I understand its purposes and its benefits even more. The mockup and testing was very helpful in identifying many flaws with our design and the iteration procedure was invaluable to polishing a very strong final product.
Task-Centered Design Process 2: The "representative" tasks that one must choose to design the interface around seems to be the hardest part of this design cycle. After you've figured that out, roughing things out and prototyping becomes much easier I think. Thus, one must choose the representative tasks carefully. Too broad and the interface becomes a hodgepodge mess. I know from our own group project, our tasks seemed very disparate, but that was because the interface itself was supposed to be fully capable of performing many tasks with the pen-paper interface. I suppose after interviewing the users and finding out their needs this task may become easier, but it seems many people have an idea for something they want to design, without realizing that they are designing for other people.
Brainstorming 1: It seems they advocate more freedom for brainstorming, with very little structuring. This seems like it would generate a lot of ideas, but the freedom is sometimes a little overwhelming. With only the basic premise to go off of, I think it would be intimidating to come up with that many great ideas with your peers. I suppose this is their concept of the comfort zone, and I'm only being overwhelmed with negativity. Their ideas about what exactly the premise should be like seems pretty sound. Building it outwards without limiting yourself does seem like the best way to generate new ideas. Also their ideas about homework before a brainstorming session seems quite creative, and I sure would have liked to have done some of that before our initial group brainstorming session.
Brainstorming 2: I agree with most of their points about what can kill the brainstorm except the first one. It seems like they fall into the stereotype of the boss being the big bad guy who's strict and cracks down. Sometimes the boss can simply be the guy who usually comes up with the best ideas or the most wild ideas. If he starts off, I think it could be a good springboard for further brainstorming. Of course if he isn't brainstorming but is instead limiting creativity, he should be ignored, but many times the boss can come up with genius ideas as well.
Robin Franco - Dec 15, 2006 10:24:34 am
C1: The task-centered design process in the readings is a more detailed approach to the design cycle when compared to the three-step process we learned in class. In my opinion, the Lewis & Rieman design cycle is too detailed. I feel that much of the innovation and creativity that is needed in developing great software and user interfaces comes from freedom. And the three-step process described in class provides that freedom.
C2: One of the problems I found with the Lewis & Rieman design cycle was that it suggests that functionality should be added based on what the user expects. This can be characterized as the intuitive nature of the interface. But I believe there are two different levels to this: 1) Immediate intuitiveness 2) Long-term intuitiveness. For example, the new Nintendo Wii: In the beginning, using the controller was rather difficult for me, so it would not pass the initial “Lewis-Rieman test”. But after some getting used to, the Wii remote was by far more intuitive than the average video game controller.
C1: We constantly hear the term: I'll sleep on it. It's been scientifically proven that many of our best decisions come from our subconscience which mainly are formulated during our sleep. Personally, I would add this “sleep on it” stage to the brainstorming Kelley describes. Maybe ending the day by posing a few questions to the participants, and then letting them mull over the answers for the rest of the day and night.
C2: I've noticed that a lot of the innovation I've come across comes through dialog. And a lot of the initial dialog is not so related to the problem at hand. I could be watching a sports game, be talking about the in-game graphics and overlays, and then suddenly come up with a solution to my UI problem. So one extension to the brainstorming I would add is: don't be afraid to get too far off-topic. Sometimes it lead to surprising results.
