Adapting Rapid Contextual Design for Smartphone App Development: User-Centered Design for Small Teams

(1)

UPTEC IT 14 015

Examensarbete 30 hp Oktober 2014

Adapting Rapid Contextual Design for Smartphone App Development

User-Centered Design for Small Teams Carl Ekman

Jonas Martinsson

(2)

(3)

Teknisk- naturvetenskaplig fakultet UTH-enheten

Besöksadress:

Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0 Postadress:

Box 536 751 21 Uppsala Telefon:

018 – 471 30 03 Telefax:

018 – 471 30 00 Hemsida:

http://www.teknat.uu.se/student

Abstract

Adapting Rapid Contextual Design for Smartphone App Development

Carl Ekman, Jonas Martinsson

User-centered design methods may be applied by development teams when creating, rewriting, or replacing software in a given workplace environment.

These techniques can give insight into the product's context of use and facilitate requirements elicitation.

One common method used when designing software applications is Rapid Contextual Design. While popular in part due to its modularity and adaptability, the process of how to choose a suitable variant of the method shows opportunities for improvement.

Technology has also advanced significantly since the method's inception, making parts of existing literature outdated.

By analyzing each step of the Rapid Contextual Design process when applied to a modern smartphone app development project, this thesis has produced a set of recommended alterations to the method, aiming to make it more compatible with contemporary agile development teams using shorter development iterations and consisting of one to five core members.

The proposed alterations are based on team

properties, timeframe, and available resources. Some steps of the Rapid Contextual Design process, such as interface prototyping on paper, may be omitted or replaced in some circumstances. Planning for even a short design phase may significantly improve product quality.

Keywords: Rapid Contextual Design; Smartphone app development; Agile development; User- centered design; User interface prototyping

Examinator: Lars-Åke Nordén, Roland Bol Ämnesgranskare: Mats Lind

Handledare: Marcus Berner, Marcus Fredriksson

(4)

(5)

Popular scientific summary in Swedish

Utveckling av datorsystem eller program som ska användas av m˚anga olika människor kan ofta vara en tidskrävande utmaning. Att designa ett system som tar hänsyn till alla möjliga typer av användare, tillämpningar och förutsättningar kräver först˚aelse av sammanhanget i vilket systemet ska användas, och p˚a grund av industrins växande fokus p˚a mobila plattformar är krav om användbarhet större än n˚agonsin. Ett flertal olika metoder används för att samla denna typ av information inför och under användarcentrerade utvecklingsprojekt, varav en av de vanligaste är Rapid Contextual Design.

Den här metoden introducerades p˚a mitten av 1990-talet och har sedan dess an- passats successivt för att styra olika typer av projekt, fr˚an storskaliga banksys- tem till utbildningsplattformar, men är fortfarande märkbart sv˚ar att förena med de agila tillvägag˚angssätt som blir alltmer vanliga. Nu har smartphones banat väg för en ny generation av mjukvaruutveckling, där användbarhet och korta utvecklingscykler är avgörande faktorer för produkters framg˚ang, och p˚a grund av detta ställs nya krav p˚a utvecklare och projektmetodik. De projekt- grupper som utvecklar mobilappar är vanligtvis mindre och med kortare tidsra- mar än vad metoder som Rapid Contextual Design ursprungligen menades för, men kan änd˚a dra nytta av en användarcentrerad metod som gynnar produk- tens användbarhet. Detta gäller särskilt i de fall d˚a projektet har vaga m˚al vid utg˚angsläget.

Detta arbete har under en fallstudie tillämpat en anpassad version av Rapid Contextual Design till ett mobilprojekt för att undersöka hur metoden kan kortas ned utan att förlora relevans. Projektet utfördes ˚at Netlight Consult- ing AB i Stockholm, där internkommunikation mellan de ca. 500 anställda skulle förbättras genom en mobilapp och samtidigt gynna kunskapsdelning och nätverkande. Genom att planera en anpassad projektfas för användarcentrerad design baserat p˚a tekniker och moment i Rapid Contextual Design kunde en projektgrupp p˚a tv˚a personer ta fram en konkret kravspecifikation och slutligen realisera en fungerande applikation p˚a tolv veckor.

Undersökningen resulterade i en uppsättning riktlinjer som kan användas av projektledare för att hitta ett sätt att inkludera en användarcentrerad designfas i sitt smartphonebaserade projekt, samt r˚ad om vilka moment som kan utelämnas under vilka omständigheter för att korta ner processen eller e↵ektivt använda begränsade resurser.

(6)

(7)

Acknowledgements

First of all we the authors would like to thank our reviewer, Mats Lind, for his guidance and advisement during the course of the project.

Next we thank our two supervisors, Marcus Berner and Marcus Fredriksson, for their enthusiasm, commitment and support from day one all the way to the finish line. We would not have reached the result we managed to attain if not for their assistance.

We would also like to show our due appreciation for examiner Lars-˚Ake Nord´en, assisting examiner Roland Bol and coordinator Olle Eriksson for their time.

Finally we want to thank Emma Rangert and Anders Steinrud for their insights, encouragement and critique.

(8)

Glossary

Agile refers to a family of development methods that place emphasis on func- tionally working releases developed iteratively in working sprints, making implementation flexible and accommodating to sudden changes in specifi- cation. 1, 6, 9, 20, 21, 29, 61, 63

Android is an operating system used on mobile, touch screen devices (Android phones, Android tablets, Android wearables) and is created by Google Inc.. 28, 50

App is a colloquial short for application, referring to the often light-weight native programs available for smartphones. viii, 1, 2, 8, 9, 11, 13, 15, 24, 27, 28, 30–33, 35–38, 40, 41, 43–47, 49–52, 56–59, 61, 62

CCell or Competence Cell, is a group of employees at Netlight who share a common interest or expertise, wherein which seminars, talks and work- shops may be organized to promote knowledge sharing. 12, 13, 25, 26, 29–31, 36, 37, 41, 49

Client Netlight Consulting AB. 2, 9, 11, 15, 21, 23, 24, 26, 27, 29–31, 33, 38, 40, 41, 49, 50, 55

Customer is a company hiring the services of Netlight. 2, 11, 30, 32

End-user refers to any of the concrete persons intended to use the actual product, distinct from the abstract term ”user” which could be anyone who interacts with the app. 1, 2, 6, 8, 15–17, 19–21, 24, 28, 29, 31, 41, 43–45, 49–58, 61

IOS is an operating system used on mobile, touchscreen devices (iPhone, iPad, iPod) created by Apple Inc.. 13, 21, 27, 28, 31, 50, 51, 58

Knowledge sharing is the activity through which information, knowledge and expertise is shared across a community or group of people; it is a central theme in knowledge management, which is prevalent in many modern business strategies. 12, 25, 29, 33, 37, 49

Scrum is an agile development framework based on delivering functional solutions in sprints, and is very common in modern software development. 8, 21, 31, 46

Smartphone is any modern, conventional and personal phone with touch dis- play and features common to these devices, such as Internet connectivity, high resolution cameras and a third party application market. 1, 7–9, 24, 27, 45, 49, 51, 52, 57, 61, 62

XP or Extreme Programming, is an agile development method based on working in iterations, a formerly very popular development strategy now per- haps less prevalent. 5, 8, 21, 31–33, 46, 47, 67

(9)

Abbreviations

API application programming interface. 33, 38

CD contextual design. 1–3, 6–9, 11, 15, 17–19, 21, 43–46, 49–56, 58, 61–63 CI contextual inquiry. 8, 15, 16, 23, 43, 67

ERP enterprise research planning. 13, 21, 31, 40 ES Engagement Search. 12, 23, 35

FI First Impression. 23

FRCD focused rapid contextual design. 2, 7, 15–20, 23, 24, 27–29, 31, 40, 41, 49, 51, 53, 57

GUI graphical user interface. 21 HR human resources. 12, 23

IDE integrated development environment. 21 MVC model-view-controller. 2, 38

POC proof of concept. 49 TS Talent Search. 12, 23, 35 UCD user-centered design. 6

UI user interface. 20, 21, 27, 28, 33, 40, 41, 45, 49–53, 55–58, 62 UX user experience. 27, 33, 44, 45, 51, 52, 55–58, 62

VPN virtual private network. 21

(10)

(11)

1 Introduction

1.1 Setting

This report details the Master’s Thesis project conducted by Carl Ekman and Jonas Martinsson as part of the M.Sc. program in Computer and Information Engineering at Uppsala University, supervised by the Department of Informa- tion Technology. The project was done during the spring of 2014, from the 20th of January through the 11th of June, commissioned by Netlight Consulting — an IT consulting firm based in Stockholm, Sweden.

The management of Netlight wanted to better utilize the smartphones carried by their consultants, in order to improve communication and knowledge sharing across the quickly growing company. This project was conceived as an attempt to investigate how this could be done in the form of an app, and how such an app should be designed to best address the needs of the end-users.

Contextual Design (CD) is a user-centered design process for developing applications and interfaces that will be used by a known group of end-users. The design process is based on collecting data by surveying the usage context of the application, and then from there using a series of process steps that among other things incorporate contextual inquiry, visioning and prototyping in order to design a system interface. CD is described in detail in section 5.1.

1.2 Purpose and research questions

The main question this thesis sets out to answer is: how can Rapid Contextual Design be adapted for agile smartphone application development in small teams?

The contextual design process, introduced in 1992, has evolved alongside technological progress, and many di↵erent versions of the process is used today in di↵erent types of software development projects. [1] This study’s aim was to examine CD’s potential in the contemporary smartphone app development industry, specifically considering that the core methods in CD have not changed much since their inception, and the prospect of using certain tools in the process may have become more feasible than earlier. This lead to the following research questions:

• how applicable are CD and agile development methods when designing and developing new smartphone applications?

• how can a core team of two people best adapt the CD process to suit their limited resources?

• are modern, digital prototyping tools viable replacements or complements to the conventional paper prototyping process?

(16)

These questions are answered through the use of focused rapid contextual design (FRCD), a smaller scale version of CD, in attempting to satisfy the project client’s needs for a smartphone application for internal communication and knowledge sharing purposes. The requirements are met with a functional pilot product based on a strongly motivated set of features compatible with a long- term scalable outlook. The resulting app should at least be able to serve as a prototype or proof of concept for continued development.

It is the hope of the authors that the work presented in this thesis could be a starting point towards creating an adapted version of the rapid contextual design process for smartphone application development using agile methods in small teams.

1.3 Limitations and scope

As this was not a development-oriented thesis project, not all the details regarding actual implementation were covered. Some notes were made on the database structure and model-view-controller (MVC) pattern used to give an overview of the system.

Scalability and sustainability, in terms of responding to a major increase in the number of end-users, have been underlying themes throughout the entire development process, but reworking the client’s back-end systems to ensure any kind of measurable scalability in performance was too large an undertaking to be included in the scope of this project. Instead, attention was directed towards more interface-related factors, to ensure that the usability of the app would not be impeded by any increase in users during the international expansion the company is currently undergoing.

Ideally, the app developed during this project would have integrations for the client’s many business systems and databases, as well as for external sources of data and services. Such integrations introduced difficulties for implementation that would have consumed unexpected amounts of time. Instead features like these were to be presented on a conceptual level with suggestions for further added content and what likely implications these would have on the system.

This communication tool was meant for internal communication between employees only. No features related to contacting – or being contacted by – customers were included.

1.4 Thesis structure

In the first section, 1 Introduction, the setting has been laid out, the area of research has been introduced, the scope of thesis has been defined and the research questions have been declared. The next section, 2 Related theory and literature review, contains relevant theory and reading material regarding the subject matter.

(17)

In section 3 General method the method used to answer the research questions is defined, while the following three sections (4 Project case, 5 Design and development methods and 6 Design and development results) describe the case study this method is applied to.

Section 7 General results lists the results that correspond to the method declared in section 3, based on the data acquired through the case study in sections 4-6. These results and findings are then processed and discussed further in section 8 Discussion. Finally in section 9 Conclusions and future work conclusions are drawn and recommendations are made about the adaptation of contextual design.

(18)

(19)

2 Related theory and literature review

2.1 Agile development methods

Agile software development was created as a response to the traditional ways of developing software based on non-changing plans. The Agile Manifesto, written in 2001, details how its authors sought to introduce Agile as a better way to develop software than had earlier been done [2]. The key principles of Agile can be described as follows: to be able to respond to changes in software development projects instead of trying to prevent them, while realizing the value in working software and people as opposed to documentation and processes [3]. Developing products iteratively is also a core concept.

Lyytinen and Rose [4] claim that agility in software development projects is achieved in di↵erent ways depending on the nature and setting of the project.

This means that strictly following one method, such as Scrum or XP, is not necessarily the best option. Following one method gives the benefit of increased structure, but may also cause unnecessary amounts of overhead. The latter is especially true in projects of short length with a small scope and team.

Abrahamsson, Conboy and Wang hold that while research on Agile development has come far, there are still shortcomings in the amount of research done and how agility is defined [5]. This is supported by their claim that the development of Agile has mostly been driven by practitioners in industry.

Sections 2.1.1 and 2.1.2 describe the two agile methods drawn from in the development phase of this project.

2.1.1 Scrum

Scrum teams work in iterations that are one to four weeks long [6]. There are three main roles involved in the process: the Product Owner, the Scrum Master and the Development Team. The Product Owner represents the stakeholders and is in charge of prioritizing the work. The Development Team is a cross- functional team of up to 9 members. The Scrum Master is responsible for ensuring that the Development Team follows the Scrum process and that the team is able to fully perform their work [7].

2.1.2 Extreme Programming (XP)

XP shares many of its basic goals and activities with Scrum. It di↵ers in that iterations are typically shorter, one to two weeks, and in that it has defined programming practices [8]. These practices include pair programming, contin- uous integration, test-driven development, and on-site customer. Having an on-site customer means that an actual end-user should always be available for questions.

(20)

2.2 User-centered design and methods

Gulliksen et al. [9] define user-centered design (UCD) (also called user-centered systems design) as:

”a process focusing on usability throughout the entire development process and further throughout the system life cycle”.

The authors also present twelve key principles, upon which the definition is based: user focus, active user involvement, evolutionary systems development, simple design representations, prototyping, evaluate use in context, explicit and conscious design activities, a professional attitude, usability champion, holistic design, processes customization, and a user-centered attitude should always be established. Especially interesting is processes customization; that there needs to be a defined UCD process, and that this process needs to be customized to the environment in which it is used. This is considered further in section 2.5.

The same authors bring up a few points about the applicability of agile methods when working with user-centered design. They contend that some of the core concepts of agile are well-suited for user-centered design projects, such as the focus on face-to-face communication and the general focus on people of processes and tools [9]. Conversely, the emphasis on producing working software can quickly diminish the focus on usability.

The work of Gulliksen et al. considers the Scandinavian tradition of actively involving end-users in the design process, which makes it a fitting starting point for this thesis.

2.3 Contextual Design

Contextual design (CD) is a user-centered design process method introduced in 1992 by Karen Holtzblatt and Hugh Beyer, founders of InContext [1]. CD breaks down the design of a new system or tool into a manageable sequence of procedures to facilitate formulating a concrete system concept. It di↵erentiates itself from other design processes by specifically analyzing the environment and context in which the end-user performs the tasks that the system will a↵ect, and covers the early stages of design—requirement elicitation, workplace studies and end-user interviews. The pre-implementational design phase is divided into a chain of discernible steps, which are individually described in sections 4.1.1 through 4.1.5.

CD is today often used in conjunction with user-centered agile methods, which cover the later stages of development and testing. As the process is intended for practical and real situations where time and resources oftentimes are limited, its modular nature makes it flexible and adaptable to a great variety of projects. In Rapid contextual design [1] the core process is provided in three configurations (all more lightweight than the original CD process) from which one can choose:

Lightning Fast (one to four weeks), the most light-weight and compact form of

(21)

contextual design; Lightning Fast + (four to eight weeks), which adds more ro- bustness by including prototyping; and focused rapid contextual design (FRCD) (six to ten weeks), a comprehensive CD interpretation which was applied to this project. FRCD is slower than any of the Lightning Fast versions, but includes every step of the CD process. Table 1 shows a summary of the configurations explained above.

Rapid CD Process LF

(1-4 weeks)

LF+

(4-8 weeks)

FRCD (6-10 weeks) Contextual Interviews

with Interpretation

4-12 users 6-12 users 8-12 users Sequence Model with

Consolidation Affinity Diagrams Wall Walk and Visioning Storyboarding

Paper Mock-up Interviews with Interpretation

4-9 users 6-12 users

Table 1: Variants of Rapid CD. LF and LF+ here denotes the ”Lightning Fast”

and ”Lightning Fast +” methods respectively, and FRCD is ”Focused Rapid Contextual Design”. Gray color indicates that the corresponding step is not included in that variant.

The CD team is described as consisting of at least two out of three core roles:

the designer, someone experienced in interaction and visual design; the work practice professional, who has insight into the environmental context of the system design; and the developer, a technological professional [1]. While two of these should be working full time, it is advised to include the third as a part time helper.

2.4 Small teams

This thesis defines the term ”small teams” in the context of software development as a group of fewer than five developers, where the roles normally applied to project teams are harder to establish. Members of small teams usually have to assume responsibility for multiple parts of a project, such as requirements elicitation, design, development and testing. More importantly, small teams would typically have difficulties in assimilating resources and conducting some steps of the design processes discussed in this thesis.

In smartphone application development, teams are in practice small by this definition, since teams ranging from one to three developers per platform are commonplace.¹

1The sizes of smartphone application development teams are not well documented aca- demically, however contemporary industry practice revolves around small core teams (game development being an exception, where team size varies dramatically). Quantitative Software Management, Inc. have published a number of studies on the subject of small development

(22)

2.5 Related work

Researchers have found that using contextual design can both increase quality of developed products [10,11] and ease adoption of new products because of the insights gained into targeted users’ workflows [12]. The parts of CD dedicated to data gathering and analytics have been found especially useful in software development, while other parts are conversely in some contexts considered not as useful [13, 14]. Most if not all who apply CD modify or expand the method to better fit in their respective scenarios [10, 12, 13, 15].

The application of CD to smartphone app development has not seen much attention in terms of research. Much of the research available [14, 16] was made before the introduction of the iPhone, which radically changed the environment for smartphones and the complexity of applications for them [17, 18].

Notess [13] used contextual design to guide the design of a digital music library.

The author did not use all steps of the process; only Contextual inquiries (CIs), work modeling and consolidation. Notess does not reach any conclusive results in terms of the applicability of CD for their specific scenario, but is positive towards further exploration of the use of CD for similar projects. This work is related to ours in that the author did not use all aspects of CD as they are described in the literature. They rather saw the universal worth of gathering contextual information from the end-users’ actual work environment and then only utilized the remaining steps of CD partially. Otherwise Notess used processes already in place. The main di↵erence from the project case described in this thesis is that Notess’ aim was to create a product that supports an existing workflow, contrary to creating an application that is supporting some existing communication flows and introducing some functionality that is completely new.

Vilpola et al. [12] applied contextual design when implementing an enterprise resource planning system. The authors concluded that the introduction of CD into the development process improves the quality of the system’s usability, and helps ease the contextual change to the newly developed system compared to if it had been developed with less insight into the end-users’ work context. This relates to the project case described in this thesis in that it also introduces a new system for retrieving information regarding a company and its employees.

In the main Rapid CD literature, the two primary parameters considered when choosing between the three di↵erent forms of the process are time and scope [1].

This leaves opportunities for investigating potential other parameters that could be of importance when making this decision, as well as adapting the process to take these parameters into consideration.

One of the co-creators of CD, Hugh Beyer, has presented ways to combine the CD process with agile development methods [19]. This literature covers how to adapt Scrum and XP workflows to incorporate CD, but the author does not consider the value, if any, of also adapting the CD process to agile development methods.

teams in general, stating that smaller teams show higher efficiency and lower costs. More information is currently available at http://www.qsm.com/risk_02.html.

(23)

3 General method

3.1 Approach to research questions

The research questions posed in section 1.2 were examined through an explorative case study where a version of CD was applied to a modern smartphone design and development project, directed by a team of two members, from start to finish. A case study is the preferred strategy when the focus of the research questions are formulated as ”how” or ”why” [20, p. 9]. The choice to perform a case study was further motivated by the notion that this type of method is suitable ”when the focus is on a contemporary phenomenon within some real-life context” [20, p. 13].

The case, which is described in full in section 4, required the construction of a pilot app. It was also reasoned that an implementation would help the vision stay alive, and prompt the client to continue implementing it. While CD would be well suited for dealing with the design phase of the project, the team would need to carry out development in order to fully follow up on the case. The development phase of the case would be performed according to a combined version of agile development methods, which would build upon the CD results according to the transition procedures discussed by Holtzblatt et al. [1] and Beyer [19].

3.2 Data gathering through process application

During the case study each step of the CD process was evaluated, and notes were taken on which parts worked well and which parts did not. This was done in order to evaluate the applicability of CD to smartphone development projects in small teams, investigating both individual steps and the method as a whole.

The project was divided into two major phases, each six weeks in length and together encompassing the entire design and development progression from idea to realized working concept app.

The study was designed to produce qualitative results, based on explorative data derived from the user-centered method adaptation. The goal was to study the CD method in light of current industry technology and procedures, more specifically that of agile smartphone app development, and see whether adjust- ments can be made to help small teams steer clear of potentially avoidable steps while still gaining insight for design.

3.3 Case study structure

The case study approach is detailed in sections 4 through 6. The results of the study are presented in section 7 and analyzed in section 8. In section 9 the conclusions on how CD can be adapted to better suit projects similar to the project case are discussed further.

(24)

(25)

4 Project case

4.1 Client and background

This thesis project was carried out at Netlight Consulting AB, a Stockholm- based IT consulting firm founded in 1999. The company has since undergone rapid growth, and has expanded to offices in Oslo, Helsinki, London and Munich.

At time of writing the company has over 500 employed consultants working at a variety of customers’ offices, mainly in the Stockholm region. Since the number of new hires per year has increased consistently, the company’s management has been looking to develop tools that would make it easier to contact employees, and also make consultants’ skills more accessible to co-workers. This would make it easier to find assistance on a peer-to-peer basis and facilitate putting together teams for new projects.

4.2 Objective

The objective as presented by the Netlight management was the following: take internal communication to the next level using smartphone technology.

This has been a vague objective, and in order to reach a solution it was first necessary to identify and investigate how employees communicate, as well as what difficulties were experienced in workplace routines. Using CD to conduct a design pre-study to elicit requirements was well motivated in this case, since the aim was vaguely specified and the client was seemingly unaware of the concrete company needs. Examining these factor were necessary in order to produce a concept of an improved future workplace.

The goal of this project was to deliver a working pilot product as a proof of concept of the design produced through the use of CD. The pilot product did not need to be fully implemented, but should convey the functionality of the app.

It is worth mentioning that while there exists commercial o↵-the-shelf services that would satisfy some of the requirements found during the case study the client had already opted for a custom solution, exploring the possibilities of an in-house mobile app.

4.3 Communication and organizational structure

Netlight has its employees organized in a network structure. This is a modern form of organizational structure that is based on social network theory, and regarded as more flat [21] than classical hierarchical structures, in that it is more decentralized and flexible, allowing direct peer-to-peer communication between employees from di↵erent parts of the company.

(26)

Netlight is divided into four departments: Operations (Accounting, IT, First Impression, HR), Management, Sales (Engagement Search (ES), Talent Search (TS)) and Consultants. Members of all departments communicate freely with each other.

There currently exist a number of options for peer-to-peer communication within the company. In addition to email and telephone contact information available on Rebel, the company information wiki, there is an extensive social chat system, Yammer². This system is reminiscent of a generic social network site, with most of the features related to such services. It also contains the CCells, where employees may create groups devoted to or interested in certain fields.

Yammer is used for both formal and informal communication, focused on sub- jects ranging from spare time interests to knowledge enrichment activities for productive teams. Aside from Yammer, most internal communication is done through Skype³.

4.4 Competence cells and knowledge sharing

Developing talent and expertise among its employees is one of Netlight’s highest priorities. Thus, tools have been created to promote knowledge sharing. This agenda is manifested in the form of CCells and EDGE. The former are group initiatives driven by employees themselves who want to either learn about a specific subject, or teach others about it. Many of these CCells are focused on technology or business, but there are also CCells for casual hobbies and spare time interests. The organizers of CCells have resources supplied by the company at their disposal for holding seminars, talks or lectures.

EDGE is an initiative that summarizes the ways in which Netlight employees maintain, develop and share current valuable knowledge and competences.

There are EDGE seminars that educate interested employees and new recruits about new technologies and development techniques, as well as EDGE Academy which is held on evenings during one week of each year and may include specially invited guests.

Knowledge sharing and talent growth are deemed important to the continued success of the company, and so creating an information technology basis for them has been an underlying focus of this project.

4.5 Company growth and expansion

While currently having a physical presence in Stockholm, Oslo, Helsinki, London and Munich, expansion to multiple new countries is being planned as branch organizations throughout northern and western Europe. This means that any

2Yammer, Inc. is a freemium enterprise social networking service that was launched in 2008 and sold to Microsoft in 2012.

3Skype is a freemium voice-over-IP service and instant messaging client, currently developed by the Microsoft Skype Division.

(27)

application being developed must ensure scalability and maintainability so that it can grow with the company. Because of this there are also challenges regarding internationalization.

4.6 Previous work

A year prior to the start of this project, an attempt was made to produce a solution to the problems described in section 4.1. The result of that project was an iOS app called Koala, where the user could search for and view information about employees and customers. Information about the location of an employee had to be provided by that employee themself, through a check-in feature which required that they were present at the location at the time of action. The app could also access information about which project a given consultant was attached to. The customer information consisted of company name and country. Koala had its own back-end, where information about employees and projects was retrieved from Netlight’s enterprise research planning (ERP) system and then cached. The back-end was taken down at some point in time after the departure of the developer, which caused the app to no longer function as intended. Koala is no longer maintained.

In 2013, the CCell for mobile platforms collectively developed an iOS app called One Netlight, where the user could browse Netlight employees by name and see their photo and telephone number. One Netlight got its data by scraping the employee directory wiki page. When some part of a page changed in layout however, bugs got introduced which made the app practically unusable. These bugs were never fixed.

Another tool created in 2013 was Net-CA, a responsive web interface created for both desktop and mobile browsers, that allows the sales department to quickly find available consultants. The employees can be filtered and sorted according to skills, experience and earliest available date. Contacting the consultants in question cannot be done through this interface. Net-CA is developed and maintained internally. The sales department enters information about each consultant into the application’s back-end database (which also gathers data from the ERP system), so the consultants themselves typically do not interact with the system directly.

(28)

(29)

5 Design and development methods

5.1 Contextual Design

5.1.1 Choosing CD version

The CD pre-study was conducted on site at Netlight headquarters between February 10 and March 21 2014, with the intent of mapping the requirements of a communications app that would assist the employees and management of the client both currently and for the foreseeable future. The application of CD to this project was mainly motivated by its compatibility with the characteristics described in the 2004 publication Interactive Technologies: Rapid Contextual Design: A How-to Guide to Key Techniques for User-Centered Design by Karen Holtzblatt, Jessamyn Burns Wendell and Shelly Wood [1]. Many fundamental prerequisites for conducting a CD study were deemed compliant with the nature of the project—such as having a core team of two people, preferably a designer and a developer (formally taken on by Ekman and Martinsson respectively).

However, Holtzblatt et al. recommend that the third role (in this case the workplace practice professional ) be included to some degree. The duties of the third role were shared by several available stakeholders—mainly the two project supervisors, both being experienced technical consultants.

The version of CD chosen for this case was the Focused Rapid CD (FRCD) approach, which is the most demanding and inclusive alternative provided by Holtzblatt et al. in their publications of the Rapid CD method [1]. In contrast to the other versions suggested (Lightning Fast and Lightning Fast +) it has not been stripped of any steps in the design process, but instead usually requires considerably longer execution time. It was reasoned that a thorough use of the method in its entirety would give the project results a strongly motivated foundation that would add the most value to all parties involved. In this chapter the abbreviation FRCD will be used when detailing the steps of the method.

Note that some of the steps are present in other versions of CD as well.

Although FRCD was the most fitting approach for the project, the parameters were picked to allow for a lightweight execution in as short a timespan as possible. This was due to the influence of two factors: the sparse number of helpers available at the client’s headquarters, which limits the number of possible interviewees and consequently the interpretation of that data; and the time required to attain a significant state of completion before deadline of the thesis project.

5.1.2 Contextual inquiries

contextual inquiry (CI) is the part of FRCD where user data is collected, which serves as the basis for further discussion. The ideal scenario is to perform two- hour interviews with a set of end-users in their natural work environment. In this context, “interview” does not mean eliciting answers to a set of written questions during normal dialogue. The idea is instead to watch the end-user

(30)

carry out their daily work routine, and to make notes of how they solve problems or tasks. The interviewer will occasionally interpose questions to clarify certain actions or to ask the interviewee how they are reasoning. In some regards this is more similar to a set of job shadowing procedures than interviews.

Finding the right interviewees require analysis of the system context. The number of interviewees that can be accommodated depends on the type of function the system will perform, and how many job roles are present in this context.

Then choosing which sample roles are to represent the user base must be done carefully so that the results from the survey will fairly a↵ect the direction of design. Thus it is also important to remember to look for relevant di↵erences and likenesses between candidate interviewees when sampling the end-users.

If the interviewer notices that it is unlikely the interviewee will run into situations that would provide data relevant to the FRCD process, the interviewer has the ability to collect retrospective accounts of previous activities. These activities should not be more than two weeks old. When collecting a retrospective account, the interviewer asks the interviewee to walk the interviewer through the event by repeating the actions as they were done the first time. If the interview has to take place outside of the actual work place, e.g., for confidentiality issues, the interviewer will have to rely on retrospective accounts.

It is preferable for the interviewer to take notes on paper, both to be able to follow the interviewee around should it be necessary and to not seem excluding by looking at the monitor when typing.

5.1.3 Contextual inquiry interpretation

To analyze and organize data from the CI sessions, the FRCD team meets for interpretation sessions. Interpretation of CI data should happen within 48 hours of completing the interview, to make sure that it is still fresh in memory. Present at this session are the FRCD team members and any possible helpers.

There are several roles in an interpretation session. The interviewer reads their notes from the CI interview and the note taker constructs notes based on the input from all team members. Additionally there can be any number of general team members present, one of which can also be responsible for creating work models (explained in section 5.1.4). If the team is bigger than the standard of two members, there can also arise a need for a moderator. This person is responsible for keeping the interpretation discussion on track.

The first step of the session is to create user and organization profiles. Each interviewee is represented by a code instead of their name, to keep their identity confidential. The profiles describe characteristics of the users and organizations;

such as age, years of experience and size of the organization. The interviewer uses the profiles to introduce the organization and user to the interpretation team. After capturing the profiles, the interviewer presents either a photograph or a drawing of the physical workplace the interview was conducted at, to help the participants contextualize the interview information.

(31)

When walking the rest of the team through the interview, the interviewer goes through their unabridged notes and recollections. The session participants in- terrupt and ask questions to elicit deeper insights from the rest of the team. If any of the participants notice any information they think constitutes a key idea for the interview, they call for it to be captured. The note taker writes all of these key ideas down. In FRCD, these are known as affinity notes.

Relevant things to capture are interpretations of problems, events and opportunities in the workplace. If any of the session participants have design ideas or further questions for the interviewee these are also written down. They are however not discussed at this session, since the design comes at a later stage in the process and questions should be directed at the person who can answer them. If the interviewee has said anything during the interview that can be used later as a quote to highlight a certain issue, this is also captured. While the interviewer is going through their material, one of the participants captures the sequence model, which shows the steps the user takes to complete tasks.

The last part of the interpretation session is capturing insights, which are high- level observations made when summarizing and reflecting on the interview. In- sights are used to communicate key findings from the interpretation session to stakeholders and other interested parties.

5.1.4 Work modeling

Work models provide di↵erent views on the structure of how end-users conduct their work, and are drawn during the interpretation session. Two of the standard CD work models, the cultural and flow models, are not a part of the rapid variant of CD [1] and will not be described here. The three models used are as follows.

The sequence model is a detailed step-by-step description of either an observed event or a retrospective account from a Contextual Inquiry interview. Together with the actual steps themselves, triggers are captured to show what situation made the user decide to take a specific step or start working on a new task;

and intents are captured to identify the reasons behind a step or task. If the user experiences an unexpected problem, this is marked as a breakdown. The sequence models are consolidated, as described in section 5.1.6, to show common patterns between di↵erent users.

The physical model is a depiction of the physical environment, including the objects in it, where the user does their work. It can show how the workspace is used and how it is potentially a↵ecting the user.

The artifact model is a copy or portrayal of any object that the user creates, uses or references to complete a task. The aim is to capture how the object is structured, how and when the it is used and with what intents.

When the work models are completed, some aspects of them can be used to write additional affinity notes. Breakdowns and intents are captured for all models, together with issues specific for the di↵erent models.

(32)

5.1.5 Building the affinity diagram

The affinity diagram represents a first unified view of the major issues that need to be addressed in the resulting design. The diagram is built from the affinity notes written during the interpretation sessions. Where each contextual interview highlights the key issues and work structure of an individual, the final affinity diagram is a tree structure that can be used to gain higher-level insights and show the hierarchical relation of these. In preparation for this step of the FRCD process, all affinity notes need to be put on pieces of paper that can be put on a board.

Constructing the diagram starts with getting all the affinity notes up on the board. Notes relating to a common observation are put in a column together. If a column gets too big, meaning it has more than around six notes, it generally shows that there are other distinctions in it that can be broken out into its own column. When all notes are either in a column or discarded for not fitting into one, the columns are combined into higher-level observations. The resulting groups are then divided into top-level ideas that complete the tree-like structure of the finished diagram. All note groups have a description written in the voice of the end-user, to make the FRCD team consider the observations from the users’ point of view.

Figure 1: Structure of an affinity diagram.

A column represents a key work distinction that will be relevant when designing the prototype. A group of columns represents a theme common between columns, and the top-level groups describe a part of the big picture, e.g., major steps of a process or a communication strategy. If the FRCD team is able to enlist helpers to assist in building the affinity diagram, the time needed to complete it can be shortened substantially; especially the first phase since it is closer to being linear in nature than later phases.

5.1.6 Consolidating models

FRCD involves capturing three work models, but only the sequence model is consolidated. The physical and artifact models are kept as auxiliary resources.

The Lightning Fast and Lightning Fast + versions of CD do not include model consolidation.

(33)

Sequence consolidation includes looking at tasks from di↵erent people where all have di↵ering triggers, intents, steps and breakdowns. The idea is to show abstract underlying steps common between people doing di↵erent tasks with di↵erent intents and experiencing varying breakdowns, and can therefore be used to design functionality that is useful in more than one job role.

The result can then be used to redesign current ways of performing a task, or supporting the task in a new system. Sequence consolidation is preferably done in groups of two, but the first consolidation should be done with the whole group to establish a common understanding of how the process is going to work.

The first part in consolidating the sequences consists of choosing the three that are most central to the work, while also being detailed enough and having overlapping steps. Then the triggers for each sequence are identified. Sequences are comprised of a number of steps, and sets of steps that can combined into a higher-level action aiming to accomplish a certain intent are noted as activities.

This is done for all of the three sequences. The activities have their own intents, which need to be identified. When looking through the steps of an activity, abstract versions of them are created if they are used by more than one person.

A consolidated activity consists of an intent and abstract steps to achieve it. A consolidated sequence consists of consolidated activities.

5.1.7 Constructing personas

End-user personas represent the major job roles of the user base, and are con- structed from the body of affinity notes and interview material gathered previ- ously during the investigation. This part of the CD process is only included in FRCD. A persona does not describe a single person interviewed, but rather a combination of attributes from all users in common job roles and with common needs. Personas have a one-page description that summarizes who they are and what they do. The description includes goals, tasks and roles. Goals are high-level accomplishments that the persona tries to achieve, or tries to sustain over a period of time. Tasks are discrete pieces of work that can be attributed to the persona. Roles described in the text are the di↵erent responsibilities the persona has in their daily work.

Personas provide the core team and stakeholders with more context, which is useful when considering the design. With more tangible knowledge about the users the FRCD project is going to support, the more informed decisions members and stakeholders of the FRCD team can make.

5.1.8 Walking the affinity model and consolidating sequences

When the affinity model is finished and sequence models have been consolidated, the team proceeds to walk the models together with stakeholders, sometimes referred to as the wall walk. FRCD suggests that the team should have a dedicated room where they can have keep all relevant progress visible on the

(34)

walls for all who are interested in following it. Walking in this context means to go through all of the collected data to create a systemic understanding of it.

This is important for keeping all stakeholders up to date on the project.

Walking the data can leave results in three di↵erent ways: design ideas, holes and questions. Participants may come up with not only features they see the project being able to provide; but also strategies, concepts and implementation possibilities. These are collectively referred to as design ideas. Instances where the affinity or sequence models seem to be missing information are called holes.

They can both show areas that need to be explored more, as well as expose expectations that were not necessarily accurate at the outset. Questions are related to holes but di↵er from them in that they raise concerns about information that is present but may need to be investigated further.

5.1.9 Visioning

To start the creative process of coming up with solutions to the problems and challenges outlined by the previous steps, a visioning session should be held.

These meetings are supposed to generate a conceptual vision of what the future workplace or context of use will be like when the project has been completed, not necessarily restricted by any of the technological constraints that may apply during actual implementation. The sessions are done in groups of no more than ten, but should include as many of the stakeholders as possible. If development is agile, then it will most likely benefit from a common vision shared by both developers and owners.

The visions themselves consist of large hand drawn pictures that depict the future, as altered by the project result, from the perspective of the intended end-user. The visions are high-level, without much implementation or user interface (UI) details. However they should not be vague, and ought to produce a set of usable user stories based on the tasks in the sequence models. Ideally the meeting will produce several visions which can then be compared, analyzed and consolidated into a single, finished vision that comply with most of the requirements construed from the investigation results.

5.1.10 Prototyping and final design

The last steps of the FRCD method is constructing and testing the final design through prototyping. First the storyboards and visions are walked in order to reiterate the functionality the design should support. Then brainstorming and hand drawing of UI elements start, producing a multitude of approaches and angles to addressing the features. These hand drawn prototype UIs are preferably made on paper in the interest of time, as each new design is likely to be reworked very soon. Fast and informal evaluations of the early prototypes are made, scrapping the unfavorable versions and keeping promising UI layouts and metaphors.

Adapting Rapid Contextual Design for Smartphone App Development: User-Centered Design for Small Teams

Examensarbete 30 hp Oktober 2014

Adapting Rapid Contextual Design for Smartphone App Development

User-Centered Design for Small Teams Carl Ekman

Jonas Martinsson

Abstract

Adapting Rapid Contextual Design for Smartphone App Development

Popular scientific summary in Swedish

Acknowledgements

Glossary

Abbreviations

Contents

1 Introduction

2 Related theory and literature review

3 General method

4 Project case

5 Design and development methods