The Design Cycle and Brainstorming
From CS 160 Fall 2008
Lecture on 9/3/2008
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?
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.
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 the fact that it could be considered generic.
Kumar Garapaty 09:43, 3 September 2008 (UTC)
The design cycle discussed in class tended to be more generic compared to that of the one in L&R but both conveyed the central themes of design, evaluate and prototype. L&R went into more detail on how to go about designing, evaluating and prototyping. The addition of generic features is not always necessary especially when adding these features takes away the time to build other more important features and create an unnecessary cost. I found the Kelley article on brainstorming extremely interesting. However, does brainstorming always have to be done in groups, is it possible to do brainstorming alone and then collaborate with group members?
Shyam Vijayakumar 16:15, 3 September 2008 (UTC)
Recently, I had the chance to attend a usability testing session. There were 2 rooms separated by a two-way mirror. My colleagues and I were able to see what the user was doing on his computer while he was testing out the product, but he couldn't see us. The user's eyes were also somehow connected to some mechanism that allowed us to see what on the product drew his attention. Specifically, two red dots, representing his eyes, showed up on the screen, which allowed us to see what on the page he was reading and what he got stuck on when the red dots stopped moving. These testing features were not discussed in the reading, but I thought they were important factors. The user was asked to think aloud and was also videotaped. These features were mentioned in the reading and were equally important in the testing process.
Kevin Lam 18:56, 3 September 2008 (UTC)
In agreement with what's been previously stated, the L&R article provides a more detailed coverage of the same design process discussed in class. The "iterate" phase of the L&R model brings to mind the Extreme Programming (XP) concept discussed in the Software Engineering course (cs169) taught here at Berkeley. With XP, you follow a process similar to the Waterfall model but work with smaller scopes, thereby allowing you to iterate the process more frequently. Although iteration is an important part of the design process, it isn't always an option as is the case with building large, sensitive products like satellites. With satellites, you are only given one opportunity to launch the product but more importantly the interface between the satellite and the ground stations must work once the product is launched.
Finally, regarding the addition of expected, but unnecessary features I don't believe it's necessary to add functionality to an application simply because users expect it to be there. Take, for example, search engines in the early 21st century (i.e. MSN, Yahoo, and Ask) that loaded their sites with news, sports, and advertisements - content that added to the user experience but were not used by everyone. Today, many sites such as Google are taking a more user centric approach by allowing users to customize their pages (i.e. iGoogle).
Geoffrey Lee 19:41, 3 September 2008 (UTC)
In regards to L&R's opinion that generic features should be included... I think this really comes down to standardization. In "The Design of Everyday Things", the author mentions that when a user interface is flawed and can't be improved, the next best approach is to standardize. For example, the placement of keys on a keyboard is rather arbitrary and not necessarily optimal, but standardization around the QWERTY layout allows this interface to be practical. In L&R's example, people always expect to be able to cut & paste through a specific set of steps. But one important point to note is that they say the cut & paste feature is "not important", but not necessarily unused.
Xuexin Zhang 01:18, 4 September 2008 (UTC)
Lewis & Rieman suggest that the design process should focus more on the end users than the three stage (design, prototype, evaluate) cycle described in class. User satisfaction plays a very important role in Software engineering, as it’s a business seeking for profit. I agree with Lewis and Rieman’s idea; by focusing more on the end user, software engineers could make sure that users satisfied with the user interface which leads to success.
Personally, I believe that system should include generic features that users expect for the same reason as the last question; by putting in those generic features, software, as a product, could more appealing to its end-users or rather customers.
Mikeboulos 05:13, 4 September 2008 (UTC)
ps: I posted on the 3rd it is still posting the 4th:
Lewis and Rieman is very related to the three stages (design, prototype, evaluate) cycle as described in class. I think that Lewis and Reiman gave us a good guide as of what to expect when designing, we mostly jump into programming and design on the fly because we think we have a good understanding of how it is going to look like, but this is not always true. The iteration process is where we loop back in the design, prototype and evaluation cycle.
"interactions with users can also yield surprises about other applications that have been found for the product, possibly opening up new market opportunities." (L&R) This is very true and is very important, we might design something that we might think it is brilliant, but the user's feedback is what is most important. The success of a certain program depends not only on the reliability of it, but also if it is usable, and This step is also critical in keeping the program maintained and up to speed with other projects that have been developed with competing companies.
as for the second question, I agree to some point that some of the functionality should be generic, this is because the user will feel more comfortable with the system and will feel like they know what to click or select next, even though they are still learning, it is like learning how to swim in shallow water, usually they put bars on the sides, you won't drown in shallow water, but the bars makes it feel like as if the water is more safe. also the user might use these features to interact with other programs, for example, cut and paste is not essential in some programs, but it is nice to have if we need to copy some information and email it to get some support.
Nathanyan 09:05, 4 September 2008 (UTC)
note: I'll post comments on the The Perfect Brainstorm later, as I can't seem to access it now (what login do we use for it?)
I thought Section 1.2 in Task-Centered User Interface Design might be somewhat dangerous. I can see how a "representative task" might be a good way to get to thinking about how the system may process through a real-life situation, but I would be worried about a task like this dominating the mindset of the designer, especially since it comes so early on in the design process.
For example, one of the representative tasks was "produce a salary budget for next year" for a spreadsheet program. It feels like there's a very strong potential there for the design to focus on making a good budgeting program, and leave out all the other functionality needed for a spreadsheet program. Or waste a lot of time implementing many budgeting-specific features. Maybe that's what makes a good designer can do - think in terms of a specific task while keeping in mind the general scope of the project. But introducing representative tasks seems like a dangerous thing to do, especially for an untrained designer.
Section 1.3 for palgiarism seems like a pretty obvious thing to do, but honestly something I've never seriously though about. It makes a lot of sense to implement the same layouts and keys across the board for similar products/similar functionality in different products. It's something I wished a lot of other software would do.
Witton Chou 09:53, 4 September 2008 (UTC)
The the development cycle described by Lewis and Rieman is one that takes a basic problem and builds around a basic solution each time. The basic solution may be drawn from other existing solutions but are built up and improved in various ways with each iteration of the design cycle. The three stage cycle described in class of designing, prototyping, and evaluating is pretty much the same concept except in more detail with respect to how to carry out the brainstorming process as well as how to critique and improve upon current prototypes.
Throughout the design cycle iterations, however, it is very important to be able to recognize any flaws as well as favorable characteristics to reduce or build upon, respectively in order to improve the interface interaction. In these situations, brainstorming plays a major role as Kelley points out. There is no bad idea besides an idea not said. There are many ways to improve the brainstorming process, from numbering all ideas to physically drawing or moving around.
It is always a start to entertain the idea of encorporating generic features one would expect but at some point, these features may not be entirely necessary. To some extent, there will always be relationships to generic designs as they are intuitive and foster comfortable useage. Thus, I don't think it is necessary to include generic features that are insignificant. However, the presentation of these design concepts may be drastically altered.
Hao Luo 07:26, 8 September 2008 (UTC)
This post is late. Oh well, I thought I was supposed to post a comment by the next lecture. That's life.
The development cycle in the reading has the backbone of the three stage cycle described in class, but it goes into more details with more stages. For example, plagiarize, which wasn't explicitly mentioned in the three stage cycle although it could very well be considered part of the design step. So in a way the LR cycle is simply elaborating on the three stage cycle.
A system should include generic features that aren't important to the system itself only if such features are relevant to the system. For example, if I were designing a game like Minesweepers, a feature like resizing the window makes no sense and should not be included. But if I were designing a game with text input, then it makes sense to include generic features like copy/paste for the user's convenience even though such a feature is not essential to the system.
Bing Wang 05:31, 17 September 2008 (UTC)
The post is late but I have emailed the GSI regarding this.
Lewis and Rieman's design cycles are very interesting and is exactly what we have been going over in class. One of the things that striked me was plagarism. When I first read the subtitle, I thought they probably don't want us to copy other things which is the case in every single class; however, in this case, it is totally opposite. They hope that we can build upon some interfaces that works and has been tested. In a sense, maybe not morally, it is true that copying something that works is a good idea for user interfaces. If the interface you are trying to copy is well known and has been used by many, it's likely it is a successful one. Maybe I shouldn't have used "copy", it's more like borrowing someone else's hand to make your work successful.
I like the parallelism that the author drew between business planning and user interface planning. User interface planning is important and it is somewhat business related. Most poeple who creates user interfaces are for business gains. An easy to use user interface sometimes differentiates a success and failure at a business entity. To tie in user interface with business planning is important because if you can generate more users to use your interface, your business will be more successful.
