InTouch Customer Service Final report INF2260 - Autumn 2012

Maria Aleksandrycheva, Weiwei Xu, Alexandra Novikova, Thomas Lindsjørn

1

Table of Contents Table of Contents Introduction Theme Group Members Plan A mobile app. What is it actually? Rapid Application Development (RAD) Requirements planning Inventor’s requirements: Telenor’s requirements: Users requirements User design and construction Prototype I Feedback from Joshi Prototype II Expert testing Living lab User based usability testing Evaluation Determine the goals Explore the questions Choose the evaluation methods Identify the practical issues Incremental delivery Participants Facilities and equipment Schedules Decide how to deal with the ethical issues Evaluate, interpret and present the data Reliability Validity Ecological validity Biases Conclusion Reference list Attachments

2

Introduction This report is a detailed description of a project, which has on its aim to create an application for a mobile phone for Telenor, which is the largest mobile operator around Scandinavia. Our task was defined by Telenor. They wish to make customer service easier to use and make it more user friendly. Telenor is using a lot of resources in this field and would like to implement new ideas or do something in a better way. Telenor is constantly developing and all the time offering something new and innovative technologically wise, we decided that we would like to be a part of this high tech process and step forward with some fresh ideas. We have used Tone Bratteteigs Tips til rapport 1 as a rough guide on how to structure our report.

Theme Our paper consists of three parts. In the introduction we are describing the chosen topic and paper structure. In the main part we are introducing the practical use of lifecycle model (RAD) which we are choosing as a guideline for our project and all the design stages; and DECIDE framework as evaluating model for our project. In conclusion we are analyzing and summarizing results of our project and sketching the lines for possible further development.

Group Members Originally group consisted of five members: Thomas Lindsjørn who is studying informatics and has experience in developing apps for Android, Maria Aleksandrycheva who has background in pedagogics and linguistics, Weiwei Xu has took INF1510 - Bruksorientert design, INF 1050 - Systemutvikling and background in economic and history. Alexandra Novikova who has experience in linguistics and transcultural communication and Audhild Harkestad, who is an experienced graphic designer. Unfortunately Audhild had to terminate the course right before the first group presentation due to the health reasons. We were sharing the work between group members having in focus competence of each group member and learning from each other. This project is not only a good opportunity to develop our skills in interaction design but also in group work and cooperation. Individual talents of group members helped us to divide roles and duties in the group. Our group has an international background which was making our work

1

Tone Brattetig, Tips til rapport, http://www.uio.no/studier/emner/matnat/ifi/INF1510/v12/ undervisningsmateriale/1510-rapport.pdf

3

challenging and interesting at the same time. However, we suppose that this experience will be useful in building up career in working life , since the specifics of field of our field of the study is international.

Plan On our first meeting 31/08 - 2012 we discussed our thoughts, ideas about the project and timetable for weekly meetings. The first milestone was presentation in class on the 15th of october. By that time we had a simple working prototype. After we have gotten feedback from Joshi and had consultation about further work with Amela, we developed further plan how to make our prototype better (design and functionality wise), test and evaluate it. Planning routines went smoothly and were easy to keep, since all group members were intuitive and quick to respond. Communication through gmail and Google drive, as well as face-to-face group meetings were regular and were going well due to the well developed and detailed plan. Meetings with representatives from SINTEF(Asbjørn Følstad) and Telenor (Kenneth Arvesen) and Amela Karahasanovic, who was our supervisor were useful and gave a right direction to project development.

A mobile app. What is it actually? Before starting designing the app we focused on the key principle which is lying in a term mobile app. It is “an application developed for small handheld devices, such as mobile phones, smartphones, PDAs and so on” 2 and which has a sharp specification as it’s key feature.3 That will say a mobile application is purpose-built and is covering a certain additional functionality for a mobile. According to reknown application designer Priya Viswanathan the following principles should be followed while designing an app4: To find out the major task which this app is going to fulfill: to give an effective customer service. To make a market research in this field: We investigated the market (checked what Telenor apps are available on Google play) and found out that there are two types sharply specialized applications: the ones concerning faktura features (mostly for the corporative clients) and Telenor TravelSure. Both are popular, but there is nothing which combining several functions, 2

http://mobiledevices.about.com/od/glossary/g/What-Is-A-Mobile-Application.htm

3

http://www.bogost.com/blog/what_is_an_app.shtml

4

http://mobiledevices.about.com/od/glossary/g/What-Is-A-Mobile-Application.htm

4

which customer service is responsible for. To find out the target audience: Telenor wanted an application for customer service and did not define any specific functions it should have and gave us pretty much freedom of action. So, we decided to try to create an app which will be useful for wide audience of customers, without any specification of age, gender or background.

Rapid Application Development (RAD) A distinctive feature of rapid software development is that a software is not developed as a whole unit, but as a lot of increments, where every piece/increment represent a new functionality. We have chosen to use rapid application development, because: ● The processes of specification, design and final implementation are interconnected. ● The software is developed in continuously in several versions, every version is evaluated by end-user who is giving corrections and update about new requirements. All those changes are getting implemented in the later versions of a product. A customer is closely involved in design process, which is making final product maximally closely responding user requirements. We have decided to use in our project rapid application development model which gives an opportunity of parallel development of software and then integrating of those functions5. The important advantage of this model is that the user gets quickly a functional device and therefore early feedbacks. It leads to regular improvements in requirements and functionality. Functions are developed cyclically and finally realised in a working prototype. The development process is presented by next stages:

5

Sommerville,Software Engineering, p. 405-409

5

● Requirements planning ● User design ● Construction ● Implementation/cutover 6

Requirements planning Organized requirements of a product are the specific qualities, features, and objects that the system will ultimately include. In our project gathering of requirements is a threesided process:

6

Shelly and Rosenblatt, Systems Analysis and Design, p. 146

6

Inventor’s requirements: In this project simple brainstorming has been the starting point because the final solution is built on set of ideas all members of group agree to. After all the ideas were generated, we prioritized the best ones for this solution which were used for the initial requirements. Thus our first prototype of the traditional Smartphone’s app was born on the whiteboard: a few functions on the main window, their symmetrical disposition and user-friendly design of interface are the distinctive features of our first prototype which we transferred to the final prototype.

Telenor’s requirements: Telenor is interested in a professional app solution for its client with the main focus on invoice and self service. The variation of project could be extensive because the Android market of Telenor’s applications is very poor. It is a real advantage for our group because this market niche is free for innovations and research. Interview with Telenor has confirmed that the user needs WOW-effect and simplicity at the same time. They have advised us to pay special attention to the most urgent problems and

7

questions the users are often faced with. One of the tasks was to try implementation of functions in the app (Innvoice, My subscriptions, PIN/PUK, services that can be operated from the app and self service).

Users requirements One of the most important steps in gathering requirements for a new application is gathering them from the user. We have chosen questionnaire as a much more informal tool. So we made a Google questionnaire(Attachment 1) to explore users’ requirements. The many-sided nature of questions helped us to find habits and typical user behavior in different life situations connected to use of mobile service and communication. 41 participants at the age from 20 to 70 participated in this study, (the results you can see in Attachment 2). By means of qualitative and quantitative analyses our app is presented by 5 these functions: Invoice, My subscription, Help, Actual and QR- code scanner.

We chose Android as our development platform. It is free, open-source and Thomas has prior knowledge of it. Is is also the fastest growing and most popular mobile os platform as of July 20127.

7

Kantar Worldpanel ComTech, http://www.kantarworldpanel.com/ 8

User design and construction Prototype I

Our first prototype was presented by the deadline and our great achievement was that it was a working prototype. We have focused on functionality, user-friendly and understandable interface and group’s innovation – QR-code scanner as multifunctional help device. The idea of use of QR-code scanner in self service has got a great response. Some creative ideas seemed to be unreal, but we are sure they will be realized in the nearest future: for example use of QR-code scanner in car service (change of oil, filters, details etc.) and different manuals. The scanner function was realized in our project but in final prototype it has undergone changes and turned into function of paying invoices. Feedback from Joshi After the presentation our first prototype was evaluated by experts in interaction design and recommendations for further research and work planning were given to us by Suhas Govind Joshi. His positive feedbacks gave us much enthusiasm for developing and realization of the new application. A functionality finished prototype was an advantage of our project which gave us great possibilities for testing and evaluation. In spite of positive feedbacks we had many tasks to finish before the evaluation. First we were advised to concentrate us on the interface and esthetic view, modern graphic and user-friendly icons and not to forget that we created the product for Telenor. Secondly QR-code scanner as our innovative function needed most of modification and redesign: a user-friendly name and icon should attract users of all age categories. The user should value the importance, efficiency and easiness in use of the function on the first try.

9

In the third place it was important to determine the target user and to try to achieve the design of the application also points the user. An important remark was that simplicity in functionality doesn’t mean primitiveness. The application should be easy to use but at the same time it should be unique and fulfill requirements and realize the functions the user asks for.

Prototype II After the first presentation and getting feedback from Joshi, it was obvious that our prototype needs some global changes: - Work more with design - make it more user friendly and looking more like a final product -Think more about functionality and it’s correspondence with focus group - Have major focus on user and her demands but also stay technical and keep in mind wishes from Telenor. We developed our second prototype basing on those principles. The second prototype has gone through different types of testing: expert testing, usability testing and living lab (usability lab with main focus on graphical design).

Expert testing We conducted an expert usability test to squash bugs and prepare the prototype for userbased tests. This kind of test is usually conducted to uncover obvious flaws, such as confusing wording, inconsistency in layouts and or colors and bugs which will worsen the experience for the user8. Our review method of choice was the cognitive walkthrough. We had one expert in the study; Yngve Lindsjørn. He has designed applications on various platforms for more than 30 years, worked as a computer scientist on Norsk Regnesentral and is currently teaching the course INF1050 Systemutvikling at the University of Oslo. The test consisted of a set of tasks that our participant performed (for the full study, including full set of tasks, see Attachment 3 ). Both high-frequency and rarely occurring tasks were tested. The test squashed some bugs that were essential for the later usability tests. Notable examples are bad layout on landscape view, navigation on Hjelp - section not working properly and some buttons not providing proper feedback. See Attachment 3 for full list of bugs. Our expert also pointed out some other areas needing work. For example the background logo was taking too much focus in the design and might make it difficult for the hard of seeing to navigate. Yngve advised us to read up on background-foreground color heuristics.

8

Lazar, Feng and Hochheiser, Research Methods in HCI, p. 256-258

10

Living lab We were promised to get a living lab testing with the help of SINTEF and it’s funds. As we got to know later on SINTEF was carrying on the survey aiming to answer the question if people who are actively using social networks are more active and engaged in participating in those kinds of questionnaires and leaving a helpful feedback or not. Our project was a practical part of it. The participant were intended to open slides and answer the questions from at home. In addition it was a comparative analysis of two prototypes: there were originally two groups working on Telenor project. So people who were taking part in testing could not be focused only on one version of app and their attention was destructed with something else, and the slides went one after each other, so their perception was not influenced by anything else. We prepared 5 slides (attachment 6), with screen-shots of our application developed by that moment, and questions required potential functionality. We’ve gotten a recent feedback (see attachment 5, which we represented graphically). In our application we tried to implement two innovative and extraordinary functions: analyzing of expenses (and further choice of abonnement) and QR code function. We had a lot of questions concerning those functions. However they were not picked up for testing by SINTEF representative because they have too close focus on functionality which could not have been represented by slides from computer monitors. Our app were called simple, easy to understand with nice design including “what is needed and nothing more”. “Analyze expenses” function were highly appreciated by SINTEF representatives and people taking into survey. So, we could conclude that we are on the right way. Among the problem zones were named: - color choice - lack of contrast - boring and too simple interface - QR code icon doesn’t look attractive enough. Initially our group was sceptical about that kind of testing, supposing that it is much more focused on graphic design skills of developers and visual perception of interface, than on functionality of an app itself. So, that will say it was not a living lab testing where people would be actually doing some tasks, being observed and get this performance documented. We discussed this issue with SINTEF representative and he recommended us to get as more as we can out of the date we’ve gotten, learn to work with theoretical results and test the functions in use if we feel initiative enough. By that time (16th Nov) we had a certain time-limit for final rapport delivery and conducting one more type of testing.

11

But we decided that it is absolutely essential and decided to conduct this additional experiment, which will focus and test the functionality of an app. User based usability testing In this type of testing we tried to test the functionality of an app keeping in focus the problematic areas (the ones found out in SINTEF testing) of our product. We selected several spots at campus (Ole-Johan Dahls hus, cantina at Frederike, CV fakultetet) and asked our friends. Because of the time constraints and and size of the project the quantity of participants were limited, but representative enough (7)9. We made a set of tasks which were checking out the functionality of every button in the major interface window (Faktura, Hjelp, Abonnement, Aktuelt). The advantages of summative test in our case are that it provides real performance data and answers the question: “How usable is this application?”, besides the results have high reliability and validity. Before and after conducting the tasks on the functionality we have asked open questions to win participants’ favor, to dispose them to positive communication and to explain the importance of their participation. (Attachment 4) It turned out that the answers on these questions gave us very important information: some questions were difficult to understand (they have really narrow context), some questions describe typical habits of Smartphone’s users and level of interest to innovations in technology. The answers on the questions also confirmed that the design of interface is very simple and actually it is on border between fancy simple and simple but innovative. All the participants showed the interest to the developing of new application and would like to have that kind of working application on their Smartphones for example to pay invoices or solve other possible problems quickly on their own, without logging in the net-bank and it does not matter if they have used similar applications before or not, but only 3 of 7 participants used similar applications before. Some of the participants suggested possible design changes in the interface to make it more attractive, user-friendly and habitual (resemblance to Telenor, combination of forms, colors, buttons etc.). The participants should: 1. Find out invoice of a certain month 2. Pay the invoice of a certain month 3. Find the function which helps to “analyze expenses” 4. Find out quality of Mb for current subscription 5. Go to Telenor’s facebook side 6. Find out help side for questions about SIM-card

9

Lazar, Feng and Hochheiser, Research Methods in HCI, p. 371

12

It turned out that the most difficult questions for the participants were questions where they should find small details or descriptions but not in functions. The outputs from a summative test are presented in statistical measures of usability (average time to complete a task, number of assists):

We record how many tasks were correctly completed and how long each task took to complete which are called task performance and time performance10.（Attachment 4). In this testing , each participant completed all tasks, most of them through tasks within short time. As you can see from the graph participant 1 has a very high value on the task Telenor Facebook. After statistical analysis we This testing is very valuable for us. Usability testing is finding flaws that can be fixed, is to modify the interface after every user test , to help immediately improve the interface flaws discovered.11 Due to the time limitation, we will not do any changes on our application. Originally, our app was intended to have innovative twist due to it’s QR code which is defined as a separate button on the front page. The user would use it to pay bills, scanning invoices, get information about new goods in the stores and even wider spectrum of functions, which we were about to develop. We tried to make QR code remarkable, made a button for it, put it on the front page of up alone on the raw, centrally aligned. Surprisingly enough, SINTEF testing showed us that the button did not attract any special attention from the users, while others more

10

Lazar, Feng and Hochheiser, Research Methods in HCI, p. 270

11

Lazar, Feng and Hochheiser, Research Methods in HCI, p. 272

13

traditional functions got much more attention and and feedback. We could conclude that we did not manage to promote and design QR code function properly to make it wanted by the user. The summative usability testing showed however that QR code function is workable and seems interesting for participants, but did not provoke “wow effect”, which “analyze expenses” button did. We could assume that this function could still be further developed and need additional advertisment (f.ex. it could be promoted in “aktuelt” showing how to pay bills extra quickly and get to know information about products in Telenor shops etc.). We also experienced some problems designing some functions especially those connected with payment methods. Since we are a group of students developing a prototype, not a real company it was hard to get access netbank functions. The function relevance - yes. Hard to test functionality.

Evaluation To structure our evaluation studies we used the DECIDE-framework as described by Rogers, Sharp and Price12. It includes the following six items: ● Determine the goals ● Explore the questions ● Choose the approach and methods ● Identify the practical issues ● Decide how to deal with the ethical issues ● Evaluate, interpret and present the data

Determine the goals Our goal is to make a user friendly customer service app for a mobile operator - include the most relevant functions, defined during requirements collection phase.

Explore the questions To make our evaluation more fine-grained, we made a list of questions addressing user experience: 1.Is the application easy to use? 2. What do the users think of the application ?

12

Rogers, Sharp and Preece, Interaction Design, 2011, p. 456

14

2.1 What are the disadvantage and advantage of the application ? 3. Is any function in the application the users think is difficult to understand ? 4. Is it easy for a user to perform a set of tasks while seeing an app at the first time? 5. Do users like to use a such application ?

Choose the evaluation methods Choosing between three broad categories of evaluation, we have chosen two, which are giving us better understanding of design process.13 While we we doing usability testing (controlled settings involving user - in our case expert testing, SINTEF research study and usability testing with users) we tried to find out usability problems answering some questions, referring functionality of app (see graphs in the attachment 5). The natural settings involving user is our second appropriate type of evaluation, since it is the most realistic way to show how the user will interact with product in real world/settings. What is more, “a benefit of uncontrolled settings is that unexpected data can be obtained that provides quite different insights into people’s perceptions and their experiences of using, interacting, or communicating through the new technologies in the context of their everyday and working lives”14. Thus participant 3 in the usability testing found out another possibility to solve task 5 and managed to enter facebook site not through Actual function as it had expected but through the Help function which led to Telenor web site where he found the solution. It made us think about functionality of an app and how the user could have his logics while using application.

Identify the practical issues Before starting the evaluation we have identified the main design inspections in our project which are important in describing design of a new app as an uninterrupted process of developing and improvement.

Incremental delivery 1. 13 14

Find out functions users might like Rogers, Sharp and Preece, Interaction Design, 2011, p. 437 Rogers, Sharp and Preece, Interaction Design, p. 442

15

After brainstorming and comparing our own experiences with desires we have decided to create a traditional Smartphone’s application but with a special appeal. An ideal app with necessary functions in one application is what Telenor really needs and lacks. To include all possible functions is not a professional solution. So the list of functions was narrowed down according to the target audience and its necessities. 2. Determine the user Telenor’s users who are interested in finding the solution of the problem by their own, quick payment of invoices without using internet bank and usage of innovations in everyday life is our user group. We suppose that the age of users can vary from 18 to 60 years. The only requirement is to be a Smartphone user. 3. Filter the list of functions With the help of the questionnaire we have found out the most asked questions to calling customer service and the functions the customers would like to have in the application. By means of qualitative and quantitative analysis of data our application is presented by 5 main functions: Invoice, My subscription, Help, Actual and QR code scanner. 4. Create unique inventions to attract the user The usage of QR code scanner in paying bills is our innovation which should attract users and simplify their life. But we have not stopped there and decided to add a new feature - analyze of expenses which helps the user to control expenses and overpayments according to current subscription and suggests changing the subscription. 5. Focus the app The Smartphone application is not a website that is why the number of tasks and options is limited. Users expect an app to do what it advertises and they want to see useful content immediately. We have decided to orient our application on paying invoices. Without doubt this function should be most used and asked-for. Besides this function interacts with our innovative functions - QR code scanner and analyze of expenses. 6. Design the app for the device The application was designed for an AndroidOS-based device. The most important was to realize users’ expectations for the app they choose to install on their devices. App structure should be clean and easy to navigate. Telenor’ s orientation and Android’s standards were taken into consideration. The application should give users an opportunity to do something (pay the invoice as our main focus in the application). 7.

Concentrate on user interface customization Our application was designed for touch and scroll, it is easy but functional and with the innovative interactions. Final user testing helped us to find weak points in the interface of the application. The users find it simple and would add rich and modern graphics. The next stage was to determine the the participants, facilities and equipment and schedule for evaluation.

16

Participants As we were developing an app which could be used by a broad category of people (Telenor customers, without any specific focus on age, gender or occupation), it was not difficult to find those people during requirements gathering process, neither during testing. We did not experience any problems with the length of time spending on a task for a user: when we were doing SINTEF-based testing, people were being paid for taking part in the survey by SINTEF, who was supporting student projects. While we were doing our testing in natural settings, it took ca 5-7 minutes for a user and was more interesting than tiresome for people who was offered to test a new app.

Facilities and equipment The majority of the data we have gotten was collected and available online (questionnaires, results from SINTEF). During the expert testing and testing in natural settings (summative?) we made notes, as a major way of recording the information, but also made a video record, which is showing how the user was interacting with app in practise. Luckily, we did not experience any problems planning our budget, since SINTEF took care of it.

Schedules It was not difficult to plan, since our target audience was literally everybody. However, getting answers and analyzing them required some time.

Decide how to deal with the ethical issues In preparing for our project it is important that we reflect on the ethical issues that might arise in the process of gathering data or otherwise interacting productively with people. We have considered seriously the rights and wrongs of what we may be undertaking and the moral values and principles that guide our actions. The principle of confidentiality in this context might be seen as controversial. The video and photographic recordings of users were made only with their explicit permission. The participants were informed about the goals of the study and further work with findings. Their participation in our project has been entirely voluntary. We have also subscribed the informed consent between us (UiO students) and SINTEF to protect privacy of the test’s participants. We were careful to use our data solely in educational purposes and interests of the project and to comply with established guidelines regarding informed consent15.

15

Lazar, Feng and Hochheiser, Research Methods in HCI, p. 280-284

17

In our prototype we have a function to pay invoices directly from within the app. To achieve this we would need to store personal information such as full name and billing address as well as credit card information. In the prototype no real information was used, but if we were to publish a real application we would need to secure this information in order to comply with Norwegian privacy laws16. A solution to this would be to store all sensitive information on a secure server, and keep the local information encrypted. Outside merchants with proven secure connections can perform the actual billing. Before collecting that data the users would need to consent.

Evaluate, interpret and present the data Reliability We can state that all kind of usability testing in our project have high reliability. Even those data which are less relevant to our research gave some kind of unique and useful information and were used in further stages of testing. The quality of questions and tasks discovers weak points of the system before final testing and helps us to reduce number of bias.

Validity The validity of our data is high, since it is measuring what it was intended to measure; we were trying to create an app which will be easy to use and have some interesting functions. We have tested the functionality through some tasks and questionnaires and can conclude that the data we have gotten answers our questions.

Ecological validity We can maintain that SINTEF testing has low ecological validity because of the extent to which the conditions simulated in the laboratory reflect real life conditions. Those circumstances led to additional testings maximum approximated to the real life’s conditions.

Biases The group which was tested is relatively small sample of participants; it was homogeneous and not wide enough (age from 20 to 45). From one point of view the results of average user is presented in our research, but from the other point the data of “critical” user (older than 60/ younger than 18) was not in focus. So bias caused by participants can be described as not adequate and universal enough. One of the bias can be described as fail usability testing method (by reason of force majeure circumstances). Our problem was not on the focus of the SINTEF study so the results gotten from research are not only relevant for us but even testing which was presented as living-lab and which we have had great plans for turned out as testing of interface design.

16

Personopplysningsloven, §8, §9, §18 and §31

18

Some of the technical bias were removed during the expert testing, but some of the app’s functionalities were limited by our technical skills and law regulations (for example we could not implement QR code functions for invoice payment: the realization has not been the problem itself, but the secure enter to the bank system is law-limited for small projects and private persons).

Conclusion As a final product of this project we have a working high fidelity prototype of an Android based mobile application for customer service for Telenor. Originally we have gotten some innovative ideas, which will create a “wow” effect for a user as: QR code scanner which could be used for paying invoices and getting instructional videos and analyzing expenses functionality under the “abonnement” button. We tried to implement those functions through design phases of our app, using RAD framework for building up and constructing prototypes and DECIDE framework to evaluate them. The result we got is a compromise between user feedback, our ambitions, our technical and design skills and time limits for the project: we implemented the most desirable by the user functions and left the ones which were not that highly appreciated apart. Thus, for example our “analyze expenses” function was marked as “smart simple” and was highly demanded. QR code button, even being put forward on the front page did not get a desired attention. Our mobile application as it is now leaves room for improvement and further development concerning design and functionality. We think that implementation of QR code function is still possible and requires more research and testing. The experience we’ve got during the project was educational for every member: not only from the point of working in group, but also from learning from each other. We learned a lot from the technical and theoretical strong points of each other, since we did not have sharply divided tasks. All in all, we consider our project successful and useful for academical knowledge and future working life of every of us.

Reference list Source

Address

Jonathan Lazar, Jinjuan Heidi Feng and Harry Hochheiser, Research Methods in Human Computer Interaction, WILEY 2010 Yvonne Rogers, Helen Sharp and Jennifer Preece, INTERACTION DESIGN beyond human-computer

19

interaction, 3rd edition, WILEY 2011 Ian Sommerville, Software Engineering, 8th Edition, ADDISON-WESLEY 2007 Gary B. Shelly and Harry J. Rosenblatt, Systems Analysis and Design, Cengage Learning 2011 Kantar Worldpanel ComTech

http://www.kantarworldpanel.com

LOV 2000-04-14 nr 31: Lov om behandling av personopplysninger (personopplysningsloven)

http://www.lovdata.no

The selection of free educational materials (articles, books)

http://www.interaction-design.org/

Tone Brattetig, Tips til rapport

http://www.uio.no/studier/ emner/matnat/ifi/INF1510/v12/ undervisningsmateriale/1510rapport.pdf

20

Attachments Attachment 1 Survey Results

21

22

23

24

25

26

27

28

29

30

Attachment 3 Ekspert testing Oppgaveliste 1.

Det er fem knapper på hovedmenyen. For hver knapp: 1.1 Trykk på knappen og se at riktig innhold kommer opp. 1.2 Naviger til hovedmenyen ved å trykke på tilbakeknappen på navigeringsmenyen øverst i appen. 1.3 Naviger til hovedmenyen ved å trykke på den fysiske tilbakeknappen på telefonen. 2

Gå til Faktura området 2.1 Gå inn på fakturaoversikten for hver enkelt måned. For hver enkelt måned: 2.1.1

Trykk på Flere detaljer knappen

2.1.2

Trykk på Betal nå knappen 2.1.2.1

3

Velg hver av de forskjellige betalingsløsningene

Gå til Abonnement området 3.1 Trykk på Analyser forbruk knappen 3.2 Trykk på Endre abonnement knappen

4

Gå til Hjelp området 4.1 Trykk på alle linkene på siden 4.1.1

5

Naviger tilbake til appen ved hjelp at tilbakeknappen

Gå til Aktuelt området 5.1 Klikk på hver av de 3 bildene med tilbud i slide-showet 5.1.1

Observer at du kommer til riktig web-adresse hos Telenors tilbudssider

5.1.2

Naviger tilbake til appen ved hjelp at tilbakeknappen

5.2 Klikk på Facebook logoen 5.2.1

Observer at du kommer til Telenor sine Facebooksider

5.2.2

Naviger tilbake til appen ved hjelp at tilbakeknappen

5.3 Klikk på Twitter logoen

31

6

5.3.1

Observer at du kommer til Telenors sine Twittersider

5.3.2

Naviger tilbake til appen ved hjelp at tilbakeknappen

Gå til QR-kode området 6.1 Scann QR-koden du har fått utdelt. Observer at du blir tatt til instruksjonsvideo 6.2 Naviger tilbake til appen ved hjelp at tilbakeknappen

Bugs and discrepancies Placement

Description

Fix

1, 1.1, 2, 2.1 and others

When going to landscape view the layout looks bad, i.e. buttons overlapping

Disabled landscape view for whole application except QRcode scanner

1.2

Back-button in top navigation menu not working.

Uncommented erroneous commented line.

1.1, 2.1.1, 4.1, 5.2, 5.3, 6.1

Functions needing internet access not working

Make sure prototype devices have internet settings enabled before testing.

5.1

Pictures moving too fast in slideshow. Animation not consistent.

Set animation duration to standard and time between slideshows to 4000ms. Also changed in-animation to right-toleft and out-animation to left-toright.

5.2, 5.3

Facebook and Twitter buttons not giving feedback when clicked – not intuitive to users.

Changed background drawable from static to selector. Buttons now showing Telenor colored background in pressed and focused state.

Kommentarer

32

Ser semi-profesjonelt ut. Godt nok for high-fidelity prototype og testing, men ikke godt nok for utgivelse. Bakgrunn og knapper på hovedmenyen er uskarpe og ser ikke bra ut i forhold til hverandre. Fargen på bakgrunnslogoen for lik fargen på knappene. Problemer for synshemmede å skille, les opp på standarder. W3C (web). Topp-navigasjonen følger industri-standard, det er bra. Navigering er responsiv, også de funksjonene som bruker internett. Ikke sikkert det er sånn for alle telefoner / dårlig internett tilgang.

Attachment 4

Results of user based usability test:

Part.1

Part. 2

Part. 3

Part. 4

Part. 5

Part. 6

Part. 7

Task 1

4

4

14

8

12

10

13

Task 2

10

9

3

10

8

7

9

Task 3

24

27

8

10

20

17

15

Task 4

3

8

4

10

7

10

8

33

Task 5

11

5

42

7

58

15

27

Task 6

9

35

30

20

15

28

33

used before

no

yes

no

no

yes

no

yes

bright idea

yes

yes

yes

yes

yes

yes

yes

Tasks for use-based usability test: Har du smart-phone? Hvis ja, hvilken? Ca. hvor mange apps har du installert på telefonen? Oppgave

Suksess?

Tid:

Tilfredshet (user satisfaction)

Finn hva fakturabeløpet er for Oktober Betal fakturaen for September Finn området hvor abonnenten kan analysere sitt forbruk Finn ut hvor mange inkluderte megabyte abonnenten har i måneden. Gå inn på Telenor sin facebook side Finn hjelpesiden for spørsmål om SIM-

34

kort.

Hva var den vanskeligste oppgaven å utføre?

Analyser ditt forbruk

Har du brukt liknende kundeservice-app fra før?

Syns du måten å betale regninger på virker som en smart måte å gjøre det på?

Har du noen kommentarer til undersøkelsen?

Attachment 5 Result of Living lab Participants: 129

Question 1.

35

Question 2.

36

Question 3.

Question 4.

37

Question 5.

Question 6.

38

Attachment 6 Screens sent to SINTEF for living lab experiment.

39

40

41

42