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.