The Iterative Design Cycle
- The Task-Centered Design Process. Task-Centered User Interface Design. Chap 1. Lewis & Rieman
- The Perfect Brainstorm. The Art of Innovation. Kelley.
- Case Study: Apple, Design, and Business Bill Buxton, Sketching User Experiences
Bhavin Modi 22:56:03 9/5/2014
Reading Critique on The Task-Centered Design Process The topic says it all. The chapter can be summarized as depicting the entire process step by step to effectively design interfaces, the do’s and don’ts. This author in this chapter focuses solely on the task centered design process and gives us a very practical and probably the first view on how to create an interface accepted by all. The mains ideas focused on are keeping the users in mind and what is it that we want to accomplish by creating this software and the target audience. The project should be the well divided into tasks specific to each functionality we wish to create and incorporate features so as to accomplish those tasks. One major thing to remember is that programming is one of the last steps in this process, effective design, strong collaboration and regular meetings amongst and with destined clientele is a major chunk of this process. The design is always bound to change, iteration, the tasks build it, track it and change it encompass that idea clearly. A point worth noting was Plagiarize (not in the typical sense). Wherever legal and useful copy or try to imitate user interface paradigms. People do not like change a lot especially when they get comfortable with certain actions, so maintaining those paradigms would make the most sense, like the copy paste example given. The risk of introducing some new method is very high, one should try and stick to the legacy features unless they have something unique to offer. A new paradigm that could make reduce the effort required for that task. One should be careful and the idea should be well debated. Another point was about prototypes, they are best way to communicate your work done so far, your ideas and the users will a clear idea what they will be getting or if any feature is not to their satisfaction or misinterpreted. The task centered design process is one of the many way to design software, in this case we are talking of interfaces. The other models like the waterfall model, iterative model, prototyping model and the rapid action development (RAD) model can also be used. But each has its set of benefits and disadvantages, as shown about the waterfall model. As an example, in some cases to get the product out to the market is a major time constraint and so we may like to use the RAD model. All this depends on the various constraints faced in the commercial environment. To conclude, the Task-Centered Design Process is effective, takes care of issues raised, aids in decision making and evaluation as the system is being developed.
Bhavin Modi 22:56:40 9/5/2014
Reading Critique on Brainstorming The author clearly focuses on one thing, Brainstorming as an art. It is the heart of this editorial, the importance, need, methods, and things to keep in mind while brainstorming, everything has been covered. The main idea of a brainstorm is to let ideas flow, they can be your wildest imaginations, be creative without restrictions. When you are in your comfort zone with no classification among the members, it creates an atmosphere conductive to the flow of ideas. A hundred ideas in a single one hour session is quite a feat, and rest assured at least 10 of them will be just genius. Getting a different perspective on problems or topics really builds to your knowledge and certain problems are solved by a mix of ideas from different individuals. After reading it, many of my own misconceptions about brainstorming where cleared up. I used to believe brainstorming was to solve a problem specifically, with a narrow approach in my mind, which the author clearly mentions is not right direction and can kill a session. The seven secrets and the six ways to kill a brainstorm cover all points where one needs to focus. The point of spatial memory was something that got my attention and also prototyping and show and tell, are the other good ideas. Clearly, brainstorming is a platform for innovation in a manner, to solve problems and promote collaboration at all levels in an industry. One should work on his brainstorming skill, because I am convinced this skill is an asset everyone should possess. Its importance cannot be undermined, as it is pervasive at all levels in a company be it marketing, designing, policies etc. What other better way is there to showcase yourself and prove you are smart, with out-of-the-box thinking to gain the respect and impress your peers? A great insight to the concept of brainstorming, with hardly or no roam to correct the author. It is spot on and a must read. “The best way to get a good idea is to get a lot of ideas”- Linus Pauling.
Eric Gratta 11:17:44 9/6/2014
Task-Centered User Interface Design (1994) Clayton Lewis, John Rieman The authors present what they call “task-centered user interface design” essentially as an alternative to the prevalent method at the time, called the “waterfall” model of software design. Although the focus of this chapter is elaborating their suggested design process, what it does is address the pitfalls of the waterfall model that they believe occur when interface designers are handed down specs from systems analysts and lack direct contact with and understanding of users and their tasks. The most significant advantage to the task-centered approach is that the interface designers are constantly keeping in mind the user, their needs of the system, their physical environment, and their daily workflows. Only well-informed designers have a chance of making a stellar product that matches perfectly the needs of its users. Another advantage to the approach is that it saves time by being iterative and cautious in nature, by having the design actions take place in order of ascending commitment to features of the design. Programming is the last thing that should occur because it requires the greatest time investment and changes at the program level are much more costly than changes on a paper mockup or digital wireframe. I’m not sure what significance this book as in the history of design literature (i.e. if this is a seminal work), but from my own industry experience this IS the paradigm by which software developers work. The design of an application or feature starts at a user need and involves constant interactions between a design team and users, task domain experts, and other experienced designers to keep the interface in line with user expectations and consistent with paradigms for low-level interactions. Since I am already trained in working via this model, there wasn’t much new information. However, I did find it interesting when it was mentioned in section 1.9 that UI code can often be more than half of the code devoted to an application. Reflecting on my own work, I would believe it if this were true! It’s pretty incredible how much effort needs to go into preventing an interface from limiting the user by being unintuitive. Very often, terrible applications actually do most of the things you want but are just confusing to use. --------------------------------------------------------------- The Perfect Brainstorm The Art of Innovation Kelley This chapter from the Art of Innovation addresses what the author perceives as a common misunderstanding of brainstorming – that you learn how to do it as a task, rather than develop it as a skill. The chapter explores tips on how to do it well, mostly by encouraging freedom of thought and working visually/spatially, as well as common pitfalls, again mostly involving the restriction of mental freedom and freedom of verbal exchange. The author is trying hard to convince the reader that brainstorming will bring many benefits to organizations that infuse it into their culture, and also implies that your daily life will feel enriched by frequent brainstorming. The benefits implied include a continual sense of mental flexibility and inspiration to solve daily problems. Earlier this year I attended a GTD or “Getting Things Done” talk at the company I was working for. The speaker was trying to encourage the employees at my company to do brainstorming and do it the right away. One suggestion that she made that has stuck in my mind was “allow yourself to imagine that your wildest dreams are possible”. You find that if you apply this concept of your “wildest dreams” to even the simple and the mundane, your mind gets excited by fanciful and unconventional ideas. You can often find ways to improve what you hadn’t before considered something that needed changing. The message of this author is very similar, but they enumerate very specific ideas for successful brainstorming in a group setting. The emphasis on visual and diagrammatic brainstorming was also emphasized at the GTD talk I attended. I think one part of the equation that should be addressed in this chapter is how to encourage the enthusiasm of your brainstormer participants. There are many times where a meeting is held that intended to be about discussing interface ideas but the levels of pessimism prevented a productive session from occurring, even when all of the requirements described in this paper had been met (a wide variety of people were present, everyone had done their research). The comments tended to focus on what was wrong with the current ideas than how we could change them or come up with new ideas. Perhaps the leaders of those meetings needed to follow the advice about momentum and the tapering of momentum, drawing attention away from the critiques and building upon promising ideas.
Yanbing Xue 19:05:11 9/6/2014
The second paper is mainly about methods that will keep brain storms creative and effective, and also about the good effects that brain storm will bring about. At first, the author mainly talks about some tips to make brain storms innovative. The first tips for brain storms is an edgy problem, which helps concentrating on the core question. The second tip is allowing wild ideas, indicating we should not criticize others too soon, for criticism exhausts passion. The third one is separation of ideas, which splits the ideas into tips and helps people move around in the ocean of whimsies. Besides, idea numbering also helps even when the brain storms are over. The fourth tip is build and jump, indicating that sometimes it is a great idea to move back to a former idea when we are having difficulties with plateau of our minds. The fifth tip is utilization of spatial information. The sixth tip is an intuition between group members improves effiency. The seventh tip is getting physical. All the tips seems straightforward and convincing, however, the only thing making this paper imperfect is the lack of clear definition. From the very beginning, the author proposed the importance of clearity. However, many definitions or edges are lost, making some tips not so feasible. For example, the second tip allows wild ideas. But, what is a "wild" idea, and what is the threshold between "wild" and "ridiculous"? There is hardly a uniform standard for every one.
phuongpham 14:40:23 9/7/2014
The Task-Centered Design Process: this is a book overview chaper introducing steps in a Task-centered design process The chapter introduces some new and interesting points. Designing a system should start with a real task which users will do in their real life, not from a functionality aspect of system developers. The task will come with user expectations as well as user's basic skill to use. Existing interfaces already (partly) defined user expectations and we should follow the community convention in the early phase. Otherwise, the new design must be tested using standard evaluation methods. GOMS is (widely) used as a tool to evaluate strength and weakness of designs in the community. There are protopying frameworks supporting prototype design process. The design is built to change (it needs to be changed frequently). After releasing phase will raise more opportunities for new applications as users gain new skills and expectations. However, the chapter also raises some questions. Do we have standard evaluation methods to measure how good a design is compared to others? How should we deal with a system used by everyone, e.g. web browsers, or a system offers new experience, e.g. the first iPhone? Does the representative tasks (use cases) selection process have a formal method? What are (possible) weakness of the Task-centered design process? For example, what if the Task is not well defined because it is a new one, no users completely understand it but they need an asistant system. It seems all feedbacks are taken subjectively from prototype users. Some scientific models as Human-Model processors could be used to get limits of feedback from the reviewers (as mentioned in Usability objectives). As shown in the optional reading, industrial design and user-centric product help Apple to become a strong company after a fall in their company. This is a strong evidence that industrial design, human model play an important role for technology products especially when all competitors have the same functional technology. And iPod follow the principle in this chapter where Apple design team kept getting feedback and improve iPod's design until the big hit in the 4th edition. *** The perfect brainstorming: this book chapter gives best practices for conducting team brain storms. What impressed me most is numbering ideas. I have never done this before and think this is very useful for tracking as well as traverse between ideas. Another point is getting to the next power curve quickly to keep the energy up. Besides to-do things, the chapter provided 6 not-to-do things which are also interesting. In general, this brainstorming approach has many similar points with the task-centered design process. They focus on a particular user task (representative tasks, sharpen the focus) rather than start from the system's functionalities or organization goal. Understanding the real problem, i.e. contact with end users or show-and-tell, is mentioned in both readings. They also emphasize on quick prototypes to get feedback and validation. However, the chapter has not mentioned about how to prepare before a brainstomer, how to nuture idea production during a brainstomer in case everyone keeps quiet.
Yanbing Xue 17:31:39 9/7/2014
The first paper mainly talks about the steps of a typical task-based design process. Usually, there are 11 steps in a typical task-based design process: figure out who's going to use the system to do what, choose representative tasks for task-centered design, plagiarize, rough out a design, think about it, create a mock-up or prototype, test it with users, iterate, build it, track it and change it. The first step is figuring out who's going to use the system to do what. This is obvious because, according to what we have learned, we have to know the user group and the goal we intend to achieve. Since the user group is the H of HCI, while the goal is destination of I. The second step is the choice of representative tasks for task-centered design, which is also the core part of task-based design process. The reason we select a task is simple: sometimes it is hard to grab the core parts or pitfalls of a goal. But with a typical task of a system, this seems quite easy. For example, a typical task of a word processor may be "transcribe a memo and send it to a mailing list", a typical task of a spreadsheet may be "produce a salary budget for next year", a typical task of a communications program may be "login to the office via modem", a typical task of an industrial control system may be "hand over control to next shift". However, some sub-titles of these steps are quite vague, even controversial. For example, the author titles the third step as "plagiarize". Although the author tries to explain that the third step is not plagiarization, some people, especially those who just skim this article, may still misunderstand the author's purpose.
Nathan Ong 20:42:52 9/7/2014
Reading Critique of "The Perfect Brainstorm" from The Art of Innovation by Kelley This chapter from the book explains three aspects of brainstorming: how to brainstorm, why brainstorming is beneficial to a company and its employees, and common brainstorming pitfalls to avoid. The notion of brainstorming is prevalent in the American education system. From a young age, teachers often engage students in a primitive form of brainstorming, generally for analyzing a book or generating solutions for a simple problem. In secondary schooling, students use brainstorming as a tool for coming up with essay and project topics. Generally, in all cases perpetuated by the educational institution, brainstorming is a tool used when one has no ideas. None of these relate to Kelley's belief of how brainstorming should be used in the real world. Kelley believes that brainstorming should be a tool used on an at least monthly basis in order to solve company issues, spur innovation, and keep employees satisfied while moving the company forward. A brainstorm, according to Kelley, focuses on quantity rather than quality, allowing freedom of creativity to solve a particular real world people-problem, with the end result focused on a few solutions. While Kelley makes a good case when arguing that brainstorming can benefit a team emotionally, I believe he does not provide any motivation for using brainstorming more often. In my personal experience, brainstorming is used as a last-resort tool. Whenever someone runs out of ideas, he or she brings people together to brainstorm. If someone encounters an unprecedented and unfamiliar situation, he or she brings people together to brainstorm. If a company is failing even after exhausting most of its resources in the attempt to restart growth, high-level executives often brainstorm. Brainstorming, in my opinion, should not be the first tool, but instead, intuition should be the first step in seeking a solution. The majority of problems can be solved using intuition because they tend to be problems that have been solved previously. There is no sense in wasting time to brainstorm for solutions to problems that already have effective solutions. What use is brainstorming when it leads to solving a problem in the same way? Even if brainstorming leads to a new solution, why waste the time to look for it when a solution already exists? It does not make sense to apply brainstorming as a method for general problem solving. Had Kelley changed his focus on where brainstorming should be applied, he would have made a better case for using brainstorming on a more frequent basis. Brainstorming should be used when a problem has not been explored in depth and where previous solutions are not good enough for practical usage. Innovation should not be wasted on finding the same solutions. Reading Critique of "The Task-Centered Design Process" from Task-Centered User Interface Design: A Practical Introduction by Lewis and Rieman Lewis and Rieman provide an overview to the "Task-Centered Design Process" (TCDP) design methodology as a way to develop software with an eye towards creating user interfaces. Organized in a consecutive series of steps, both authors present a rational method for software development starting at a software's inception and ending at the continuing need of software update. Almost as a foil to Kelley's chapter on brainstorming, the description of the TCDP focuses more on the intuitive and rational aspect of software development. Unlike in Kelley's brainstorming, the TCDP requires that solutions via software features must pertain directly to the set of problems, or have the set of problems be altered to include the proposed software features. In addition, Kelley's brainstorming allows for all types of solutions, favoring quantity over quality. Much of this becomes wasted effort as many of these ideas are discarded. In addition, Kelley believes brainstorming can be applied to all types of situations, which is again producing wasted effort. In problems that already have effective solutions, there is no need to brainstorm or spend time thinking about new ideas. Lewis and Rieman also advocate for this, since a "new solution" to an already solved problem may not provide any benefit, even if it is better. As stated in my previous critique, Kelley lacks focus on using frequent brainstorming, believing that a brainstorm can be the catch-all solution to any type of problem. Lewis and Rieman do not propose that their TCDP be the process for solving all problems, but rather a good series of steps for a software's life cycle. The two authors know when using the TCDP is most effective, and do not uphold it as a panacea to life's problems, making this chapter much stronger than Kelley's.
Nick Katsipoulakis 9:20:46 9/8/2014
The Task-Centered Design Process: This article presents basic guidelines for task-centered user interface design. The need to identify the end user and the tasks that they are going to perform is very important. Not only the software has to fulfill its original purpose, but also it has to be friendly and easy-to-use. Hence, a thorough understanding of the users’ previous knowledge and the context in which the software will take action is needed. Task-centered design proposes picking a list of representative tasks and trying to analyze them in the design process. These tasks are often tasks that have been requested by the users and should cover (as much as possible) the full spectrum of the software’s functionality. Another advice presented in this article is to plagiarize, in the sense of following the same solutions in design as other software that users might be using. This will minimize the work effort during the implementation of the software and users are going to be more familiar with. In addition, the need to rough out a design is important. This is advised because during prototyping, many binding decisions are made. Also, determined functionalities have to be supported, according to users’ needs. Furthermore, procedures like GOMS analysis and cognitive walkthrough will reveal crucial information about the software’s usability and will lead to improvements. Creating a mock-up and presenting it to some of the users can reveal many hidden misunderstandings to the design team. Testing is another important part of the design process, in which real users are asked to perform representative tasks. At this point, users’ experience needs to be recorded and evaluated in order to retrieve important indications about the system’s usability. Iterating over the software’s design is an important role towards success. The design member’s need to re-evaluate the software and balance the severity of an error with the time it takes to resolve it. Building and tracking the design are two important tasks. The design team should be in touch with other teams in order to ensure that their goals are met throughout the development process. Finally, changing the design will extend the software’s lifetime. This is important since tasks, users, technology, and needs change. The best way to get a good idea is to get a lot of ideas In this document the brainstorming process is addressed. The author defines it as an important process that will give birth to new ideas. The need to sharpen the focus of the brainstorming group is important so that useful opinions are expressed. However, ideas should not be too specific and product-oriented; the focus of an idea has to concentrate on users’ needs. Also, the rules of a brainstorm session should not be strict and the group needs to be encouraged to express “wild ideas”. Moreover, numbering ideas and motivating participants to state their thoughts is desired. Building on an initial idea to give birth to new concepts is a good approach. Similarly, not being afraid of jumping back and forth will most certainly guide to new approaches. An important way of keeping track of the thinking process is to enforce spatial memory of the group, so that jumping from one view to another is easier. Mental muscles need to be warmed-up before the session starts, so that participants have already reached the proper mental state for generating new ideas. Finally, getting physical is encouraged during the brainstorming process, by bringing competitive products and/or materializing prototypes on the fly. In addition, this article presents some pitfalls that people need to watch out for. Usually, a boss might take a driving role in the brainstorm process, which is not desired since it might constraint people’s thoughts. Everybody needs to participate but not in an orderly fashion; brainstorming should be an abstract. Sometimes, expertise might get in the way of novel thoughts and prohibit new ideas from expanding. Brainstorming should not necessarily take part off-site and time needs to be spent on meaningful ideas. Finally, writing down everything and not actively participating in the thinking process is counterproductive in the sense of brainstorming.
yeq1 12:39:22 9/8/2014
Yechen Qiao Review for 9/8/2014 Task-Centered User Interface Design A Practical Introduction Chapter 1: The Task-Centered Design Process In this chapter, the authors had provided a brief description of what task centered design process is about and what are the typical steps for doing it. The approach stresses the importance of choosing reprehensive tasks from reprehensive users, understanding of interface design, and rapid prototyping. While the paper did not cite the sources, they obviously had cited previous experiences from interface designs and software engineering. In the last class, we have covered how Xerox PARC had established the GOMS model, and this model is again mentioned in this chapter as a way to deliberate on a model design before starting to run costly prototype evaluations. I also think the authors are correct in pointing out that we should know about our users, and should not provide an interaction that is conflicting to the ones users are custom to. In earlier models of human processor and the simple keystroke model, the authors did not take these into account. I think design re-use (a.k.a. Plagarize) is good not only because it allows interface designers to come up with an effective high-level interaction paradigms in shorter time. It also allows the users to improve their interactions outside the system. For example: if all apps developed for iOS requires “home” key to return to home screen, and “volume” keys to change the volumes, the experienced users no longer have to think about the app they are running before pressing these buttons, effectively reducing the interaction time required for the tasks “back to home” and “change volume”. In fact, some companies such as Apple has specific interface guidelines so that the users are being provided a consistent user experience. Also, I believe the authors were correct in pointing out whether to plagiarize would depend on user and task variables such as frequency of use, their experience and knowledge, and similarities of the app interface with those users typically use. The counterargument for conformity is that it reduces the freedom for interactions in specialized apps, and it discourages the developers from coming up with more innovative interface designs using these buttons. The rapid sketching and prototyping, and the encouragement for the “Wizard of Oz” emulation techniques brings similarity of this design process and that of XP. The cost of evaluation is usually high, and both of these practices focuses on reducing the time between evaluations. And both of these techniques focuses on the evaluation. The difference is that XP is usually evaluating the quality of all functional and some non-functional requirements, while this technique is mostly centered on improving the user’s interactions (the “ease of use” category and some others). As a result, the text stress the need for user involvement in almost all steps, even after the product is put on the shelf. I find it somewhat difficult to relate this to design privacy controls for users. There are two main problems: security is almost always a hassle for users, and users generally do not have the domain knowledge necessary to complete a task. So far, the models we have covered all assumed that the users are well educated with the domain knowledge necessary to complete the task, even though they may have never used computer before. However, security and privacy are often specific to a system and an institution, and the users usually use them not because they like to fiddle around with security and privacy controls, but because they are either concerned about security or the admins told them to do it. For those that are concerned about their privacy, they are usually ill-informed and this often results in a suboptimal use. There are also very few examples we can just “plagiarize”, and most of the widely used designs are not yet proven to be effective or easy to use. The Art of Innovation The Perfect Brainstorm In this chapter, Kelley and Littman have discussed how to brainstorm and how not to brainstorm. The arguments they make mostly draws from their experiences working in IDEO with some of their clients. Tom Kelley, as a general manager of IDEO, is widely known as a good consultant. He summed up that brainstorming should be focused on a problem statement, and that people in the team should not be constrained by short term goals. I can confirm this with my experience. In our lab, sometimes we have a sudden brainstorming session. Depending on whose problem it was, we have different styles of brainstorming. There is a person who would get directly into math expressions and equations about machine learning, and would continue to talk about possible theories and hypothesis. I cannot recall a single successful brainstorm from these sessions. However, the others would brainstorm mostly the right way: they talk casually, they are focused on the problem but not with either research papers or math expressions, and they write the ideas on the board (no numbers though). The brainstorms are simply much more fun to work with. While these are simply anecdotal evidences, I still think the authors are largely correct. Brainstorming is important in many engineering areas. They are usually related to coming up with a solution to a seemly open problem. Once the brainstorm is done and done correctly, the rest of the work are usually more tractable and we can generally see incremental progress (if the team do not slack off…). The brainstorming for me is usually the most difficult part of a project, and I had worked with many of them in undergraduate and graduate classes and research. I believe brainstorming is usually the most difficult part of a project, and being able to do it the right way is important. Sometimes, an idea came up during a brainstorm was being worked on, evaluated, and then proved to be infeasible or not what we expected. As this chapter explained, there is not necessarily a problem with brainstorming procedure itself. Sometimes another brainstorming session is required once a theory or a hypothesis is invalidated. The authors described the need for continued exercise for brainstorming. I think this may help getting unstuck early, but potentially at the expense of less spent on tractable work.
Brandon Jennings 14:34:02 9/8/2014
The Task-Centered Design Process: This is a book about task-centered design process. It discusses the design process and breaks down the process into steps on using the goals of a system to influence how the system should be designed. This book is important in the field of technology because it is a blue print on not only designing a system, but also covers non-technical topics that are as, if not more, important as the technical topics. The book talks about critical things like getting in touch with the user and understanding the user’s requirements and using them design the more effective system. The book also discusses how to document development of your work, management of an organization, and even legal issues like copyright. As engineers and computer scientists, many times we do not consider the non-technical aspects of system design. One thing I would have included in this book was real-world examples. It had some examples through out it, but I would have liked to see real engineering and business practices, both effective and ineffective. This would give the readers a better understanding of why these steps and guidelines are important. The reader would be able to relate the content to real life and see the consequences of bad practices. I do appreciate the exercises at the end. I found them to be engaging and important to give the reader insight into what the book is talking about by having the reader participate in a mild form of the process. The Perfect Brainstorm: This article is about brainstorming and how it can be a developed skill. Many people believe brainstorming is just a quick monthly session, but it is in fact a skill one can practice and become good at. This article is relevant to not only today’s technologies, but to today’s business practices. What I like about the article is that it defines and spells out specific steps to improving brainstorming sessions. This technique of brainstorming can increase productivity and lead to more creative and innovative solutions than traditional meetings where one person runs the show and others respond. In addition to explaining how to brainstorm, the article describes ways to hinder a brainstorm. This method makes brainstorming less like work and more like a creative session. It allows for everyone to shine and offers a more incubator-like environment. Over all I like the article, thought I had a couple grievances. I would have liked to see this technique implemented in other organizations. The article speaks of this brainstorming technique from experience within IDEO, but that does not necessarily mean that these steps are effective. I agree with the premise that there is more to brainstorming than sitting in a circle, but this method has not been proven. I also disagree with the second way to kill a barnstormer: everybody gets a turn. I understand the idea is not to have everyone speak for a limited time, but it is important to incorporate everyone’s opinion.
SenhuaChang 17:01:16 9/8/2014
The Task-Centered Design Process This article gives us an overview of the task-centered design process and give us the steps in this process, the steps are very typical, which can be used as reference in many other design process. For example,Step1.1 Figure out who’s going to use the system to do what is very important in every design. And Step1.7 and 1.8 Test the Design with users and iterate are also important. User experience plays a key role in System design, based on users’ reviews, details, even a big part of system should be change to cater users taste and need. In Task-Centered Design Process, step 1.2 is special, step 1.3 is interesting. We can learn a lot of thinking of design from every steps of the process. Which I like best is the step 1.3 plagiarize. Learn from what has existed really can save time and get inspired. --------------------------------------------------------------------------------------------------------------------------------------- The Perfect Brainstorm I pretty like the first sentence-“the best way to get a good idea is to get a lot of ideas.” This sentence seems to be the fundamental of brainstorm. Every part of the article point one of the important rule in Brainstorm, but it seems like lack good example to support author’s point. For example, in the second part, what is a wild idea, what’s the definition of wild in here; and in the fourth part, an instance about how to jump will better express author’s point—build on and idea or take a jump is good. The idea of stretch mental muscle looks great and a good example is used to support the opinion. After reading this article, I realize how awesome the brainstorm is. I think I’d like to practice it by myself in the following project.
Qihang Chen 17:11:07 9/8/2014
The Task-Centered Design Process. Task-Centered User Interface Design. Chap 1. Lewis & Rieman This chapter gives an overview of the task-centered design process, which is structured around specific tasks that the user would want to accomplish as the system is being developed. The steps in the task-centered design process are as follows: 1) figure out who's going to use the system to do what: The is obvoius because your software is designed to accomplish specific tasks and serve specifc customers. If your target user is wrong or your functionality is irrelavant to what is needed by the customers, then your software is just a piece of trash. 2)choose representative tasks for task-centered design After establishing a good understanding of the users and their tasks, the task-centered design process takes a more concrete approach. The designer should identify several representative tasks that the system will be used to accomplish. 3)plagiarize This means finding existing interfaces that work for users and then build ideas from those interfaces into your systems as much as practically and legally possible. 4)rough out a design The rough description of the design should be put on paper, which forces you to think about things. But it shouldn't be programmed into a computer (yet), because the effort of programming, even with the simplest prototyping systems, commits the designer to too many decisions too early in the process. 5)think about it This is so obvious. You need to think! 6)create a mock-up or prototype 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. 7)test it with users Of course your need to do test with users because they paid you! 8)iterate you can't finish your product at one time even if your are a genius. build it track it change it ------------------------------------------------------------------------ The Perfect Brainstorm. The Art of Innovation. Kelley. This article basically just tell us the importance of Brainstorms and how to do that in the perfect way. The problem with brainstorming is that everyone thinks they already do it, so what makes a brainstormer sing? Most people are familiar with the fundamentals—like sticking to one conversation at a time and building on the ideas of others—but it takes extra effort if you want a great brainstormer with valuable results. And there're SEVEN SECRETS FOR BETTER BRAINSTORMIN: 1)SHARPEN THE FOCUS 2)PLAYFUL RULES 3)NUMBER YOUR IDEAS 4)BUILD AND JUMP 5)THE SPACE REMEMBERS 6)STRETCH YOUR MENTAL MUSCLES 7)GET PHYSICAL
Zhong Zhuang 17:27:50 9/8/2014
This article is introducing a new paradigm of designing user interfaces. Instead of the traditional “water fall” paradigm, this article brings this new term of “task-oriented” design process. As the term indicated, this new paradigm will be centered by a bunch of tasks that the users will use the system to do, and build the user interface based on these tasks. The author elaborates his point by dividing the design process into eleven steps and explaining them one by one. The most inspiring part of this paradigm is the first three steps, it first survey the users to find out what tasks are they expecting from the system, and then it selects representative tasks, by doing this, it realizes the abstract user study to a vivid and practical picture, then the rough design of the interface will be based on asking questions about these representative tasks. The third step is plagiarize, this topic is controversial, people has been debating on whether we should follow the market main stream or be creative, my point on this is that, in the interface designing world, creating a brand new way to interact with computer is normally not a good thing to do, you should stick to the way that every people is using every day, because interface is all about being easy to use, users will not want to change their way of using an everyday tool regularly. But by saying this, it doesn’t mean that we shouldn’t bring new idea into interface design ever, I think the interface design should looks like the evolution of creatures, one small but firm step at a time. The rest of the article is typical interface design paradigm, basically it follows a iterative way, prototype-test-evaluation-refine.
Xiaoyu Ge 18:18:08 9/8/2014
The first article “The Perfect Brainstorm” is mainly concentrated on talk about Brainstorm. In this paper the author first talk about what is a brainstorm and why is brainstorm so important to the enterprise. Then the author was focused on two important aspect of brainstorm, one is how to make a good brainstorm, the other one is what pitfall should we avoid in making brainstorm. In able to make a good brainstorm, the author introduces seven tips which he believe can make the brainstorm better. They are 1. Sharpen the focus 2. Playful Rules 3. Number your Ideas 4. Build and Jump 5. The space remembers 6. Stretch your mental muscles. 7. Get physical. Also for avoid pitfalls in brainstorm, the author brings six tips, which shouldn’t be doing in the brainstorm, and they’re 1. The boss gets to speak first 2. Everybody gets a turn 3. Experts only please 4. Do it off-site 5. No silly stuff 6. Write down everything. Before read this paper I’ve had couple brainstorm experiences before, however after I read this paper I realized some mistakes I’ve make during my pervious brainstorms, especially, I think “everybody gets a turn” and “experts only please” is the most useful tips to me, since based on my own experience I truly believe that in a brainstorm we should invite people from each level so that the idea we come out can represent more people’s needs and therefore benefit people more, and don’t force every people to speak is also important in brainstorm, I believe forcing people to speak will reduces people’s interest in attending the brainstorm. Moreover reading this paper also gives me confidence in attending future Brainstorms, because the author claims that he believe brainstorm is a skill and therefore can be practiced. Due to above reasons, I think this paper is very useful to me. The second article is “The Task-Centered Design Process”, basically this is an introduction chapter to the book “Task-Centered User Interface Design”. In this article, the author introduced a process so called “Task-Centered Design Process”, which can make the software interface design more effective. In able to introduce this process, the author divide this process into 7 steps. They are: 1. Figure out who's going to use the system to do what 2. Choose representative tasks for task-centered design 3. Plagiarize 4. Rough out a design 5. Think about it 6. Create a mock-up or prototype 7. Test it with users 8. Iterate 9. Build it 10. Track it 11. Change it. For each step, the author use a brief description to explain what this step means. First step means we should perform analysis before we start design the product this can help us to make sure the product is on the right track. Second step tells us that before we start our design we should focus our initial design on some major tasks which users described to the designers. The third step means that we should take any currently available recourses into our design. The fourth step let us know that we should draw the design on paper, since this can help us to rethink the design. The fifty step tells us to exam the design before actually design it, so that we can decrease the risk of failure. The sixth make me realized that it’s important to make a prototype, therefore by showing the prototype to user we can avoid some misunderstandings of what user’s truly needs. The above six steps are useful tips to reduce the risk and cost of actual implantation. From step 8 to step 11, the author are focus on how to build a successful interface after the design phase. The main point in these four steps would be to keep match the user needs, therefore always be ready to change or give an update to your software. This requires the software to be developed using OOP method. After read this article I found this article is quite useful to me. It remands me some important concepts of software engineering.
Wenchen Wang 18:41:40 9/8/2014
The Task-Centered Design Process Summary: This chapter introduces how to design a system. There are 11 steps to do design process for detail. Paper review: I think this chapter’s content is part of software engineering, through requirement analysis, choosing representative tasks, sketching the design, creating a prototype, testing it, building it, tracking it and then changing it. Every step is equally important. The book mentioned UIMS to create prototype. I googled UIMS and it is a mechanism for cleanly separating process or business logic from GUI code in a computer program. UIMS are designed to support N-tier architectures by strictly defining and enforcing the boundary between the business logic and the GUI. Nowadays a lot of software companies have product feedback, such as Apple, Facebook. Feedback is a effective way to track the design after the product hits the street. The designers could get a deep learning about customers/users’ real need. Changing the design is to meet customers’ new needs. Almost every success product has different versions, such as mobile apps and operating systems. It is a manifestation of changing the design. The Perfect Brainstorm Summary: The paper introduces a comprehensive view of brainstorm. It mainly discusses how important brainstorm is, how to do better brainstorm and what ways could impair brainstorm. Paper review: Brainstorm is a group or individual creativity technique, which is very effective for coming up with idea. The paper mentions seven secrets for better brainstorming. To better brainstorm, first we should start with a clear statement of the problem focusing on specific customer service enhancement. Second we should turn aside critiques, instead of turning off critiquers completely. Third, we should come up as many quality ideas as possible. Forth, try build on an idea or takes a jump, to keep the energy up. Fifth, leave as much the space as possible. Sixth, to do some warm-ups before brainstorming. Seventh, do brainstorming regularly as stretching exercises for your mind. Nowadays a lot of brainstorming application are invented to help better brainstorm. For example, Freemind applies some of the seven secrets mentioned in this paper. It starts from a central idea, has large white space. Then you can expand it with different branches which are then elaborated. This paper gives me some inspirations for my current project about fault-tolerant real-time control system. We usually just came up with one idea to talk about per meeting. When the idea is killed, we went to the next idea. It’s not very efficient that we should think about as many ideas as possible first, then to look at how possible they are.
Longhao Li 20:09:27 9/8/2014
Critique for Brainstorming The main idea of this article is to show how to do brainstorm for ideas and how to maximum the power of brainstorm. It include lots of tips that needs to take care with when hold a brainstorm session, which is very valuable suggestions. When people want to solve problems, they need to think a lot to find the appropriate solution. But single person’s power may need a lot of time to get it and sometimes people even cannot find the solution by themselves. This is the common problem that most people are facing. Brainstorm is a good idea to solve this problem. Doing brainstorm is easy. A group of people gets together to discuss and find out ideas. By correctly doing it, it will be easier to find a good idea. But how to do it in the right way and find some good ideas is hard. This article contributes a lot of ideas that can help to hold a successful brainstorm session. It suggested how long is appropriate for a brainstorm session. It also suggested six ways to kill a barnstormer, like boss talk first, and write down everything. By Avoid these pitfalls, I think people can do a great brainstorm session. Thus, I think it is a very important article for the people who want to do brainstorm. Also in my experience, I used to be benefited from brainstorm while I am doing a class group project with classmates. We sit together and speak out our personal ideas. People doing discussions on the ideas that just came out. It is very interesting that when you doing brainstorm, you may get more ideas than thinking by yourself. Most of the ideas that we find out are great. We choose the best one and make it real. I think we did great in the project. I think we may not be able to achieve that if we didn’t do brainstorm at the beginning of the project. Thanks for brainstorm. Critique for Task-Centered User Interface Design In general, this article talked about task-centered user interface design and detailed steps that needs to follow. It also included suggestions in the steps. The biggest contribution of the article is the great interface design steps that designer can follow. Using this task-centered method, I think designers can design the interface faster and also make the interface better to use. It is because that based on task, designer can achieve not only the beauty of allocation, but also great usability. Doing test of the design with people who are similar with the target user group will help the design aiming to their goal. Also the on paper design and prototype test give the designer enough time to adjust the design to the best fit style before turn it into the real object. By doing it on this way, people can save a lot of time on modifying the design since when it become a real thing, it will be harder to adjust the design compare to on paper design, since it needs to adjust the code, and code is more complex to change. After reading, I find out that parts of the method that the article talked about are similar with the methodology that are used in software engineering. For instance, the iterate step are quite similar with the method used in software engineering. During the development of software, developers needs keep changing their overall design to make sure that they developed the right software. In this case, I think once the development involved human subject, modifying and testing on humans will become a big part in the process, and it will become the key to achieve the goal of the project.
Xiyao Yin 23:25:02 9/8/2014
' The perfect brainstorm ’ shows the effectiveness of brainstorms and provides several reasons to support his idea, including seven secrets for better brainstorming and six ways to kill a brainstorm-er. If people want to make their group more productive, they should make it brainstorm more regularly and effectively. Brainstorming is a treasure in our society. However, inappropriate methods will limit people’s imagination and creativity during a brainstorm. The most impressive idea in this paper I find is not to let the boss get to speak first. It is a common phenomenon for a boss is always to speak first and it is normal for employees to follow the boss’s agenda and boundaries in my hometown. I have attended such brainstorm several times and none of them bring great new ideas in the end. What’s more, those brainstorms are all filled with critique and debate ideas. People spend too much time discussing just one topic and finally it will not be accepted because of too many hypothetical problems. I think more people in my hometown should read this paper. ‘The Task-Centered Design Process ’ contains eleven steps to describe the general process in a task-centered design. It is similar with the normal process on designing a system I learned in Software Engineering in my undergraduate class. During the seventh step, the author provides the idea that there will be problems that only appear when the designed is tested with users. I agree with this idea. However, during my undergraduate class, I found another important thing that although user’s idea will help the designer to find errors, problems and surprises, the designer should not show everything to the user. Since users are mostly unfamiliar with detailed techniques in designing the program, designers need to prepare much more information to show the relationship between each part of the program, which will waste a large amount of time. Furthermore, user’s misunderstanding in some information will bring much more trouble to designers, which should be concerned during contact with users.
Wei Guo 23:36:20 9/8/2014
Review of The Perfect Brainstorm Wei Guo This paper points out people’s incorrect interpretation of brainstorms. Besides the definition of brainstorm, it also gives seven tips for better brainstorming, and six tips to ruin a brainstorm. It also gives the effect of brainstorm. Brainstorm is an opportunity for group teams to understand ideas, solve problems for budding up later. The seven tips are: make your topic focus on a specific customer need or service e enhancement instead of on some organizational goal; do not critique or debate ideas which will waste the energy of brainstorming really quick; it is always good to number the ideas in case you need to jump back or motivate the teams; Brainstorm energy curves show that a light touch in the first phase, and let ideas flow during the steep part is good to keep plateau; make a medium visible of ideas to the group can better use the spatial memory, which is more powerful than simply say the idea; we need to know whether we need a warm-up for a group before brainstorm, and which kind of warm up (clear mind or content-related homework) we need; include physical feelings when doing the brainstorm. Brainstorm helps people to have a wild mind, have a different approach when facing a problem, and also help the team members to get a chance to be a star. However, there are six things we should pay attention, otherwise the brainstorm will be ruin: don’t let the boss speak first; do not force everyone speak in turn; do not just include experts; do not always do the brainstorm off-site; exclude silly ideas; do not write down everything. By reading this paper, my former experiences of brainstorm are no longer actual brainstorm experiences. Mine seem to be so informal. However, according to my understanding, brainstorm is just a way for us to get ideas to solve problem. Do we really need that much rules to guide it? As long as we can come up with ideas, it will be a good brainstorming, right? I would like to join a formal brainstorm as described by the author, and see if it is really that stimulating. Review for The Task-Centered Design Process Wei Guo This paper gives us an overview of the task-center design process. It lists eleven steps to describe the process, from understanding user need to the final design comes out. The most interesting part to me is step 3: plagiarize. It is so abrupt as if it is a proud to copy. I do think copy the existing similar code or interface and others can save us time, save us efforts. I just kind of surprise by this “shameless” saying. Another thing I would like to say is about step 10 and 11: track the design and change the design. I used to work as a web-programmer. We normally need to spend one month or so to build up a small website. However, the change according to the users may take much more than one month. The maintenance of the website and the update of the software and content will stay during the life time of the website. In my opinion, another step called maintenance should be added.
Mengsi Lou 0:27:23 9/9/2014
The Task-Centered Design Process. This reading material indicates main steps of the task-centered design. The process help developers to manage a design project systematically and improve developing efficiency.---------- 1. The first stage ‘Task and user analysis’ equips the designers with adequate knowledge of users’ and product’s background. 2. After the knowledge established, the second step is to ‘choose representative tasks for task-centered design’. The designers should select some tasks that will cover nearly all the functions of a system. It is a more concrete way compared with the traditional way of building up abstraction and specification of the system and user interface. 3. Then, here is another different step before design by their own – ‘plagiarize’. In this step, designers will find some existing successful cases that are similar to their aim product and take these ideas into their product in a reasonable and legal way. The benefit is to make the developing adventure lower and also make the product appears in front of users in a more acceptable way. 4. After referencing on other products, designers should make their own design, including adjusting other products’ function and proposing new features. 5. Then the design is roughly built, so the next step is to ‘think about it’. This timely reflection may take them to discover both strengths and weaknesses then adjust them. 6. Now the preliminary scheme is built up, we can try to ‘create a mock-up or prototype’ using prototype tools. The prototype is the foundation of final product. 7. Expose the design to users and get the feedback. 8. Iterate. When getting the problems from users, designers will make adjustment based on both the cost of change and the severity of problem. 9. Here come the true ‘Build the design’. The key of building is to build it for change, which means modular is needed for easy change later. 10. Track the design after building. 11. And also change the design to catch up with the tasks and users demand. ----------Here I’d like to talk about some interesting points that are different from my previous knowledge. 1. The main idea of the whole process is that designing is more than implementing. Obviously, the first 8 steps are all affairs related to design, and implementing comes after the adequate backup. After implementation, we should get the feedback from users and may have to redesign again. Thus, a good design is an indispensible base for a successful product. 2. In software engineering course, we get the traditional ‘waterfall’ model is to begin with system analysts’ identifying requirements without interface designers’ participation . But in the interface design field, it is a poor approach. Because designers need to start from the very beginning and know tasks and users’ background better, make abstraction better and then get a better design. ----------Additionally, I think we may need to consider the third step ‘plagiarize’ critically. Taking parts of the successful cases is good from the perspective of saving costs and reduce adventure. But we may not take it as much as possible. It should also take the practice and also the aim of products into account. Some functions may look awesome in their product, but may turn out to be useless and unfavorable. What’s more, design need innovation. Never stop trying new ideas and make the design wonderful. /////////////////////////////////////////////////////////////////////////////////////////// The perfect brain storming. This article tells about the brainstorm, including 7 points that can make the brainstorm better and 6 points that make it worse. As the saying in the article ‘The best way to get a good idea is to get a lot of ideas’, brainstorm is important that will bring new fresh air into our brain and make our minds more active in studying and research. That is what we need in the interface design field.
Yubo Feng 1:06:45 9/9/2014
The main idea of the passage "The Task-Centered Design Process" is that build your interface or software design based on tasks acted by user rather than features, and the other passage "Brain-storming" gives readers some hints about how to organize your own brainstorms, some tips and some principles. Basically to say, I think the former passage is more interesting than the later one. What makes it more fun lies in a totally different designing mode. In traditional software design, we concentrate on how to design features and hot to implement them, but user’s experience is neglected. This passage comes up with the idea that as a designer, user’s experience is the first thing to consider, and how? Tasks center is the way. We try to catch basic behaviors, construct them as tasks, try to build the models abstracted from tasks, referring to other’s implement and delaying implement to last step, after that, we build a demo, testing it and improving it.
Andrew Menzies 1:12:30 9/9/2014
Andrew Menzies Critiques due 9/9/14 Brainstorming This chapter describes brainstorming as a skill or even art, not a simple task. The author gives several suggestions for maximizing the number of ideas people generate in a brainstorming session in order to increase the chance that some usable ideas will appear. I believe this author makes several good points. One is the recommendation that people mention their outlandish ideas in addition to their reasonable ones. In my experience, many times during meetings I or someone else has blurted out a clearly unviable idea, only for one of us in the group to realize that with a minor tweak, the idea could work. Another is the suggestion to do away with requiring specific people to speak at specific times. This makes sense given that whenever I know I am expected to say something in a discussion, such as in a class where the teacher tracks participation, I am more likely to prepare something “safe” to say from the beginning rather than actually respond to the ideas others share. Some of the suggestions the author gives, such as covering the walls with paper, are strikingly low-tech. I believe that developing technology to improve brainstorming will prove challenging. The usefulness of idea visualization software, for instance, is limited by the size of the screen of the device it is on as well as by how many people can input their ideas to the device at once. However, the advance of technology does provide a boon to brainstormers—ideas they come up with that are unviable now might become usable later if an innovation makes an implementation detail possible. Task-Centered User Interface Design A Practical Introduction by Clayton Lewis and John Rieman This chapter presents the idea of designing a user interface by thinking primarily about what tasks the user should be able to do with the system and then coming up with interfaces to make those tasks possible. It presents a step-by-step plan for interface development beginning with task selection and including user testing of a prototype before actual development begins. The chapter makes several good points about the interface design process. One is that the features in the interface of a system under development should be laid out similarly to equivalent features in the interfaces of other systems that the users are likely to know. Another is that before adding a feature, designers and developers should think about what the feature actually helps the user accomplish. When upgrading a Web application this past summer, I discovered a feature for changing items’ ID numbers that, judging by the amount of code it required, took a long time to develop. Since the upgrade replaced sequential ID numbers with random ones, my coworkers and I realized that the feature didn’t help accomplish anything useful, so we cut it from the application rather than try to change it to fit logically with the system. The fact that countless interfaces have managed to stump me, as well as other experienced computer users I know, proves the necessity of user testing for any interface meant for wide distribution. I do not believe, however, that every interface needs to be designed following the exact steps presented in this chapter. In some cases, the users themselves might provide hard specifications for the interface, preventing the developers from coming up with a task-oriented design. However, developers might be able to use task-centered thinking to explain to the users why a different design might be better. Also, the middle steps (engineering analysis and user testing, in particular) might not be worth the cost if the interface is only going to be used internally by a small amount of people, especially if the interface is needed quickly. Finally, eliminating every feature that is not associated with a specific task might lead to a restrictive design, especially for artistic applications like image and sound editors. These applications may include a large number of effects and changes to apply even though only a few of them will frequently be used, just in case someone manages to find a creative use for the others.
Yingjie Tang 1:31:33 9/9/2014
The first article Task-Centered User Interface Design recommends us a overview of a process that’s very important in interface design. It mainly tells us to figure out to fulfill the users’ needs and to make a rough design for it and then repeatedly change it to meet users needs. There is a paragraph tells us to create a prototype or a mock-up. The author suggest that in this stage, designers should make a simple design rather than a concrete product. And he mentioned some systems which can help us to make a prototype of our interface, such as HyperCard, Dan Bricklin’s Demo Package. We can save a lot of work in making a prototype rather than to produce the entire interface. Moreover, Interface techniques tested in a stand-alone prototyping system may be difficult to duplicate in the production User Interface Management System. The second article The best way to get a good idea is to get a lot of ideas tells us the important of brainstorm, how to perform a better brainstorming, the brainstorming effects and some ways to destroy a brainstorm. Brainstorming is not as easy as a check box, and we can get a lot of information in a brainstorming. So, there are 7 tips for us to make a better brainstorming, 1, we should make our focus narrow by make the questions well-honed. 2, we should not focus on the debates and critiques of the ideas from others and just encourage wild ideas and that will make the brainstorming more informative. 3, Number the ideas so that can motivate the participants to gauge the fluency of a brainstorm. 4 In a good brainstorming, we should follow a series of good curves and to build and jump in correct time. 5, To make the thoughts visible by some graphs so that group members will be more clear about the discussion. 6, Before starting a brainstorm we should do warm up first. 7, use physical elements to make the discusion clear.
zhong zhuang 3:49:50 9/9/2014
This paper has a very clear main point, how to brainstorm. I think almost everyone who has a college degree has heard of this term brainstorm. Half of them may say they do brainstorm on some projects, but if you ask someone how to brainstorm? What is a good brainstormer and what is a bad brainstormer. I think most people won’t be able to say anything meaningful. So that is why I found out this paper is very useful. It tells you how to brainstorm. I personally found this paper very useful to me, because I brainstorm a lot, I own a restaurant here in Pittsburgh, we have a 4 people management team, and we will brainstorm regularly like once a month. After reading this paper, I figured out that we do it in a wrong way, in our brainstorming, nearly half of the time will be used to debate and argue, it is very unproductive, I think this “build and jump” way this paper introduced is much better, first you bring out a topic and all team member build around this topic, push or introduce small variation and once you have no more thoughts, you either jump to a further step or step back to previous step, I think this is the most inspiring part I learned from this paper. Another interesting thing in this paper is the author thinks brainstorming is a multi-win situation. I never thought this before, it is true, because, in brainstorming, if someone said some very good idea, you will not feel being intimidated, instead, you feel being encouraged, and one will try harder to brainstorm after a good idea has been brought up. This is very like singing karaoke, if you heart someone sings a really good song, you will also want to show off in front of your group. This is multi-win.
Christopher Thomas 3:54:40 9/9/2014
PAPER 1 STARTS HERE ******************* 2-3 Sentence Summary of “The Perfect Brainstorm. The Art of Innovation.” – The author(s) present a case for how brainstorming sessions should be conducted to maximize their productivity in an organization. The author(s) present some basic guidelines to follow for companies seeking to conduct more effective brainstorming sessions, listing some guidelines to follow to conduct brainstorming sessions, but also listing some common pitfalls that companies often run into which inherently limit the brainstorming sessions. My critique of the article / chapter: One thing I wanted to note was, in the chapter that we read, the author(s) never motivated when and why brainstorming was useful (i.e. what problems is brainstorming appropriate for and what problems is brainstorming not appropriate to address), but perhaps this issue is addressed in a later chapter of the book this article came from. I definitely think brainstorming sessions and encouraging a culture of free thought is important though, and we see evidence of that every day. For instance, Google is widely known for encouraging its employees to brainstorm and actually spend so much of their time on “blue-sky” projects. One thing that was missing from this article was a discussion of whether or not the company should allow employees to work on some of these ideas that seem “far out” instead of mainly focusing on a narrower solution to a particular goal. For instance, the article discussed one case where someone suggested a motorized squiggly pen, but their company never followed up on it, but a few years later some other company did. So, while I think brainstorming is critical, I also think allowing your employees to work on exciting projects like that can be critical. For instance, Google Glass and the Google Car arose out of the free time that Google gives to its programmers and engineers to work on whatever projects they want. The article got me thinking about how useful brainstorming sessions may be in the context of a research group. For one thing, brainstorming may certainly yield a lot of ideas on how to solve problems, but often for research very well thought out solutions may take precedence over this sort of methodology. That is to say, some problems require deeper thought to address than may be reachable from a brainstorming session where people state things off the top of their head. Also, while the author(s) do give examples of exercises that might be useful, they don’t specifically state what to do if the brainstorming session just isn’t being productive (i.e. no relevant ideas to the topic). While the author seems to be of the opinion that all brain storming sessions are productive which generate lots of ideas, discussion, and are fun, I am of the more practical opinion that if those ideas generated are not feasible (i.e. not patentable or too expensive to manufacture) then is there really a benefit to this exercise? ************ PAPER 2 STARTS HERE ******************* 2-3 Sentence Summary of The Task-Centered Design Process. Task-Centered User Interface Design. Chap 1. Lewis & Rieman – This chapter describes designing user-interfaces through the “task-centered design process,” which involves the designers identifying representative tasks that the project will be used for. Based on these fundamental, core tasks, the designers consider and plan all aspects of the user interface around these core tasks, keeping in mind that all functionality should be natural to the intended audience of users and also the efficiency which those tasks can be performed with this design. Also inherent in the model is the step of performing planning, user testing, and iterative development to produce a production grade product. It was interesting to read this chapter and see the similarity with another paper we read, which discussed GOMS (goals, operators, methods, and selection rules). In the GOMS model, the notion of the “human-information processor” was explored, which is a cognitive modelling technique modelling how long users take to perform tasks. In this article, which was about task-centered user interfaces, the time users take to perform tasks using the interface is also key. It is actually interesting in this regard, that sometimes the “fastest” interface (i.e. fewest number of keystrokes, etc.) may actually not be the best or most efficient interface for the users. If the intended audience of users are used to performing a certain task in a certain way, providing a jarring interface may actually make the users take longer to complete the task and may actually cause the users to use a different product, even though the new user interface is actually more efficient in theory. I also see the connection to GOMS modelling where the authors discuss how in task-centered design, designers need to consider the number of mental “leaps” or cognitive steps necessary to complete some task and in the most likely order the user will have the requisite information, which also relates to GOMS modelling from the other paper, so I thought this was an interesting connection. I keep thinking of this process in comparison to another process which is currently used today called AGILE development. We haven’t discussed AGILE in class yet, and I’m not sure if we will, but the basic goal of AGILE development is to get something working as soon as possible – i.e. code “lean and mean” and worry about fixing the little things later incrementally. I see a lot of the AGILE development philosophy reflected in the task-oriented design philosophy. For instance, the concept of iterative improvements to the product is common to both methodologies. However, it seems a bit like task-oriented development has more of a planning component to it. For instance, task-oriented development emphasizes the importance of planning, modelling, developing prototypes, etc. rather than rushing to get code working as soon as possible as AGILE does, so I see that as a difference in the two philosophies. However, it should be noted that the planning done in task-oriented development may actually pay off later, because if the code is designed very modular and well-thought out, it should not be difficult to upgrade or replace certain features. However, if one is to rush to get something working, with the intention of later improving it, as in AGILE, one may find that it is actually more work to change the code which wasn’t written in a generalizable manner or with poor foresight.
Jose Michael Joseph 5:25:46 9/9/2014
Task Centered User Interface Design This paper is about the various processes that must be ideally followed to ensure that a product has a good interface system. It lists the various steps that must be taken one after the other to ensure that the final product has an interface that is easy to work with and appealing to the user. Although most of the points in the article sound reasonably logical, the primary perspective/priority the author seems to be missing is the intention in making this application. If the creator’s priority is speed over quality, which could be the case if the creator wants to be the first to release the product into the market, then this model is inefficient as the various processes it describes are too time consuming. Another point that seems a logical fallacy to me is the point where the author asks the creator to “plagiarize” by which he means look for design features in existing products and create something similar. The problem with this statement is that often most of the technologies reach a plateau stage after years of development (example : the mouse) and thus looking at systems that use a mouse will restrict the creator’s ability to redefine their product. What if Apple looked at the iPhone and thought it should have a keypad since every other phone was having a keypad at the time? That would be the drawback of plagiarism.
Jose Michael Joseph 5:26:26 9/9/2014
Brainstorming This excerpt is about the various ways to make a brainstorming session more productive as well as the things that would destroy the productivity of the session. The excerpt highlights the importance of brainstorming in companies and how it can lead to innovative ideas. The point that struck me most is that when we are in a brainstorming session we should try and reduce the ‘formality’ of the whole event. This encourages the people participating to shoot out ideas which they wouldn’t in a normal setting in fear of being judged by their peers. But often these “off shoot” ideas lead to solutions even if they’re not necessarily the solution themselves; a person sitting in the room could be motivated by a wild idea and suggest something that builds on it which could lead to the solution. Another important point is to number all the ideas obtained in the session. This helps us to keep a track of the ideas that are generated and gives an incentive for those in the room to push themselves further to produce an idea. Also we could use the list of ideas for a solution to another but similar problem on a later date. Hence brainstorming could pay off not only for the current problem that is being discussed but also for future similar problems.
Qiao Zhang 8:48:35 9/9/2014
The Task-Centered Design Process This article reminds me of the classic software engineering model: the waterfall model. The difference is that this article puts strong emphasis on the users instead of focusing on the developing process. As said in the class, human-computer interaction concentrates more on the human side, which is the bottleneck of today's computational work. Every developer needs to keep the users' needs in mind during every developing stage. The article points out a very important process which is often overlooked by the developers: tracking and changing the design. In real world situation, many developers' job stop at finishing the software. However, in order to maintain the sales, the developers must upgrade their software regularly in need of the users. There are innumerable examples of good software outfalls into disuse because of the lack of upgrades. The maintainance part should be viewed as important as the design and develop part. ================================================================ The Perfect Brainstorm The article is inspiring. I strongly agree with what Linus says: "The best way to get a good idea is to get a lot of ideas". My father, who is a professor, once told me that the best way to come up with your own idea is to come up with as many ideas as I can. He also says that even though I might find most of my ideas are already done by others, sooner or later I can find an idea that has not been done. I have not practiced brainstorms often, and so far I seem to have only practiced a brainstorm-like activity once, which happened in the last term during the visualization class final project. I and my partner were not aware that we are actually brainstorming at all. In fact, we just sit there, trying to find a good way to visualize our data. We first tried to come up with all the representation methods possible, and then we evaluate each method and listed the strength and weakness of them. As we finished the project, we received very good feedbacks from others. I will definitely brainstorm more in the future since it boosts creativity to a great extent.
changsheng liu 8:50:21 9/9/2014
<The Task-Centered Design Process> mainly introduces the basic process of task-centered design. It’s quite straightforward in the paper, listing all the critical steps. Regarding the steps, I especially like “Choose Representative Tasks for Task-Centered Design”. The representation should provide a reasonable complete coverage of the functionality of the system, which can help user better understand the task and have a big picture of task, without ignoring too many details. Also, “Create a Mock-up or Prototype” and “Test the Design With Users” are significant during the whole processes. This can help us find the potential problems at the early stage of design and resolve it as soon as possible. <The perfect brainstorm> introduces what we should and not to do to have a perfect brainstorm. Seven Secrets for better brainstorming includes Sharpen the Focus, Playful Rules, Number your ideas, Build and Jump, The space Remembers, Stretch your mental muscles, Get physical. This is really helpful to guide us doing a good brainstorming. For example, build and jump is an idea I have read for the first time. Take power curve into consideration, this could speed up the process of brainstorming and move forward when we get stuck in a plateau. Six ways to kill a brainstormer includes The boss gets to speak first, everybody gets a turn, experts only please, do it off-site, no silly stuff, write down everything. If we could follow this rules, it could improve the quality of brainstorming dramatically.
Vivek Punjabi 8:59:25 9/9/2014
Paper 1: Task-Centered User Interface Design Summary: The paper suggests that, for any successful product, focusing on the design and implementation of the user interfaces is equally important as the other attributes such as requirements, performance, completeness, etc. Particularly, it provides an approach to build an user interface system which uses user tasks as their reference point, calling it as task-centered. Critique: The paper provides a good amount of information on how user interface is important and the extent to which it depends on the user tasks. In the current technological world, the success of products hugely depend on its user interfaces and appeal. So its quite important to modify our traditional software development life cycles to incorporate these changes. This paper focuses on one of the most important points required for an user interface to succeed, user tasks. Apart from the one mentioned here, the other focus points can be user background and environment where it will be embedded. Couple of things that I would have liked to change in the approach are: Ideas that are found or developed in this process shouldn't be discarded but documented for future review. This will keep a space of improvement at some point of time in future. Also, I would suggest instead of plagiarize, better and modified techniques should be developed that can replace the traditional and non-efficient ways rather than using similar techniques, but only if they are more efficient.