After having read through the material in the course literature I feel like there is a lot more to designing and developing a successful product than most people realize. In chapter two the authors bring up a number of examples of different ways to approach a design process and point out some of the pros and cons that might come from each separate method. It is mentioned that looking at a problem from the "nuts-and-bolts" perspective might not always be the most efficient way to develop a good product. Instead it is suggested that you as a developer or designer need to consider primarily the wants and needs of the potential users of the product you’re developing. This I agree with.
I believe that starting from scratch without thoroughly examining all aspects of the users can lead to a lot of problems. It seems kind of obvious that if you as a developer get going trying to find solutions to problems you yourself have the end result might not actually reflect what others want at all. After having spent, assumingly, a large amount of time and effort developing something a certain way you wouldn't feel too good about having to tear it down and basically starting over. In order to further the success of your development you really have to make sure it always starts, and ends, with the users.
That bring us to ways of testing what the users actually want. In chapter eight a few methods of conducting this kind of research is suggested. One of the points I found most interesting was "low-fidelity prototyping". The idea is that you basically take whatever product you are developing, highly technological or not, and make a physical prototype at an early stage. The prototype is not meant to be highly functional but basically showcase what the product is meant to do when it is eventually finished. This way whoever ordered the development of the product as well as the potential users can actually see and try what you're making before you over-commit to a certain design that later turns out not to be the right one. I think this is a real clever way to approach things. Let's say you're developing an application for the iPhone. Then it makes sense that the target-customer gets to try out your ideas to give direct feedback before any code is actually written. This will most likely save both time and effort and you get a deeper understanding of what might be missing or what needs to be removed. It can give you insight to things that you might have never realised if you for example asked a customer about something. When you observe someone from the outside actually use your product , and not just talk about it, I think some of the subjectiveness you might have towards it is removed and you get enlightened as to what the situation really is like. This seems like a great way to improve your product in all aspects.
A question that comes to mind however is; when do you know that you know enough? How can you be certain that what you have gathered from your research guarantees that your product will be more successful? One can example imagine that the customer group the research was based isn't really the right one for the product. What happens then? Won't you as a developer end up in the same situation as if you hadn't conducted the research in the first place? Then you would have wasted time for nothing. I suppose this is what we are supposed to learn and develop a feel for during this course. Hopefully, come summer, I will feel confident in my abilities as a product designer thanks to what I will learn during the duration of this human-computer interactions course!
Ted Wanning
When designing a product the literature mentions that it is of importance to identify the users needs in their specific environment, the so called “identifying needs". The product that you are designing should satisfy and support the intended targeted “needs”. After having identified the users needs, some kind of requirements have to be set before moving on to the actual design of the product. I believe that this kind of iterative process during a design project is of great importance to consider. Even though there are several methods, “data-gathering techniques”, to achieve this. Which one to use and how to carry it out is not always clear. The more effort that is put into this kind of research and analyse process the better the results will be, if done well (according to the literature). Some methods might work better for certain data than others. Which one to use is up for the design team to choose, weighing cons and pros for each method against each other for the specific situation. Several methods could also be used as the literature mentioned to get more perspectives. Table 7.1 represents different kinds of techniques to gather data, and some additional information about each technique. I think that using this table to compare the methods with what data you want to gather will help greatly in the choosing of a “good” method thus yielding better end results. We are already suppose to use the interview technique as an initial data-gatherer, which I believe is a good starting point to get some kind of feel for how to proceed with the project and what users and which of their needs might be interesting to target when planning our design product. Later on additional data-gathering techniques might be used for more perspectives on what requirements and needs the product has to satisfy for the intended target-group. The product is intended for the users, so why not take the users needs in consideration when designing the product. Even though it might seem time consuming and unnecessary at first to do this kind of data-gathering it is most likely worth it.
Robert Wörlund
While reading through the chapters I felt like the most interesting chapter was about design.
Prototyping and construction is about spawning ideas. These ideas are perhaps making prototypes out of cardboard to show your early ideas of your upcoming product. These methods are useful if you want to test and interact with the product and explore its suitability. This is called low-fidelity prototyping, it means a prototype that uses materials like cardboard and paper which differs from what the final product will be made of, like electronics. They are easy to modify and cheap to make. These are encouraged during early development.
High-fidelity prototypes is in many cases worse than low since it makes it harder to change the product. But if you are planning to make a software program, then high-fidelity prototyping might be better, since you can then from the beginning test stuff on your computer screen or phone.
Wizard of Oz is a strategy when you input something on a monitor, but it’s actually connected to another human, to make it look like artificial intelligence.
If you’re using high-fidelity prototypes, then you may have a vertical prototype, which means that it has few features but a lot of depth, or you can have a horizontal prototype which includes a lot of features but they don’t have the intended functionality yet.
I thought it was interesting with all the things you have to think about when you create menus, icons, screens and information overall. I want to quote the book:
“The conceptual design should be allowed to develop freely without being tied to physical constraints too early”.
Petter Andersson
I feel the most interesting chapter was the one about evaluation and how using different kinds of evaluation to better your products “user friendliness”. For example using an iterative form of evaluation you encounter problems that you improve on, but sadly improving the problems can have caused an increase of other types of problems. Iterative evaluations helps catch these mistakes and can help you improve both design and hardware problems. The best way to accomplish this is by utilizing both prototypes and different evaluations.
If we, for example, had a program designed to handle certain data for business purposes, we would have to let the users test it and take their criticism and use it to improve our program. BUt as mentioned before this is still not enough. We have to test both the technical standards of our program while at the same time ensuring that the design is easy to understand and use. If not enough people find the program easy to use, we must improve it. The most effective way of evaluating one’s program or product is to have one public evaluation for the design and one controlled evaluation for the technical standards. While the public evaluation have very slack standards and mostly focus on what the user finds to be better for the task, an evaluation of the technicalities of the program must be conducted very strictly with a controlled group.
This, atleast to me, is very fascinating and i truly look forward to the time when we can evaluate our own product.
Axel Swaretz
I think the book brings up many good points. Especially the about the mindset that one has to adopt to be a successful interaction designer. People are all different and the way you think isn’t necessarily the only way to go about things. The need to understand the minds you are developing your product for is crucial and if you just make it the way you think makes sense theres a decent chance it doesn't make sense to somebody else, and it doesn’t matter how easy the system is for you to use if whoever’s intended to use it can’t make heads or tails of it. Just keeping your target users in mind isn’t really enough either (unless you’re making it for yourself) as just guessing what they might want isn’t particularly reliable no mattern how confident you are in your own ability.
To be able to see past solutions which might be already in place and to bo back to the fundamental task is also something very important. Its easy to look at a system, do a field study and figure out flaws and then try to fix them. This might indeed improve a system but some things can’t perhaps be addressed by simply improving on flawed design, but require a reevaluation. Improving the interaction with a parking ticket dispenser will indeed make it easier to buy a parking ticket, but why is there a need for a parking ticket dispenser? Is there perhaps a better way to charge for parking?
David Sjöblom
The articles detailed some interesting facets of user-centered design. The “Key principles for user-centered systems design” article highlighted how difficult a wide application of UCSD might be, but how nonetheless it both can and should be done. This article provided an inside look in to the challenges associated with introducing a UCD (user-centered design) aspect into an environment where such a scheme has not been readily available or used. In particular what the article calls “case mania” is brought forth as a very real problem, namely that an overly abundant use of models might actually hamper rather than help in the development process. This is something that is worth keeping in mind during our project in this course and beyond. This article also introduces a handy checklist of key principles that ought to be worked with if one aims to successfully use a UCD-based development process. Among these principles the principle of “holistic design” seemed most poignant to me. In essence “holistic design” states that one ought to, when designing a product, design all the other related material (ex. the user manual) in tandem with the principal product, this way the overall usability of the product goes up as the related materials are clearly focused and in line.
The ISO Ergonomic requirements for office work with visual terminals (part 11) (henceforth: “the text”) standardization guideline is a different sort of text compared to the article discussed above. The text specifies standardized guidelines to measuring usability, mainly effectiveness, efficiency, and satisfaction. The text also presents a number of examples regarding possible ways to determine these aspects. These examples will no doubt come in handy in our project and as such they are, to me, the most interesting part of the text.
The text does raise a number of good questions for debate, for example how and to what extent is following a standardized set of guidelines for usability good in the design process and to what extent ought UCSD-centered process be utilised in the development of a complete product. In particular the latter is of interest to us as we are to apply these principles in our own project to a certain extent.
The text does raise a number of good questions for debate, for example how and to what extent is following a standardized set of guidelines for usability good in the design process and to what extent ought UCSD-centered process be utilised in the development of a complete product. In particular the latter is of interest to us as we are to apply these principles in our own project to a certain extent.
Jonas Hongisto
No comments:
Post a Comment