Reflektioner angående studielitteraturen: Prototyper

Reflektioner angående studielitteraturen:

Eftersom att vi har blivit tilldelad en uppgift så går många tankar till uppgiften när man läser från boken. Hur kan man applicera denna metod på projektet vi arbetar med? Boken hjälper även till med detta då den ställer retoriska frågor i texten för att få läsaren att tänka. Det kapitel jag tyckte var mest intressant var kapitel 8 som handlade om prototyper, design och skapande av produkten.  Målet med detta kapitel är:

·         Beskriva vad en prototyp är och de olika metoder för att göra en prototyp.
·         Göra det möjligt för läsaren att göra en simpel prototyp.
·         Göra det möjligt för läsaren att gör en konceptuell modell till ett system och även kunna försvara       ens val till modellen.
·         Möjliggöra försök till vissa aspekter av fysisk design för läsaren.
·         Förklara användandet av scenarier och prototyper i konceptuell design.
·         Diskutera standarder, riktlinjer, och regler som finns tillgängliga som hjälp för interaktions designers.
·         Diskutera de alternativ av hjälpmedel som finns tillgängliga för interaktions designers.

Så när jag läste detta kapitel så tänkte jag på hur vi kan använda oss av denna information i vårat projekt och jag kom snabbt fram till att det kanske inte är fullt realistiskt att vi i slutet av kursen kommer kunna ha en färdig produkt att visa upp och att det är mer realistiskt att skapa en prototyp som man eventuellt kan göra en produkt av. Efter jag läst detta kapitel så förstod jag även att det man inte kommer ha en färdig prototyp efter ett försök utan att det är en iterativ process. 

Min första fråga jag ställde mig efter att ha läst delen om prototyper var: 

• Vilken metod ska man använda sig utav för att skapa en prototyp? 

Man kan antingen använda sig utav hi-fi(högre nogrannhet) prototyper eller lo-fi(mindre nogrannhet) prototyper.  En metod för att göra en lo-fi prototyp är att man låter en användare testa ett program som styrs av en människa för att fejka upplevelsen. Denna metod kallas för ”Wizard of Oz” metoden.

Konceptualisera Interaktion

Innan man börjar bygga på mjukvara måste man förstå problemrymden, det vill säga hur själva problemet ser ut och hur man skall attackera problemet. Det fel man kan göra är att för tidigt börja tänka på teknologier istället för problemrymden. I sitt team bör man börja med att just definiera problemrymden för det aktuella projektet. 

Genom att gå igenom tillsammans med sina team medlemmar hur man själv ser på problemet kan man undvika att ta något rörande användarupplevelsen för givet. Till exempel att alla vill ha 3D hemma i TV-soffan eftersom det är populärt på bio. Då man som grupp samtalar kan man bestrida varandras antaganden och därmed få fram en åsikt som gruppen som helhet kan ställa sig bakom. Med detta kan man alltså då definiera både problemrymden samt hur man skall gå tillväga för att lösa sagda problem. Nedan är frågorna man kan använda för att väcka diskussion i gruppen.

1. Finns det några problem med produkten? I så fall, vilka är problemen?
2. Varför tror du problemen finns i produkten?
3. Hur tror du att ditt förslag löser problemet i frågan?

Vinsterna med att ha problemrymden klar tidigt i utveckling är många. Bland annat kan man få en delad grund inom designen och därmed undvika förvirring. Allt ovan är precis vad som behövs i början av ett sånt här projekt då just förvirring kan vara ett ständigt återkommande problem. 

Intervjutekniker

To ease up the work with making a good foundation to our project is there 5 key points from the literature that will help us with the interviews. 

1) Goal – to have a clear goal with the interview and why we are really asking these questions.  

2) Population – Who are we interviewing? We can choose people by random or go after a specific pattern. 

3) Relations with the interviewer and the people that are being interviewed – To keep a professional relation is important. It’s also important with an approval from the people that are being interviewed. And at last to inform what the interview will be used for. 

4) Triangulation – To investigate problems from different angels. 

5) Pilot study – Try our interview questions before we use them. Is it really going to work? This will save us lots of time.

There is also different kind of interviews we can use. A structured, Open Semi structured or open questions.

What requirements for this given design task should we have?

The key activities we can lean back on and repeat from the literature is

1) Establishing requirements. 

2) Designing alternatives. 

3) Prototyping 

4) Evaluating.

Even if we won't have that much time to repeat these steps over and over again do I feel like these steps could really help to make a product “perfect” I think it’s good to have an open mind about the initial requirements at point 1 here and not get stuck on some idea that can’t be changed.  I think these theoretical steps will help us in our user studies, instead of just going out and watching people at a museum we have specific points to go on and we could establish some kind of ground to work on when we kept developing our product.

I think the key requirements for a given design task should be:

1) Effectiveness – easy to use, do what it’s supposed to do. 

2) Safety- safe to use. 

3) Utility – satisfaction, you get some kind of feeling when you use it. 

4) Memorability – easy to remember how to use. 

5) Learnability – easy to learn how to use. 

I also think that the product should give back adequate feedback to the user instead of just printing out an “Error – wrong” or “No” or something like that. Another thing that goes hand in hand with effectiveness is that features should be visible. They talk about visible in the literature, the more functions that are visible it’s more likely that the user will really use your awesome features, this way the user will get what he paid for and really get the whole experience of your product. Another good requirement is the consistency in a design. I didn’t think of this but the literature did, but it really hit me how incredible annoying it is when you use something and the interface isn’t the same for each menu or some button moves around for each step you advance into the application. Another thing is a profound investigation on the current market, what existing technologies are already out there, copyrights etc. I have no mentioned a row of requirements that should be in a design task. In a real design, will there be lots of different professionals involved so the process won’t be the same for everyone. But some key features the literature points out is the and summarize all above:

1) understand the requirements 

2) produce a design that satisfies those requirements 

3) evaluate the design. 

If everyone in the team knows about this we have a stable ground to develop on.

An interesting questions to discuss under the reading seminary is:   

 How can we use triangulation in the best possible way? I mean how can we really step outside the box and look at the problem with a totally new angel.