onsdag 1 juni 2016

Exercise 4 Reflections

The aim of this exercise was to evaluate other designs, and let ours be evaluated. The prototype we presented was an unfinished interactive design of high-fidelity. As well as our sketches of the project. We showed them Stockholm Explore, an app that suggests activities for you to do and experience in Stockholm depending on your preferences. 

A group of "experts" evaluated our design and we acted as experts as well in evaluating another group's design.


Their feedback was very good, but unfortunately a lot of the things they mentioned, we had already thought of but not completed. They did give us some valuable input on not having a bright red SOS button on the front of our app as it would distract and prehaps confuse users. They used Nielsen’s 10 usability heuristics and felt we had optimized the app for both our target group but also for people outside of it which was a positive note. They did give us some feedback about the fact that users might not return and we thought about what to do in this situation. We motivate our decision in the way that we have a fast-paced app in acccordance to with customized user-experience best fitted for each individual. Moreover we have a straight forward design that is easy and fast to navigate through in accordance to Hick-Hyman law. We hope this will bring users back, but we are aware that people who only visit Stockholm as tourists might not want to keep the app when they return home, this is something we accept since it is intentional. A potential improvement is to alter the app, so that it works in cities world wide, this is however, something that we do not wish to be done in our circumstances.

That's all for this week!

Exercise 6 Reflections

During this exercise there was not much to do except present and listen, however, I feel the work for this excercise was some of the most important during the whole course. For our design decisions, please refer to the posts dedicated to this.

However, here is a reflection of the PROCESS of designing our app:

In the beginning stages we must choose a path, and actually get to work. By using data gathering tools such as semi-structured interviews, triangulation of data (by using observation, interviews etc.). Using these as a framework in step II and III (which are inter-connected) we can confirm our target group, evaluate our predictions and start creating something.

 Moving on we iterate through our process, look back at what we have done, and what we should change in our method of doing things. Base a framework for creating more, and for being able to target our specific target group(s). Basing some things on our interviews and leaving some things to our imagination we refine personas and scenarios. This is yet another framework for the next stage in the process.
 We make changes and decide which direction we want to head in, create a basic prototype, which still is still high-fidelity since it is quite easy to make one with the help of a computer. Use feedback receieved from two rounds of evaluation (teacher and students). This feedback is essential to then go onto creating a final design which we create, let it breathe and then iterate through it once again to complete the process.
  A chart and text showing most theory used in the creation of this design:
  A chart illustrating our thought process on how the design process should and has looked like:

måndag 23 maj 2016

Design decisions 2.0

Pilot prototype : 


Final design prototype:


Walkthrough:




Disclaimer
Many of the buttons do not work since it is a prototype but they illustrate the end functions of the final product. 


Explanations of choices and improvements



It is obvious that there are some major differences between the prototype presented at exercise 5 and the prototype presented at the final exercise. Since there already is two different posts that discuss the feedback we have received both from the exercise group and from our user tests, we will not be discussing those here, but rather this post will serve as an insight in how we were thinking when we redesigned the prototype. 

When we revaluated our prototype we found ourselves thinking that, yes from an utilitarian point of view our design is excellent, but the user experience is not all that enjoyable. We thought at the time that the design was to "blocky" and did not look all too pleasing, it felt rough in a way. With that in mind in combination with the ideas of striking a balance between aesthetics and usability presented to us in one of the lectures, we decided that we needed to remake the design but not really the core functionality. This is something that can be observed when comparing the two prototypes, yes the design is different but at the core they are exactly the same. We attribute this to the fact that the choices and decisions that were made to build those core features where and are grounded in HCI theories and concepts. One of the mest obvious changes is that we changed all of the edges of the buttons from "edgy" to rounder to make the buttons appear more smooth. Our motivation behind this change is based in the psychology theories that where presented in the lectures. The idea is that straight edged buttons and interfaces disrupts the thought process of the user. 

Now when it comes to the aesthetics changes we have made we did not want to just do something that we ourselves though would look " aesthetic" since we are only four individuals and there was no possibility to ask a lot of people so our sample size(data gathering would be limited in other words) would be far to small to be reliable. What we did instead was that we turned to the course literature and lectures to guide us. Emotional interaction was a concept we thought was really interesting and we wanted to try and implement it in our prototype. The way in which we did this was for example to choose colour that would be rather mellow to try and calm the user, since we thought that our target group wanted to take it easy i.e. leisure travel and hence we wanted to do everything to reduces their stress levels. We included background imagery related to each tab, see for example the "gröna lund" page, this is an idea we got from the literature on page 138. 

We did not only improve the aesthetics of the prototype but we even tweaked the usability. The way we did was to try and implement the concept of external cognition in our prototype. Our thinking was that the user may not use our application for long periods of time, hence the user will not be spending enough time with the application to remember all the nooks and crannies. This coupled with what was said during the lecture that the human mind works really well with association and that association is often used to reduce memory load, we figured colour coding every section would add some externalizing to reduce said memory load. This is apparent in that for example all the information related to food is in the same colour as the food label at the home page and so on. 

We hope that this post does what it's aim was, which is to give a more thorough insight in our process and the thinking that have gone into each decision step.



onsdag 11 maj 2016

Design decisions

The aim of this post is to give a greater insight in our design process since we as a group feel as though we have not conveyed everything we could have done this far, in regards to providing insight to our process. What we will do is that we will go through every step of the iteration process and the reasons behind why we decided to do what we did. Since in those decisions and the reasoning behind them, the use of the human-computer-interaction theories/concepts we have learned and the applications of them comes to light.

At the beginning of the process we did some data gathering on how people use the currently available technologies. We did this in a few different ways, something that we touched lightly upon on the post regarding the discussions after exercise one. What we said there was that we planned on using triangulation when gathering our data for the design requirements. Now what we failed to mention is that we in fact used two different kind of triangulations when data gathering to establish requirements for our design. The first type of triangulation we used is “Triangulation of data” where the idea is to use different sources at different times. The way we used this in out interview for example is that we interviewed people at different times, and to add to this we did some observations of the environment to further enhance the quality of the data gathered. The second method we used is called “Methodological triangulation”. What we did here is that we looked at different websites or rather different available services and ran some state of the art analysis on them and then combined the data from the analysis with the data gathered from the observations and interviews. What all of this allowed us to do was to set up some preliminary usability goals and user experience goals that will be discussed later on in the text.

With all of this data we now had a good idea about our main demographic user characteristics. So as expected, we used this data as our base on which we built the first persona. Since the persona is supposed to be representing the stereotypical user of the service that is being designed our second persona which is not really in our target group might seem like a misfit. But Persona 2 is not us not understanding what personas are supposed to represent, but rather it is us twisting the concept a little bit. Our idea was that we would make a persona that is not really in our target group so that it would become really clear for us where the “edges” of our target group is, in hope that this give us some much needed insight in which way we should go with the design. In other words, by using a persona that is not really in the target group we managed to make it clearer for ourselves in what direction our user experience goals should be set.

Before we started on our final design sketches we decided to ignore most of the data gathered and a majority of the different goals we set, so that we could brainstorm properly. Our reasoning for this was that too many restrictions would just inhibit our creativity but one or two of the core goals where kept in mind and used as guidelines, so that our creative efforts where at least somewhat directed towards something “useful”. The designs or concepts that we came up with are those presented in the exercise 3 summery blog post.

The bulk of the project work was done around the final design sketches, since this is where all of the data gathered and all the goals be it user experience goals or usability goals where all put together and combined into a concept of a product that is supposed to implement a lot of different ideas and concepts from human-computer-interaction texts and fields. When we designed this application we had a bottom up approach. First we decided that the UI should be kept simple and have a card like look as to mimic other well used and well knows UI’s such as Facebook and Google. The effect of this choice was that we indirectly had to use a combination of the “Instructing” and “Conversing” interaction types since this is what users would expect with a UI that resembles this “card” looking type of window. In reality we where not really forced to go with these types of interaction types but we still did because our target group is young adults that we are assuming have a lot of experience with different technological services and thus have a well established mental model of how an application should react when they interact with it. Another major reason we choose to go with a card looking UI is because cards are often closely associated with information of some sort, since one of our user experience goals is that the user feels informed this choice of UI design is a no brainer.

The next major step in this iterative design process was the presentation of the high fidelity prototype during exercise 5, something that we viewed as a pilot study. What we learned from that pilot study is described in the summary post regarding that exercise.