Showing posts with label Seminar. Show all posts
Showing posts with label Seminar. Show all posts

Sunday, October 19, 2014

Thoughts from seminar 2

Our findings from the group discussion was fore mostly that we would liked to been told to read chapter 6 (which was partly about brainstorming) before we had the exercise about brainstorming. We felt that this information was brought up a bit too late in the process. Therefore we didn’t have much use for this at this phase.

We further discussed chapters 7 and 8 which was about refinement and about prototyping your product. We are still in the refinement phase and we feel that the book gave us an idea of how to approach the rest of this phase. A flow chart, which was mentioned in this chapter is something that we found was a really helpful tool for the group to get a common picture of our product. We got a more clear idea of our concept.

The book also talked about low-fidelity and high-fidelity prototypes and we concluded that we, in our group, probably will use a low-fidelity prototype. The heuristic evaluation method will most likely be something to have in mind when prototyping our product. And this, we think, can also be useful in the iterative-design-prototyping-process.

Some questions we discussed was: “How does the relationship between developing and prototyping work and do we think it should be?”

  • We concluded that you would like a technological foundation when you build an evolutionary prototype. Some design decisions might not be possible without technology. It certainly is a good idea to think about…!

Another question we discussed was: “How do you introduce a shift in technical paradigms?"

  • Our discussion lead to some thoughts how much trust a user must have for a certain company to adapt the design innovations that they produce. We also talked about having a perspective where you know that a new innovation is better through an analytic point of view. This is something that the book called a superior design cause of the fact that it should work better. We also talked about how leading companies easily can force a new design on the user and that later on becomes a standard.

Thursday, October 16, 2014

Reading Seminar 2 - Mathias Bylund

We read three chapters from the book Designing For Interactions for this seminar, namely chapter 6,7 and 8. It was an interesting read with a lot of different views to visualise a project, test the project and make improvements.


Chapter 6 Ideation and design principles and it sought to give an overview of how you can develop your idea into something more concrete. There’s is a lot of different principles for ideation and I think it’s a good idea to at least try most of them to know what works for you and especially your group. Some of the more common principles that the book explained was structured brainstorming, personas and metaphors and I think they are all good ways to start developing your concept. I think that you gain the most from having a lot of discussion but it is also important to use these tools to create the interesting discussions from which your group can take applicable knowledge from.


The next chapter was about refinement and how to structure your concept before starting to prototype it. The refinement process is about making good decisions made from research and knowledge that you can apply on your project. One part of this chapter with the title Standards quoted an axiom from Alan Cooper Obey standards unless there is a truly superior alternative, and I think this a smart viewpoint when making decisions for your project albeit a bit boring and maybe not so creative. It was also a lot about principles and my personal favorite was the Poka-Yoke Principle because I think that this principle is something to always take into consideration especially when designing for a wide audience. They went through different approaches on how to make design decisions by concretizing the visual aspect of the concept in last part of this chapter. Personally I think that you don’t necessarily need to use a lot of them but I think it is good to have an idea to know what tools different designers typically use to be able to make smart decisions on what your group should use.


The final chapter was about prototyping, testing and development and all of them are crucial parts to ensure that your project is taking shape the way that it was planned. I think prototyping is all about being creative and analytic to produce good prototypes to gain further insight of how the product should be developed. Also here they give examples of how you can prototype, for example physical, low- and high-fidelity prototypes, you should take these into account but I think the most important part is to constantly question and try different approaches to improve a project. When it comes to development I really like the idea of an agile-development approach as it provides and efficient way to develop larger problems by dividing them into smaller parts I am not sure if this is something we as a group will be able to use for this project but I think this approach is something to consider for bigger projects.


Question: The first thing Leisa Reichelt said on the question Why should designers bother with  being involved in the development process? where she answered: Firstly the design process is the development process and the development process is the design process. The idea that they are seperated from each other is a tragic misconception. Is it common practice to go back from development process to the prototype process? And if so, is it usually on smaller parts or the project as a whole?

Reading seminar 2 - Björn Lundkvist

The chapters that we have read for this weeks seminar are about different aspects of designing your product. The chapters cover a lot of great methods of making a good design and they mark some points that are important to take in consideration when working with interaction design.

I found chapter 8 most interesting and I think that it is the most relevant chapter for where we are in our project at the moment. It is about prototyping, testing and development and I think that all those three things are something that could be good for us to put some thought on. We have come up with our final design idea and I think it could be good step for us to make a prototype of our final design so that it is easier to get a grip on what we want to do with our idea. I think that by doing this it will be easier for us to make a good interaction design. We have put a lot of focus on that our final design should be easy to use and understand. We want the user to feel comfortable with our product straight away. Another reason for making a prototype and testing it is because we have created our final design idea mostly based on the genius design perspective and on the interviews that we´ve made. If we don´t test our product by making a prototype it could be easy for us to overlook things that are obvious for us who came up with the product but maybe not as obvious for the user. The one and only unbrakeable law in interaction says “Design for the users” as is stated in chapter 6 and you don´t simply mess around with chapter 6 so I guess the only logical thing to do here is to follow that unbreakable law.

In the text the writer recommends the interaction designer to make several different prototypes rather than just making one prototype. A prototype can be anything from illustrations on a piece of paper to an almost finished functioning product. We have already tried to illustrate our design idea as sketches on paper and simple drawings and I think it could be time for us to make a prototype that looks more like the finished product on the computer. Since we are making an application for mobile phones I think it could be a good idea to try to represent the application by different images in the computer describing every page and function of our final design so that it is easier to understand and view. We can test it by letting some of our class mates have a look at it and have them trying to explain back to us how our product works and how it is used. By doing this I think that we will get a good view on the users perspective and that is important when working with interaction design.

Reading Seminar 2 - Alexis Tubulekas

In chapter 6 we learn how to actually designing something based on your research. By brainstorming you can come up with a lot of concepts, which we did during one of the exercises. You will most likely not come up with your final design straight away but maybe the spark that in the end ignites the fire that is your final design. It is quantity and not quality that is the main objective with brainstorming. The brainstorming sessions should generate dozens of ideas and they should be done “analog”. Meaning with pen, paper, post-its and so on. According to the author, messing around with technology steals time. You need to get your idea down as quickly as possible. I’m skeptical to many of the brainstorming methods in the book. I would like to use reason and careful thinking, but I can only speak for myself.

Once you have your concepts, one must organize them to make them easier to distinguish. This can be done with labels and names. By taking requirements of the design into consideration, or so called design principles, you can determine which one to pursuit. We have, more or less, been doing this when deciding what ideas to pursuit.

Chapter 7 is about how to execute your concept and work with the details. The execution and details depend on the constraints of the project. These constraints could be time, money or technology. When designing, there aren't any fixed rules, but there are principles and guidelines that should be followed. One example of a principle is feedback. Feedback in this case means an indication that something has happened. Without feedback, the user would repeat the action they just did over and over again. We are given a great amount of principles as well as do’s and don’ts in chapter 7. I found most of them interesting and hopefully we can apply some on our design.

In chapter 8 the author talks about the final steps in the design process; prototyping, testing and development. The prototype is an incomplete version of the final product that shows the intended interaction. Without a prototype, the developers of the design can have another vision of how things should work. There are different kinds of prototypes that serve different purposes. A paper prototype is a fast way to demonstrate a product, but maybe not the type of prototype to test on users. A high-fidelity prototype would be a better choice in that case. We currently only have simple paper prototypes, but until next exercise we’re supposed to make an online interactive prototype. Now we have some great tips in how to make a good prototype. 


Question: How does one chose how much effort and time to spend on a prototype?

Wednesday, October 15, 2014

Reading seminar 2 - Anton

This reading seminar involved chapters six to eight which in short were about the stages in the design process where you come up with ideas, refine them and finally concretize them as a prototype.

One of the things I found worthwhile considering brainstorming is that you need to give room to be a little wild and not to criticize any idea that comes up. I found during our own brainstorming sessions that that kind of climate in brainstorming did help us to really dare to approach our problems in new ways. Earlier we kind of had ideas of ways of solving our project, but I found the ideas we came up with during this brainstorm to be superior.

Right now we’re in the process of refining our main idea, so reading about that chapter felt relevant, although I felt much of what was written were not so much about what to do, but rather things to watch out for as to not confuse users. For example you don’t want to two lines of text aligned and looking similar if the texts themselves are not related.

We probably will start to think about prototyping soon so we can get some user input about the small details we most assuredly will miss. I think we have a strong concept so far, but to really make something people will want to use, we’ll have to spend time making the interface understandable for the users. I didn’t feel like I got as much from the eighth chapter as I did for six and seven, but I think I realize how important this step is in the iterative design process. Prototyping can’t be done the last thing you do, because after you let people try your prototype you’ll end up with a long list of things that need to change. It will be longer the longer you wait because a lot of functions often are tied in to each other, so to change one thing you might have to change another.

My question is: Is it better to involve users during the process of refining your idea, or rather to independently work out a version and then develop a prototype to test on the user if you only have the resources for one test study

Tuesday, October 14, 2014

Reading Seminar 2 - Emil Westin

For this seminar we were supposed to read chapters 6, 7 and 8 in the course literature. These chapters explain and process the basic tools and methods for HCI design, both for different brainstorming methods, refinement and prototypes and product developing. Throughout the entire HCI industry most of the designers agree that the design process often starts when the designer starts to design a prototype. It's at that step that the product is concretized and become reality; it's the step from thought and sketches to physical form.
  When you have a prototype, you'll have a bigger chance of detecting problems that you might not have thought about before, problems that can not be seen until you actually try to use the product. It could be functionality problems but also things like sizes of buttons, colours and choose of fonts; you can more easily see what works in reality and what doesn't. There are different kinds of prototypes. A designer could choose to create a more lifelike, high-fidelity, prototype, i.e. programming an app in code, or do a more primitive, low-fidelity, prototype, i.e. draw on paper/the computer and then simulate a user session by showing different slides depending on "where the user clicked" on the paper slide.
  I think that our project could really benefit from a prototype, as it is a way to see our work in real time, though I think that a real programmed prototype would mean lots of work and time spent. A conclusion I draw from this is that we should do a more primitive, but still lifelike, prototype, i.e. digital pictures that we use in a simulation.
  Saffer also writes about some guidelines that a designer should think about, when creating adaptive products. These guidelines bring up the importance of how a design should be designed in such a way so the product feels personalized for the user. The designer should help the user to learn by combining doing with understanding, but try to not steer the user in the right way. Rather, the designer should set up a path in such a way so the user can choose to follow by choice. It's a fine line to not steer the user and at the same time "push" them in the right direction so that they can learn the product easily. Another guideline of importance tells about sensitivity and responsiveness. The designer should try to focus on making the application personalized for each user, and that each user should feel as if the artefact is alive and responsive. This, I think, is of great importance in a modern design. As the technology is sprinting ahead and we, the users of todays applications, are used to products that respond for every click we make, it should be one of the main focuses of designing a product. Personalization and responsiveness are two key terms that I think my group should keep in mind when we design our product, which as of today, looks like it's going to be an application for a mobile phone.

/Emil

Thursday, September 18, 2014

Seminar 1 - 18/9 - Thoughts from the group discussion

Today was our first seminar with Vincent, our group supervisor, where we discussed chapters 2, 4 and 5 from the Designing for Interaction book.

We started talking about what we've been reading and something that caught all of our attention was the Genius Design approach that was mentioned in chapter 2 in the book. At first we discussed that it’s was probably a bad idea to use this approach in our group project but after some discussion with Vincie we decided that a combination of genius design, the UCD and ACD would suit our needs. He made us realize that we're also are a part of our target group and that we should think of our own needs and desires when designing. The target group that we've chosen to work with is people that don’t go to museums or who rarely visit them.

After that insight we started asking ourselves when we last visited a museum, why we went, what we thought before and after the visit and so on. This information will make our questions more relevant to our target group. Another interesting thing that came up during the discussion was that when we talked about our museum exhibition on monday, we concluded that we were really looking forward to it, even though none of us have been to a museum in a long time!

Reading Seminar 1 - Emil Westin

In these chapters the author discuss and inform on how to prepare a design process in the best possible way.
In chapter 2 Saffer writes about how to approach interaction design. He speaks about what to think when you accept a design job and that there is four major roads to design by. The User Centered Design (UCD), the Activity Centered Design, the System Design and last but not least, the Genius Design. Genius Design is the most popular and used design method because it’s not necessary to do a lot of research when you work in this way, but Saffer points out that this method is best suited for those designers with a lot of experience. A new designer should work with UCD or the activity centered design methods because they let the designer to know their audience and to think of the design from a users point of view, and that is really important if you would want to make a product that is usable.

In chapters 4 and 5 Saffer talks about how to do an effective and qualitative research and how to best analyze your data so that you can work with it later on. It’s a good thing to look for patterns when interviewing subjects. If an answer is said once, it’s a phenomenon, if it’s said twice it’s a coincidence and if it’s said three times it should be looked on as a pattern. Patterns are easy to work with and reflects what subjects think about things and how they use certain products. Saffer also points out that when you ask questions you should really think about not to say them in a leading way, and that you should be as neutral as you can be in your interviews. And most important of all, write everything down for future analysis! 

After you have collected your data it’s time to evaluate it and to try and see what the problem really is and how to solve it with design! Saffer thinks that it’s a good way to materialize your data, to make it physical. It can be a challenge because you usually have all kinds of different places to store data in different formats. He brings up four different analyze methods that you can work with when you evaluate your data. All of them seems to be good and I think that it’s a matter of taste and maybe what your projects goal is. The most used method is probably the ordinary analyze method, but to know what method is most effective could be hard to know from beforehand.

In chapter 5, Saffer also talks about Personas and what an important role this design tool is. To make a virtual person that the designer can have in mind when designing a product for that target group. For small projects it’s best to keep the number of Personas on a low level.

/ Emil

Reading seminar 1 - Anton Sivertsson

The chapters in the book go through a lot of the steps you take before you start the real designing of a product, for example how to attack a design problem or how to do proper design research. One of the things I found very interesting was the different ways of attacking a design problem that was brought up: user-centered design, activity design and genius design, which were all very different in their approach and where to put the focus of usage in your product.


The later chapters we read were about how to make proper research and how to treat both researched subjects and interviewed people as well as what NOT to do. A lot of focus was put on the importance of this stage in the design process and how much could be accomplished if the research stage was treated correctly as well as how it could help in getting an overview of the problems that you will be faced with in later stages. Formulating a problem seemed to be one of the most important aspects of pre-design, however different kinds of design approaches treat design research differently. For example user-centered design relies heavily on it while genius design relies very thinly on it, if at all.


If I relate to our own project, I think we will have great use of proper design research both in the beginning and maybe even more when we start to reach a concrete concept. We proboably will have to include users in the design over and over if we are to acheive a user-friendly concept.

The other texts were two ISO-text, one about user-centered design in general and the importance of user-centered design and one about a specific example with ergonomic standards for working with a visual terminal. There was also a text about key principles of user-centered design which brought up several interesting things. One was that user-centered designing of products often was left to only one person in the design group instead of being considered by all throughout the design process. This is all the more interesting since in our project the whole group will work from an entirely user-centered design perspective.

My question is: is genius design the most effective doing design research or without?