The Design Cycle and Brainstorming

From CS 160 Fall 2008

Jump to: navigation, search

Lecture on 9/3/2008

slides

Readings

Discussion Questions

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

Discussions

Please post your critiques/commments on the required readings below. To do that, first login by using your user name and password, then click the "edit" tab on the top part of this page (between the "discussion" page and the "history" page), New to wikis? Read the Wiki editing guide. . Hint - Please put a whole line == ~~~~ == (literally) at the beginning of your submitted critique, so the wiki system will index, sign and date your submission automatically.

Note

For students who have trouble in submitting their comments, please check this guide on edit conflicts.

Contents


Stuart Bottom 06:01, 29 August 2008 (UTC)

The brainstorm time limit (1-1.5 hours) presented in The Art of Innovation was a bit surprising to me. It seems quite short when compared to sometimes well-known "lock-in" situations, employed when a difficult problem absolutely must be addressed: a leader will assemble his/her team in a room and lock the doors until a viable solution is generated. Initially I had assumed most situations demanding a brainstorm were interchangeable; therefore, why wouldn't a long-winded brainstorm be just as applicable? I now believe this is not the case: for example, a user interface cannot be developed all at once. Some problems are more serious and demand immediate, concentrated attention to a specific technical issue, whereas others are less-well-defined and demand the development of more free-flow or creative solutions. In the latter case, it seems Kelley's approach is more desirable in terms of creating a large number of variegated solutions to choose from in a high-energy but low-pressure environment, making the shorter brainstorm format more applicable to user-interface design.

KevinFriedheim 02:33, 30 August 2008 (UTC)

Lewis & Rieman's (L&R) approach to Interface Design very closely reflects the three stage approach that we touched upon in class; L&R is just a little more specific. It would appear that any variation of the the three stage approach would work and in fact, some variations would be more suitable to specific problems. That is, L&R's task-centered approach might be a bit of an overkill when designing a kid's game. Furthermore, I think it would be safe to say that there is no cut-and-dry way of producing an interface..otherwise we could simply ask a computer program to design it for us. But I think I can agree that no matter the subject for which an interface is being produced, none of the general processes (designing, prototyping, and evaluating) can be skipped entirely.

Jonathan Fong 04:51, 31 August 2008 (UTC)

As Kevin says, Lewis & Rieman's design cycle elaborates on the three stage cycle (design, prototype, evaluate) described in class. The details that L&R give on the first two iterations of the three stage cycle agrees completely with the steps discussed in class. The first run-through of the cycle, begins with the task analysis and brainstorming ("design"), then a rough design/prototype. The "evaluation" is done by the designer, using heuristics and walk-throughs. Then, with the next cycle, the "prototype" a bit fancier, and end-users are brought in for "evaluation". Beyond what was covered in class, L&R continues by discussing iterating on the design after the product is released.

L&R's emphasis on continuing the design process after the product release is confusing. In the initial task analysis, they suggest the importance of keeping the user comfortable by including features that might not be functionally-important to the system being designed. They suggest that someone "might be able to create a novel interaction paradigm that's better suited to [the] application, but the risk of failure is high." Yet, they later concede that "users gain new skills and new expectations" so a design may become "inadequate in a few years."

L&R appears to argue that the user interface design should never force innovative changes onto the user, but should wait for the user to somehow force the change. I disagree. A user interface designer is in the best position to recognize costs of supporting legacy functionality, e.g. a more convoluted interface, increased resource costs (in both development and application run-time). Counter-examples to L&R's position are "Web 2.0" applications/interfaces that are both effective and popular today, Google's Gmail service that organizes emails by threads and/or labels, the Xobni add-on that introduces social networking and fast search to Microsoft Outlook.

To close, some words from Bill Gates: "we [Microsoft] have to innovate. We got to come up with that breakthrough. In fact, the way software works -- so long as you are using your existing software -- you don't pay us anything at all. So we're only paid for breakthroughs."

Buda Chiou 01:09, 1 September 2008 (UTC)

Lewis & Rieman suggest that the designer has to make sure the interface they design can be accepted by its user, but it seems to be impossible. Unless there is only a specific user that we design for, it's really hard to get a conclusion for what is the best. The characteristic, intellegence, and skill of users could be very diffrent, and sometimes the feedback we get from users may disagree with each other. As L&R say in 1.11, the skill and expectation of users may also change, and actually they are easy to change and change quickly. Therefore, the design cycle (design, prototype, evaluate) may never end in order to make the design perfect.

Vedran Pogacnik 01:25, 1 September 2008 (UTC)

L&R are limiting in their thoughts. It is a very different approach from Kelley’s “brainstorming”, which can lead to innovation. L&R seems to prefer the traditional and a user-focused approach, talking about models and adjusting the interface (or some features of it) to the what user knows. I have to agree with Jonathan (and mr. Gates), that innovation and breakthroughs are what we should be striving for.

Anthony Kilman 05:09, 1 September 2008 (UTC)

L&R seem to elaborate on the design, evaluate, and prototype as was described in class. Jonathan's interpretation of the initial task analysis and continuing the design process being confusing reflect my sentiments exactly. Specifically, providing a framework for functionality that will potentially be used in future iterations of a product could be a useful habit, but at the same time should be exercised with moderation. A program solely used to view read-only JPEGs doesn't need a spell checker underneath the hood *just in case* future implementations include tagged metadata.

In regards to L&R's notion of not imposing innovative changes on the user, I believe that moderation again is the key. Hey, it's fantastic if a new spiffy feature greatly simplifies some task; but there is always going to be a learning curve for the user if this feature has never been implemented in the wild. This trade-off must be considered in the design process. Unfortunately, excessive "innovation" can become counter-productive.

Trinhvo 15:24, 1 September 2008 (UTC)

I think L&R is closed to the 3 stage (design, prototype, evaluate) cycle described in class. L&R is more specific and user-focused. I agree 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 because users decide whether products sell or not. The more usable and friendly products are to users, the better.

Tsung Han Tsai 20:51, 1 September 2008 (UTC)

The L&R design process matches the design cycle almost all the way from looking at other products to testing the product with people and improving it. However, the L&R focuses on completing one task, and only that one task. It encourages people to make every feature in the product have to relate to the task to be completed. I am also not sure if the guidelines can be applied to create something new. It emphasizes to use pre-existing products as examples and even says to “stick with what the users know, even if it does require an extra keystroke or two.” (L&R). Other than that, the L&R process would be a pretty good path to take to create an effective conventional product.

A product does not have to contain all the generic features that a user expects. Maybe if the whole user group wanted it, it should be there. But if only half of the users think a feature should be included, the designers can make an add-on or something so that the interface will be as simple as possible for those who do not need extra stuff.

Perry Lee 00:00, 2 September 2008 (UTC)

In The Art of Innovation, Kelley writes that one of the secrets for better brainstorming is to number your ideas. Numbering your ideas "[1] motivates participants before and during the session" and "[2] gauge[s] the fluency of a completed brainstorm." Although I can see how numbering your ideas might result in [1] and [2], I also see a potential shortcoming of using "numbering your ideas". Participants may become more concerned with the quantity of ideas rather than the quality of the ideas (e.g., "Let's hurry up and come up with a hundred ideas so we can get out of here already!"). To me, using "numbering your ideas" seems to cause more harm than benefit.

JoshuaKwan 05:51, 2 September 2008 (UTC)

The L&R approach to UI design is essentially the same as the three-step model presented in class. You can group most of the steps in the L&R process into one of the three Design/Prototype/Evaluate steps:

  • Design: figure out, choose, plagiarize, rough out, think
  • Prototype: create a mock-up
  • Evaluate: test it, iterate (repeating the first steps)
  • Not in the list is something like Develop & Maintain, where you commit to the design you have chosen and then keep reacting to user feedback and updating it; so this would contain the rest of the steps in the L&R approach.

The question about "generic features" is a little controversial. The L&R page gives cut 'n' paste as an example of a generic feature that should always be present. Similarly, you can guess that the File menu, Save and Quit etc. are quite essential. It's true to an extent. It is always good for cut and paste to work, and it is always good to have a quit function (especially if you can use a generic key sequence to activate it, like Ctrl-Q or Alt-F4.) But take games for example; by and large they don't need a "Print" function. Or a spell check function. So the line has to be drawn somewhere; it's NOT always true.

MuQing Jing 06:07, 2 September 2008 (UTC)

I find the L&R process in the user interface design process to be very interesting because it seems to be very straight-forward and industry driven. It is conservative in how hard it pushes innovation, and instead decides to focus more on tried-and-true aspects. For example, I thought it did a good job on emphasizing "plagiarism", which is what it seems like a lot of successful programs/services do nowadays (they take an existing idea and make it better). I do feel that this facet stymies creativity and innovation, but at the same time I do believe that it is effective and noteworthy for programmers to understand.

I found the section titled "Everyone Gets A Turn" in The Art of Innovation to be especially interesting, if not controversial. Kelley makes a good point in that as far as effectively developing ideas goes, a democracy (or a co-op, as some would see it) is definitely counter-productive. On the flip side, I believe that as far as finding an idea to start on, a round-the-table discussion is worthwhile. Once a general or vague idea has been established, the democratic aspect of brainstorming need not be retained in its entirety; a clear leadership/management hierarchy should be put into place in order to effectively and efficiently determine future steps while still taking into consideration the team's input, ideas, and suggestions.

Cynthia T. Hsu 07:24, 2 September 2008 (UTC)

As previously stated, Lewis & Reiman's design cycle is almost identical to the three stage (design, prototype, evaluate) cycle described in class. The Kelley reading seems to be more focused on the designing step - Lewis and Reiman suggest to be able to have a concrete product once you reach the Mock-Up or Prototype stage (1.6). One interesting variant between Lewis & Reiman's Task-Centered User Interface design and what was in last week's lecture is that they emphasize that paper is not just a "low-fidelity technique", but that "concrete product might be as simple as a series of paper sketches showing the interface while a user steps through one of the representative tasks. A surprising amount of information can be gleaned by showing the paper mock-up to a few users. The mock-up may even reveal hidden misunderstandings among members of the design team." I am not entirely sure how comfotable I am with this conclusion. If you have a drop down menu, one of which opens a new window with a new set of hyperlinks, it is difficult to stack two large sheets of papers with intermediate cards representing hyperlinks in between in any way that is coherent. I wonder if this may be a reason why Professor Canny described the major asset of paper techniques to be their low fidelity and suggested more interactive prototyping tools such as HTML, Flash, Javascript, or Visual Basic.

In resonse to Jonathan Fong's confusion about continuing the design process after product release, I feel that Lewis and Reiman are addressing examples such as Microsoft Word and Excel. In particular, Windows 3.1 didn't come with Word, it had Wordpad, which has little more functionality than Notebook. I think that by "users [gaining] new skills and expectations", Lewis and Reiman referring to something analagous to the people fifteen years ago become increasingly familiar with the features that Wordpad had (I don't remember what it was exactly, but I think it included adjusting the margins, making text bold or italicized, stuff like that). Once these features become familiar intead of foreign, it becomes easy to imagine new features of an application: the idea of inserting a picture into a Word document or changing the design of the bullet points, or even automatic bullet points themselves, would have seemed very absurd when features such as Save, Bold, Italicize were very new. At the same time, these very familiar features remained in the same place: although our Word2003 toolbar is much more cluttered, it still looks very similar to Wordpad. The need to continue the design process after product release relates directly to the example of what Anthony Kilman described: "A program solely used to view read-only JPEGs doesn't need a spell checker underneath the hood *just in case* future implementations include tagged metadata." At first, when people are interested only in viewing read-only JPEGs, it wouldn't make sense to implement a spell checker. However, if tagged metadata becomes increasingly common in the future ("as users gain new skills and expectations"), a product that can do both might outcompete one that lacks a spell checker.

Also, as Joshua Kwan says, there must be a line drawn as to what familiar features are retained, but I think familiar "generic features" only applies to specific contextual features. While "Print" is a generic feature that has often (and historically been) seen in Microsoft Office, it isn't actually a generic command to the gaming world, and thus is generally overkill.

However, I feel that in a more heavily text-based game (such as Oregon Trail), it might be nice to have a Print command to retain a record of what happened. I think that this is one of the reasons why Gmail is an example of a user interface that has succeeded despite being "original". In one sense, nothing that they have is very original per se - the threaded discussion, labeling, and archiving is very similar to forum discussions or favoriting websites, while the basic email infrastructure (with an Inbox, Drafts, Saved Mail, Sent Mail link on theleft-hand side) remains very traditional. Although they have features that have never before been seen in email, the elements that make up these features are derived from other user interfaces that the users are already very familiar with.

While I initially agreed that what Kelley described as "Everyone Gets a Turn" to be destructive to brainstorming (I've experienced classroom activities where everyone has to contribute one idea and it's always awful being the first or last person), MuQing Jing's post regarding this subject actually changed my perspective. It's definitely difficult to start a brainstorm when everyone feels awkward and no one wants to be the first to broach the silence. In some ways, starting with an "Everyone Gets a Turn" democracy is very similar to the "Stretch Your Mental Muscles" exercise ; which Kelly says is very useful when a group has not worked together before or when most of the group doesn't brainstorm frequently.

James Yeh 07:28, 2 September 2008 (UTC)

Each stage of the three stage design cycle discussed in class is included in the design process described in L&R. In addition, the book focuses on a task-centered design which puts a heavy emphasis on catering to both the needs and familiarities of the users. The overall process seems to be a solid one that can serve as a guideline for most design projects; however, the book’s preference of familiarity over functionality makes me question if including generic features for the sake of following tradition is practical or cost-effective. I would assume most companies would want to make design decisions that maximize profit, so if an unnecessary generic feature isn’t predicted to increase a product’s sales, then no, it wouldn’t be included.

Haosi Chen 19:19, 2 September 2008 (UTC)

L&R's approach to Interface Design is very different to Kelly's "Brainstorming". L&R is preferring the traditional and a user-focused approach, which means we should build and adjust the interface base on what the user knows. On the other hand, Kelly's Brainstorming approach is more open-minded and creative. I agree with Lewis and Rieman's suggestion 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, because user interface is really depend on the user, and should as precise as possible to fit what the user wants.

Jordan Berk 20:57, 2 September 2008 (UTC)

L&R's process is fairly similar to what we discussed in class. As Joshua Kwan pointed out, the respective steps described in each method can be mapped in a way that aligns the two methods to the point of extreme similarity. L&R just happened to be more specific and elaborate more on certain steps, specifically the user acceptance parts. Speaking of user acceptance, I don't think that all "standard" features need to be included. The basics, yes, but to include all is probably overkill in almost all cases. On the other hand, not having expected features, useful or not, can lead to unwanted user frustration, even if the task could be completed in an alternate way, possible one the designer considered more intuitive.

Greg Nagel 21:59, 2 September 2008 (UTC)

The reading by Kelly is an eye-opener for me. One of the difficulties I've found in group work is to try to get everyone interested and participating. Mostly the aim is a democratic process, but under time constraints, it collapses to direct assignment of tasks. The democratic approach never works because it takes too long to make everyone participate and people have different strengths. Direct assignment leads to boredom--meaning progress is slow or non-existant--because individuals don't feel like they're involved in the project as a whole. A brainstorming session could allow each group member to participate as much as they want and to watch or help ideas evolve.

Alan McCreary 22:08, 2 September 2008 (UTC)

I found Kelley's discussion of brainstorming very interesting. The idea of incorporating more than one of the five senses during a brainstorm seems especially useful - coming up with ideas while just sitting at a desk can be pretty boring, and boredom isn't too good for the imagination. In response to Cynthia's comment about the awkwardness at the start of some discussions: I think this awkwardness is often the result of a low comfort level amongst the people in the group - a classroom, for instance, usually has people who aren't familiar with everyone else, as well as a teacher, who adds extra pressure. In groups like this, Kelley's suggestion of a "group warm-up" seems appropriate. Once the members of a group become comfortable enough in each other's presence, there shouldn't be a need to start out with an "everyone gets a turn" roundtable discussion.

As Vedran pointed out, L&R's design process is more clear-cut and doesn't appeal as much to the imagination as Kelley's approach to brainstorming; and I agree that this brainstorming process leads to more innovation. However, it's important to know that innovation doesn't always lead to success. New, creative ideas in a user interface can be well-received, but there's also a good chance of failure, as L&R point out. (Microsoft Bob, anyone?) So while coming up with new ideas is important, L&R's approach should be a good, safe bet in most cases.

Juanpadilla 22:51, 2 September 2008 (UTC)

The three stage cycle described in class is pretty much the same as the one described by Lewis & Rieman. They are similar in that they both use task analysis to get the required tasks for the system as well as they both build a mock up of the idea first on paper or some other means to ensure the proper fit to those tasks. However, Lewis & Rieman were more specific. For example, they described only using a subset of tasks as representative for all the tasks that the system will do but they also mentioned that if a task comes along that does not fit with these representative tasks, it might be necessary to throw it away. I found this in particular, difficult to go with because it is often the case that as the system progresses, customers will come up with new tasks that they didn't think of before; often these are tasks that are not similar to those already built into the system. So is it the case they are suggesting to tell the customer that it can't be done simply because you can't fit it into your design?

As for the suggestion that you should add generic features that users expect even when these features don't play an important role in the system's functionality, I think this is just wrong. First having a feature that does nothing or next to nothing is not only a waste of time and money but it is often the case that they user gets even more confused for the simple fact that they are used to that feature being more robust or having more of an impact in their other applications and may not trust that your application is stable or robust enough for them to rely on.

Antony Setiawan 02:27, 3 September 2008 (UTC)

In my opinion, L&R's task centered design process pretty much resembles the three stage process. 1.1-1.5 touches on the design process, while 1.6 illustrates the prototype process. 1.7-1.11 illustrates evaluate process. 1.11(Change the design), however, seemed to be out of place in my opinion. Changing the design would waste all the effort made on the preceeding two steps. The perfect brainstorm that is discussed in Kelly's article would leads to a better design process compared to L&R's step 1.1-1.5. The brainstorming process would prevents the change of the design in the evaluating process.

Wheter a system should include non-critical generic features or not, I would say depends. Excessive features bloats the system excessively. I belive that users will be more comfortable with a compact interface that "does its purposes" rather than having a complex interfaces with so many unnecessary features. It is hard to determine whether a feature is important or not because each people has his/her own preferences. I believe that evaluation process would help sorting this matter.

Karen Tran 03:29, 3 September 2008 (UTC)

I agree with the many answers above that the three stage (design, prototype, evaluate) cycle that we talked about in class last week is an overall summary of the Lewis & Rieman design cycle, described in reading Task-Centered Design Process Chapter. They both start out with the analysis of the task; from there, the brainstorming of the design can take place through careful selection of the most essential, representative tasks. Followed is the building of the user interface and lastly, testing the design with users – or what we call “evaluation” in lecture. The L&R design cycle extends further and describes how to track the design by actually contacting the users after the design has hit the street. From there, they could get feedback and then based on those comments, they could alter the design in such a way that it would be even more beneficial to the users. Personally, what I liked most about the chapter was the idea of stripping the problem down to the most essentials, the most representative. I think, as software programmers, we tend to automate and generalize the system too much. That is because we frown upon hardcoding. I think by coding the most symbolic tasks, we have the best of both worlds; that is, we have something that is specialized to only that system, but at the same time, that something is representative enough to be treated as a generic framework.

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. I think that, while, from a user’s point of view, this idea is nice because it provides the users some familiarities, it is a waste of time and effort. Like I said previously, stripping the problem down to its most essentials is the best way to approach the design of the system. If we populate the interface design with too many generic, non-important features, it might have the negative effect of confusing and leading the users away from the system’s main purpose.

Kai Lin Huang 04:22, 3 September 2008 (UTC)

In general, the outline of Lewis and Rieman design procedure is similar but more detailed to the 3 stage cycle described in class. However, the main difference is that Lewis and Rieman do not specify whether this procedure will be reproduced when doing later changes, and thus it implies some of the steps in the procedure may be skipped or changed in the redesign process.

Copy and paste functions are important in ordinary systems, but in UI perspective, they don't necessarily appear on it. I believe it is not always true that a system should include generic features when these features don't play an important role in the system's functionality. If these generic functions are expected by users, then there is a need for these functions. If they are not even expected by users and not useful at all, such as placing copy and paste in a simple flash shooting game, then the exclusion of generic functions in this case will not post any dread of difficulty in use.

Wenda Zhao 04:38, 3 September 2008 (UTC)

L&R design process is pretty much a more specific version of three stage (design, prototype, evaluate) cycle. Both of them break down to a cycle of three fundamental steps which are design it, build it and refine it. And Both of them would work fine for most given user interface projects. I also agree with with L&R that a system should include generic features that users expect even when these features don't play an important role in the system's functionality. User's requirement is most important element in building a successful application in my personal opinion.

Mike Kendall 05:40, 3 September 2008 (UTC)

I'm not sure if I should have read the other responses before reading my own, since my answer to the first question is exactly Mr. Kwan's, though I think that his formatting is probably better than mie would ever be.

With respect to generic features, I have to say that I think they should almost always be there. When I am using a piece of software and don't have copy/paste available to me, it's frustrating. I can go as far back as being annoyed whenever I couldn't tab through fields or ctrl+tab through windows. Safari drives me nuts because of its non-conventional keyboard shortcuts. Personally I think it's poor design... But in the Apple paradigm (get people dependent on our products and make our products co-dependent on eachother), it makes more sense.

This article only reminded me of a meeting that I had about a month ago about a programming project. At this meeting, I was trying hard to get a mock-up made and get a true feature list going, but the facilitator couldn't get past the idea that his coder (who didn't know php) was going to be collaborating with me and that we had to figure out HOW to collaborate... But this paradigm seems to agree with my priority which was figuring out WHAT we were collaborating on. Rant over.

Gary Wu 05:41, 3 September 2008 (UTC)

I feel that that L&R's step of testing the design with users (1.7) to be a bit flawed. When testing the design, there should not be any member of the design team conducting the tests. From experience, I noticed that people tend to subconsciously guide the user unknowingly when asking the user to perform a task. However, I do wholeheartedly agree with the "thinking aloud" technique and even watching a video tape afterward to further analyze the entire process.

I found that the 6 ways to kill a brainstorming session to be invaluable information. I know I've been a victim and a culprit of these vices. One thing I was looking to get more out of the article was how to tackle the subject of choosing the ideas that have been brainstormed. Would a democratic vote be the best bet, or following the idea of a few experts be the better alternative, or even just having the boss choose?

Billy Grissom 06:03, 3 September 2008 (UTC)

I thought that the L & R Design Cycle was pretty similar to the 3 step method we discussed in class. Granted, the L & R cycle is a bit longer but at the core it seemed to have the same underlying message: have a plan, keep things simple and test, test, test. I couldn't agree more with this idea. All too often we get too caught up in making the next "big thing" rather than what's the must usable thing. For example, the Microsoft quick menu thing that the professor pointed out in class mirrors exactly what L & R says about the need to make this necessary rather than "flashy".

I also believe that what L & R mentioned about having a good sense of communication between users and developers is key. As a tester myself, it is very true that there's often many bugs or inconveniences that you simply dont catch yet users do. Why is this? Well like L & R says it's because users often have a different experience level with the programmer than the developers and testers. Testers like me, for example, spend a lot of time with the program and thus have certain expectations that aren't necessarily spelled out. A standard user, however, may not have quite as much experience. As a result our expectations that were implemented can often come as complete confusion to a basic user (ie the Microsoft thing up above). I think L & R makes a good point of getting the message across that the whole design process really is a cycle...in the sense that it's kind of never ending. I think this is something that the 3 step method in lecture lacked in. The 3 step method in lecture seemed to be more of a "you make it and release approach" while this cycle seems to be more of a "you make it and then improve it approach". Nevertheless, the two cycles seem the same for the most part.

As for the idea of generic roles I think that this truly is always true. If an applicaiton provides some of the generic features of eithe ran OS or similar programs then it makes it that much easier for the user to ease into the interface that you've built. All too often there's been interfaces that I've used where it's utterly confusing. Sure it looks pretty, but all of the key strokes (like copy and paste), button positions, and other things are all different form other apps I usually work with. Granted, you don't always want all of these general functions to be reproduced....yet you can't deny that you always want at least some of them. For example, say you're making a game. Chances are copy and paste won't do you much good gameplay wise, but nonetheless you'll probably still want the windows key to open up the start menu.

I also think this idea of generic implicit functions goes hand in hand with what they said about plagiarism. I think it's good for programs to build upon one another and improve and expand off of that. I think the general idea of user interfaces can be applied to the cycle described here. For, it's not only individual interfaces that grow but others that take that grow off of that as well.

Paul Im 06:36, 3 September 2008 (UTC)

The design cycle in Lewis & Rieman is fairly similar to the processes we discussed in class; one source produced more detail on certain topics than the other. Lewis & Rieman discussed the analysis that we should do before we build a prototype in order to make sure that our design isn’t impossible to create. The lecture contributed more to the testing phase; it talked about low-cost versus high-cost techniques, such as doing a quick expert evaluation versus doing a complete user study, respectively.

I believe that generic features are a good suggestion, as long as they don’t interfere with any of the system’s important features. If a certain generic feature should logically produce a different outcome more appropriate to the system’s functionality, then its generic functionality should be removed (e.g. ctrl+c may be more appropriate as a ‘color’ function rather than a ‘copy text’, for a graphics application).

The Perfect Brainstorm discusses many logical, practical ideas for brainstorming. It gave many good insights to having a successful brainstorming session (e.g. warm-up activities).

Jeffrey Rosen 06:11, 3 September 2008 (UTC)

Both L&R and class advocate thinking about what you want to accomplish with the UI, mocking it up and testing (first using paper, then using say, HyperCard), then actually producing it and iterating on the design until it is satisfactory. As a personal response, I feel like paper testing is quite dated in light of modern UI frameworks. It is hard to imagine getting accurate data out of a paper mockup in an interactive game and the time saving is negligible.

Furthermore, I am surprised multivariate testing is not mentioned, which IMHO is critical in UI design. That is, testing your interface with a variety of predefined permutations and collect data according to concrete goals (e.g. the amount of time it takes for someone to start a new game, for instance, or more capitalistically, how many people click the BUY button) and statistically deduce which permutations are best. Eliminate the worst performing permutations, introduce new ones, and repeat. This way, you can scientifically evolve your UI rather than leave it up to subjective interviews with a small number of people. I suppose you could argue that you can build the variations to perform the multivariate experiments on would be chosen through laborious paper testing and interviewing.

In response to the second question, yes. You should always implement everything according to the UI guidelines of the OS, for instance. It is extremely annoying to the user when you want to resize something that looks like it could be resized but it just doesn't work. Or you try to paste something into it but the designer didn't think about that. Even seemingly small things like implementing a text field on Mac OS X where ctrl-d doesn't perform a forward delete. You might think who uses ctrl-d in a text field? Well, Apple laptops don't have forward delete keys, so ctrl-d is actually reasonable. A less esoteric example would be not assuming that someone with a screen reader would go to your website and not making it accessible.

Frank Yang 07:37, 3 September 2008 (UTC)

In regards to the L&R reading, I too found it similar to the processes we discussed in class, and L&R simply elaborated on certain topics. L&R simply focused more on providing some ways to actually execute each stage of the 3 stages mentioned in class. In regards to the emphasis placed on user feedback by L&R, I wholeheartedly believe that the usability factor is an incredibly important part of designing anything. Anything that is all flash without the function behind it does not achieve the goal. I believe that Microsoft fell victim to such accusations when Vista was released as many people saw it to be just unnecessary flare. However, in regards to Vista, after their newly released "Mojave experiment" ads, it reinforces the factors of the customers' willingness to change, as mentioned in L&R.

In regards to the generic features, as mentioned before by many others, the practicality of the feature itself must obviously be considered for each case. As mentioned before, copy and paste shortcuts should not be expected to work when playing a game that requires no text input, nor should the shortcut ctrl+s be a suitable command for one to save his or her game in a first person shooter as it might in a text editing application. However, I do believe if the generic command is expected enough that it would annoy the user, it should most definitely be kept in an application.

In regards to The Perfect Brainstorm and some comments above, I agree with the article in that the "Everybody Gets A Turn" rule would be indeed counterproductive. However, I do believe it is a shame when the best ideas go unsaid due to a fear of being shut down or simply breaking the ice. I feel like this is exactly what happens in discussion sections and lectures every day. I, for one, am a victim to it myself. However, I feel that with the proper warm ups, as mentioned in the article, and proper preparations pre-brainstorming session, these problems can easily be avoided. I also think that perhaps if one is unsure about throwing an idea out on the table, he or she could run it by someone else just for some feedback before throwing it out in the brainstorm to avoid such a case.


Michaelczhang 08:15, 3 September 2008 (UTC)

I agree that the Lewis & Rieman design cycle seems to just be a fleshed out version of the three stage cycle described in class. The Lewis & Rieman design cycle simply elaborates on the particulars of the process and how each of the three stages should be accomplished.

With regards to the generic features, I do not think it is always true. If resources can be allocated to implementing a generic feature that users expect, and that generic feature offers enough utility to users to make the implementation worthwhile, then it should be included. Otherwise, it is simply a waste of time and resources to include something that has no purpose for users anyway. If users aren't going to benefit from something at all, then even if they expect that feature to exist, it shouldn't need to.


Stepan Grigoryan 08:18, 3 September 2008 (UTC)

Lewis & Rieman put a lot of importance in accommodating the users. They believe that it's more important to have a somewhat working system that the users already understand and are more comfortable with than to try to improve the product, to find an alternative way to do the same task. I don't think I agree with this approach. If we never changed or modified the product, then we would be stuck with same old product and the same old ways. Users can adopt and they can adopt much faster that Lewis & Rieman give credit too, especially if the new way makes more sense. I understand that there is a high risk involved in trying to create a new approach or a new design. However, in my opinion, most of the times the designers have a better understating of the system and then next steps involved in creating a better product than the users. A designer will have a better idea of how a new feature or method should behave than a user. Therefore, it is essential that the designers look for a better and easier ways when possible instead of just sticking with the same old idea and with something that "works" .

Jimmy Nguyen 09:22, 3 September 2008 (UTC)

The two design cycles compare well in that after many cycles of the approach described in class, you may end up crossing a lot of similar steps simultaneous as if you did the other cycle. The main differences is that L&R is more descriptive at each step along the cycle, i.e. at the end of the cycle, it explicitly says to build it, track it, and to change it, whereas the design cycle described in class takes everything into groups. I believe that the class design cycle is a better idea because there is no set path in terms of designing a UI, but rather modifications will have to be adjusted throughout the whole process according to the situation. The thing that I do like about L&R is that it says explicitly to iterate, track and to change the design, which I believe to be one of the most important parts of UI design in general. I guess it could fall under Acting out and Walkthroughs in the class model, but the idea of getting every possible scenario should be emphasized.

I don't think it's ALWAYS necessary to include generic features when they are not as important. An example I can think of a website does not always include links to the contact info or even other links, when at times they are more of a hindrance on a design or something. An example is when I'm grouping things into a Menu, but there is something that is alone or insignificant to a group, despite