adapting rapid contextual design for smartphone app...
TRANSCRIPT
UPTEC IT 14 015
Examensarbete 30 hpOktober 2014
Adapting Rapid Contextual Design for Smartphone App Development
User-Centered Design for Small Teams
Carl EkmanJonas Martinsson
ii
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 SmartphoneApp 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
ISSN: 1401-5749, UPTEC IT 14 015Examinator: Lars-Åke Nordén, Roland BolÄmnesgranskare: Mats LindHandledare: Marcus Berner, Marcus Fredriksson
iv
Popular scientific summary in Swedish
Utveckling av datorsystem eller program som ska anvandas av manga olikamanniskor kan ofta vara en tidskravande utmaning. Att designa ett system somtar hansyn till alla mojliga typer av anvandare, tillampningar och forutsattningarkraver forstaelse av sammanhanget i vilket systemet ska anvandas, och pa grundav industrins vaxande fokus pa mobila plattformar ar krav om anvandbarhetstorre an nagonsin. Ett flertal olika metoder anvands for att samla denna typav information infor och under anvandarcentrerade utvecklingsprojekt, varav enav de vanligaste ar Rapid Contextual Design.
Den har metoden introducerades pa mitten av 1990-talet och har sedan dess an-passats successivt for att styra olika typer av projekt, fran storskaliga banksys-tem till utbildningsplattformar, men ar fortfarande markbart svar att forenamed de agila tillvagagangssatt som blir alltmer vanliga. Nu har smartphonesbanat vag for en ny generation av mjukvaruutveckling, dar anvandbarhet ochkorta utvecklingscykler ar avgorande faktorer for produkters framgang, och pagrund av detta stalls nya krav pa utvecklare och projektmetodik. De projekt-grupper som utvecklar mobilappar ar vanligtvis mindre och med kortare tidsra-mar an vad metoder som Rapid Contextual Design ursprungligen menades for,men kan anda dra nytta av en anvandarcentrerad metod som gynnar produk-tens anvandbarhet. Detta galler sarskilt i de fall da projektet har vaga mal vidutgangslaget.
Detta arbete har under en fallstudie tillampat en anpassad version av RapidContextual Design till ett mobilprojekt for att undersoka hur metoden kankortas ned utan att forlora relevans. Projektet utfordes at Netlight Consult-ing AB i Stockholm, dar internkommunikation mellan de ca. 500 anstalldaskulle forbattras genom en mobilapp och samtidigt gynna kunskapsdelning ochnatverkande. Genom att planera en anpassad projektfas for anvandarcentreraddesign baserat pa tekniker och moment i Rapid Contextual Design kunde enprojektgrupp pa tva personer ta fram en konkret kravspecifikation och slutligenrealisera en fungerande applikation pa tolv veckor.
Undersokningen resulterade i en uppsattning riktlinjer som kan anvandas avprojektledare for att hitta ett satt att inkludera en anvandarcentrerad designfas isitt smartphonebaserade projekt, samt rad om vilka moment som kan utelamnasunder vilka omstandigheter for att korta ner processen eller e↵ektivt anvandabegransade resurser.
v
vi
Acknowledgements
First of all we the authors would like to thank our reviewer, Mats Lind, for hisguidance 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 thefinish line. We would not have reached the result we managed to attain if notfor their assistance.
We would also like to show our due appreciation for examiner Lars-Ake Norden,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.
vii
Glossary
Agile refers to a family of development methods that place emphasis on func-tionally working releases developed iteratively in working sprints, makingimplementation 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 (Androidphones, Android tablets, Android wearables) and is created by GoogleInc.. 28, 50
App is a colloquial short for application, referring to the often light-weightnative 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 acommon 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 prod-uct, distinct from the abstract term ”user” which could be anyone whointeracts 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 andexpertise is shared across a community or group of people; it is a centraltheme in knowledge management, which is prevalent in many modernbusiness strategies. 12, 25, 29, 33, 37, 49
Scrum is an agile development framework based on delivering functional solu-tions 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 work-ing in iterations, a formerly very popular development strategy now per-haps less prevalent. 5, 8, 21, 31–33, 46, 47, 67
viii
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
ix
x
Contents
Glossary viii
Abbreviations ix
1 Introduction 1
1.1 Setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Purpose and research questions . . . . . . . . . . . . . . . . . . . 1
1.3 Limitations and scope . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Thesis structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Related theory and literature review 5
2.1 Agile development methods . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Extreme Programming (XP) . . . . . . . . . . . . . . . . 5
2.2 User-centered design and methods . . . . . . . . . . . . . . . . . 6
2.3 Contextual Design . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Small teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 General method 9
3.1 Approach to research questions . . . . . . . . . . . . . . . . . . . 9
3.2 Data gathering through process application . . . . . . . . . . . . 9
3.3 Case study structure . . . . . . . . . . . . . . . . . . . . . . . . . 9
4 Project case 11
4.1 Client and background . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3 Communication and organizational structure . . . . . . . . . . . 11
xi
4.4 Competence cells and knowledge sharing . . . . . . . . . . . . . . 12
4.5 Company growth and expansion . . . . . . . . . . . . . . . . . . 12
4.6 Previous work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5 Design and development methods 15
5.1 Contextual Design . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1.1 Choosing CD version . . . . . . . . . . . . . . . . . . . . . 15
5.1.2 Contextual inquiries . . . . . . . . . . . . . . . . . . . . . 15
5.1.3 Contextual inquiry interpretation . . . . . . . . . . . . . . 16
5.1.4 Work modeling . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.5 Building the a�nity diagram . . . . . . . . . . . . . . . . 18
5.1.6 Consolidating models . . . . . . . . . . . . . . . . . . . . 18
5.1.7 Constructing personas . . . . . . . . . . . . . . . . . . . . 19
5.1.8 Walking the a�nity model and consolidating sequences . 19
5.1.9 Visioning . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1.10 Prototyping and final design . . . . . . . . . . . . . . . . 20
5.2 User-centered agile development . . . . . . . . . . . . . . . . . . 21
5.3 Software setup and revision control . . . . . . . . . . . . . . . . . 21
6 Design and development results 23
6.1 Carrying out the CD study . . . . . . . . . . . . . . . . . . . . . 23
6.1.1 Conducting CI interviews . . . . . . . . . . . . . . . . . . 23
6.1.2 Interpreting and consolidating inquiry results . . . . . . . 24
6.1.3 Building the a�nity model and diagram . . . . . . . . . . 24
6.1.4 Visioning seminars and storyboarding . . . . . . . . . . . 26
6.1.5 Formulating system requirements and data dependencies . 26
6.1.6 Choosing online wireframing over paper prototyping . . . 27
6.1.7 Designing prototypes . . . . . . . . . . . . . . . . . . . . . 27
xii
6.1.8 Performing prototype interviews . . . . . . . . . . . . . . 28
6.2 Concluding design and preparing for development . . . . . . . . . 29
6.2.1 Features designed during the FRCD study . . . . . . . . . 29
6.2.2 Writing user stories and concept specification . . . . . . . 29
6.2.3 Adopting an agile development process . . . . . . . . . . . 29
6.2.4 Release planning and iteration schedule . . . . . . . . . . 31
6.3 Implementing the app design . . . . . . . . . . . . . . . . . . . . 33
6.3.1 App structure . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.3.2 Employee profiles . . . . . . . . . . . . . . . . . . . . . . . 36
6.3.3 Knowledge sharing . . . . . . . . . . . . . . . . . . . . . . 37
6.3.4 Networking and overview . . . . . . . . . . . . . . . . . . 37
6.3.5 Pilot product app . . . . . . . . . . . . . . . . . . . . . . 38
6.4 Implementation schedule . . . . . . . . . . . . . . . . . . . . . . . 40
6.4.1 Iteration 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.4.2 Iteration 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.4.3 Iteration 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7 General results 43
7.1 Applicability of Rapid CD . . . . . . . . . . . . . . . . . . . . . . 43
7.2 Rapid CD for small teams . . . . . . . . . . . . . . . . . . . . . . 45
7.3 Digital complements to paper prototyping . . . . . . . . . . . . . 46
7.4 Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8 Discussion 49
8.1 Case study reflections . . . . . . . . . . . . . . . . . . . . . . . . 49
8.1.1 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
8.1.2 Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
8.2 Quality of results . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
xiii
8.2.1 Project results in relation to client requirements . . . . . 49
8.3 Evaluating UI and UX . . . . . . . . . . . . . . . . . . . . . . . . 50
8.4 Method analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.4.1 Properties of smartphone development and design . . . . 51
8.4.2 Applicability of Rapid CD . . . . . . . . . . . . . . . . . . 52
8.4.3 Introducing additional qualification parameters . . . . . . 53
8.4.4 Qualification parameters applied to case project . . . . . 54
8.4.5 Qualification parameters applied to fictional examples . . 55
8.5 Digital and physical prototyping . . . . . . . . . . . . . . . . . . 56
8.5.1 The prototyping process . . . . . . . . . . . . . . . . . . . 56
8.5.2 Prototyping in this particular project . . . . . . . . . . . 57
8.5.3 Trade-o↵ considerations . . . . . . . . . . . . . . . . . . . 58
9 Conclusions and future work 61
9.1 General conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 61
9.2 Process adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . 62
9.3 Prototyping recommendations . . . . . . . . . . . . . . . . . . . . 62
9.4 Suggestions for future work . . . . . . . . . . . . . . . . . . . . . 62
xiv
1 Introduction
1.1 Setting
This report details the Master’s Thesis project conducted by Carl Ekman andJonas Martinsson as part of the M.Sc. program in Computer and InformationEngineering at Uppsala University, supervised by the Department of Informa-tion Technology. The project was done during the spring of 2014, from the 20thof 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 carriedby their consultants, in order to improve communication and knowledge sharingacross the quickly growing company. This project was conceived as an attemptto investigate how this could be done in the form of an app, and how such anapp should be designed to best address the needs of the end-users.
Contextual Design (CD) is a user-centered design process for developing appli-cations and interfaces that will be used by a known group of end-users. Thedesign process is based on collecting data by surveying the usage context ofthe application, and then from there using a series of process steps that amongother things incorporate contextual inquiry, visioning and prototyping in orderto 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 ContextualDesign be adapted for agile smartphone application development in small teams?
The contextual design process, introduced in 1992, has evolved alongside tech-nological progress, and many di↵erent versions of the process is used today indi↵erent types of software development projects. [1] This study’s aim was toexamine CD’s potential in the contemporary smartphone app development in-dustry, specifically considering that the core methods in CD have not changedmuch since their inception, and the prospect of using certain tools in the processmay have become more feasible than earlier. This lead to the following researchquestions:
• how applicable are CD and agile development methods when designingand developing new smartphone applications?
• how can a core team of two people best adapt the CD process to suit theirlimited resources?
• are modern, digital prototyping tools viable replacements or complementsto the conventional paper prototyping process?
1
These questions are answered through the use of focused rapid contextual de-sign (FRCD), a smaller scale version of CD, in attempting to satisfy the projectclient’s needs for a smartphone application for internal communication andknowledge sharing purposes. The requirements are met with a functional pilotproduct 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 aprototype or proof of concept for continued development.
It is the hope of the authors that the work presented in this thesis could bea starting point towards creating an adapted version of the rapid contextualdesign process for smartphone application development using agile methods insmall teams.
1.3 Limitations and scope
As this was not a development-oriented thesis project, not all the details regard-ing actual implementation were covered. Some notes were made on the databasestructure and model-view-controller (MVC) pattern used to give an overview ofthe system.
Scalability and sustainability, in terms of responding to a major increase inthe number of end-users, have been underlying themes throughout the entiredevelopment process, but reworking the client’s back-end systems to ensure anykind of measurable scalability in performance was too large an undertaking tobe included in the scope of this project. Instead, attention was directed towardsmore interface-related factors, to ensure that the usability of the app wouldnot be impeded by any increase in users during the international expansion thecompany is currently undergoing.
Ideally, the app developed during this project would have integrations for theclient’s many business systems and databases, as well as for external sources ofdata and services. Such integrations introduced di�culties for implementationthat would have consumed unexpected amounts of time. Instead features likethese were to be presented on a conceptual level with suggestions for furtheradded content and what likely implications these would have on the system.
This communication tool was meant for internal communication between em-ployees only. No features related to contacting – or being contacted by – cus-tomers were included.
1.4 Thesis structure
In the first section, 1 Introduction, the setting has been laid out, the area ofresearch has been introduced, the scope of thesis has been defined and theresearch questions have been declared. The next section, 2 Related theory andliterature review, contains relevant theory and reading material regarding thesubject matter.
2
In section 3 General method the method used to answer the research questionsis defined, while the following three sections (4 Project case, 5 Design and devel-opment methods and 6 Design and development results) describe the case studythis method is applied to.
Section 7 General results lists the results that correspond to the method de-clared in section 3, based on the data acquired through the case study in sections4-6. These results and findings are then processed and discussed further in sec-tion 8 Discussion. Finally in section 9 Conclusions and future work conclusionsare drawn and recommendations are made about the adaptation of contextualdesign.
3
4
2 Related theory and literature review
2.1 Agile development methods
Agile software development was created as a response to the traditional ways ofdeveloping software based on non-changing plans. The Agile Manifesto, writtenin 2001, details how its authors sought to introduce Agile as a better way todevelop software than had earlier been done [2]. The key principles of Agile canbe described as follows: to be able to respond to changes in software developmentprojects instead of trying to prevent them, while realizing the value in workingsoftware and people as opposed to documentation and processes [3]. Developingproducts iteratively is also a core concept.
Lyytinen and Rose [4] claim that agility in software development projects isachieved 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 notnecessarily the best option. Following one method gives the benefit of increasedstructure, but may also cause unnecessary amounts of overhead. The latter isespecially true in projects of short length with a small scope and team.
Abrahamsson, Conboy and Wang hold that while research on Agile developmenthas come far, there are still shortcomings in the amount of research done andhow agility is defined [5]. This is supported by their claim that the developmentof 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 de-velopment phase of this project.
2.1.1 Scrum
Scrum teams work in iterations that are one to four weeks long [6]. There arethree main roles involved in the process: the Product Owner, the Scrum Masterand the Development Team. The Product Owner represents the stakeholdersand 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 forensuring that the Development Team follows the Scrum process and that theteam 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 thatiterations are typically shorter, one to two weeks, and in that it has definedprogramming practices [8]. These practices include pair programming, contin-uous integration, test-driven development, and on-site customer. Having anon-site customer means that an actual end-user should always be available forquestions.
5
2.2 User-centered design and methods
Gulliksen et al. [9] define user-centered design (UCD) (also called user-centeredsystems design) as:
”a process focusing on usability throughout the entire developmentprocess and further throughout the system life cycle”.
The authors also present twelve key principles, upon which the definition isbased: user focus, active user involvement, evolutionary systems development,simple design representations, prototyping, evaluate use in context, explicit andconscious design activities, a professional attitude, usability champion, holisticdesign, processes customization, and a user-centered attitude should always beestablished. Especially interesting is processes customization; that there needsto be a defined UCD process, and that this process needs to be customized tothe 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 methodswhen working with user-centered design. They contend that some of the coreconcepts of agile are well-suited for user-centered design projects, such as thefocus on face-to-face communication and the general focus on people of processesand tools [9]. Conversely, the emphasis on producing working software canquickly diminish the focus on usability.
The work of Gulliksen et al. considers the Scandinavian tradition of activelyinvolving end-users in the design process, which makes it a fitting starting pointfor this thesis.
2.3 Contextual Design
Contextual design (CD) is a user-centered design process method introducedin 1992 by Karen Holtzblatt and Hugh Beyer, founders of InContext [1]. CDbreaks down the design of a new system or tool into a manageable sequence ofprocedures to facilitate formulating a concrete system concept. It di↵erentiatesitself from other design processes by specifically analyzing the environment andcontext in which the end-user performs the tasks that the system will a↵ect, andcovers the early stages of design—requirement elicitation, workplace studies andend-user interviews. The pre-implementational design phase is divided into achain of discernible steps, which are individually described in sections 4.1.1through 4.1.5.
CD is today often used in conjunction with user-centered agile methods, whichcover the later stages of development and testing. As the process is intended forpractical and real situations where time and resources oftentimes are limited, itsmodular nature makes it flexible and adaptable to a great variety of projects. InRapid 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
6
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 thisproject. FRCD is slower than any of the Lightning Fast versions, but includesevery step of the CD process. Table 1 shows a summary of the configurationsexplained above.
Rapid CD Process LF(1-4 weeks)
LF+(4-8 weeks)
FRCD(6-10 weeks)
Contextual Interviewswith Interpretation
4-12 users 6-12 users 8-12 users
Sequence Model withConsolidationA�nity DiagramsWall Walk and VisioningStoryboardingPaper Mock-up Interviewswith 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 RapidContextual Design”. Gray color indicates that the corresponding step is notincluded 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 workpractice professional, who has insight into the environmental context of thesystem design; and the developer, a technological professional [1]. While two ofthese should be working full time, it is advised to include the third as a parttime helper.
2.4 Small teams
This thesis defines the term ”small teams” in the context of software develop-ment as a group of fewer than five developers, where the roles normally appliedto project teams are harder to establish. Members of small teams usually haveto assume responsibility for multiple parts of a project, such as requirementselicitation, design, development and testing. More importantly, small teamswould typically have di�culties in assimilating resources and conducting somesteps of the design processes discussed in this thesis.
In smartphone application development, teams are in practice small by thisdefinition, since teams ranging from one to three developers per platform arecommonplace.1
1The sizes of smartphone application development teams are not well documented aca-demically, however contemporary industry practice revolves around small core teams (gamedevelopment being an exception, where team size varies dramatically). Quantitative SoftwareManagement, Inc. have published a number of studies on the subject of small development
7
2.5 Related work
Researchers have found that using contextual design can both increase qualityof developed products [10,11] and ease adoption of new products because of theinsights gained into targeted users’ workflows [12]. The parts of CD dedicatedto data gathering and analytics have been found especially useful in softwaredevelopment, while other parts are conversely in some contexts considered notas useful [13, 14]. Most if not all who apply CD modify or expand the methodto better fit in their respective scenarios [10, 12,13,15].
The application of CD to smartphone app development has not seen muchattention in terms of research. Much of the research available [14,16] was madebefore the introduction of the iPhone, which radically changed the environmentfor 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 resultsin terms of the applicability of CD for their specific scenario, but is positivetowards further exploration of the use of CD for similar projects. This workis related to ours in that the author did not use all aspects of CD as they aredescribed in the literature. They rather saw the universal worth of gatheringcontextual information from the end-users’ actual work environment and thenonly utilized the remaining steps of CD partially. Otherwise Notess used pro-cesses already in place. The main di↵erence from the project case described inthis thesis is that Notess’ aim was to create a product that supports an existingworkflow, contrary to creating an application that is supporting some existingcommunication flows and introducing some functionality that is completely new.
Vilpola et al. [12] applied contextual design when implementing an enterpriseresource planning system. The authors concluded that the introduction of CDinto the development process improves the quality of the system’s usability, andhelps ease the contextual change to the newly developed system compared to ifit had been developed with less insight into the end-users’ work context. Thisrelates to the project case described in this thesis in that it also introduces anew system for retrieving information regarding a company and its employees.
In the main Rapid CD literature, the two primary parameters considered whenchoosing between the three di↵erent forms of the process are time and scope [1].This leaves opportunities for investigating potential other parameters that couldbe of importance when making this decision, as well as adapting the process totake these parameters into consideration.
One of the co-creators of CD, Hugh Beyer, has presented ways to combine theCD process with agile development methods [19]. This literature covers howto adapt Scrum and XP workflows to incorporate CD, but the author does notconsider the value, if any, of also adapting the CD process to agile developmentmethods.
teams in general, stating that smaller teams show higher e�ciency and lower costs. Moreinformation is currently available at http://www.qsm.com/risk_02.html.
8
3 General method
3.1 Approach to research questions
The research questions posed in section 1.2 were examined through an explo-rative case study where a version of CD was applied to a modern smartphonedesign and development project, directed by a team of two members, from startto finish. A case study is the preferred strategy when the focus of the researchquestions are formulated as ”how” or ”why” [20, p. 9]. The choice to performa case study was further motivated by the notion that this type of method issuitable ”when the focus is on a contemporary phenomenon within some real-lifecontext” [20, p. 13].
The case, which is described in full in section 4, required the construction of apilot app. It was also reasoned that an implementation would help the visionstay alive, and prompt the client to continue implementing it. While CD wouldbe well suited for dealing with the design phase of the project, the team wouldneed to carry out development in order to fully follow up on the case. Thedevelopment phase of the case would be performed according to a combinedversion of agile development methods, which would build upon the CD resultsaccording to the transition procedures discussed by Holtzblatt et al. [1] andBeyer [19].
3.2 Data gathering through process application
During the case study each step of the CD process was evaluated, and noteswere taken on which parts worked well and which parts did not. This was donein order to evaluate the applicability of CD to smartphone development projectsin 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 andtogether encompassing the entire design and development progression from ideato realized working concept app.
The study was designed to produce qualitative results, based on explorativedata derived from the user-centered method adaptation. The goal was to studythe CD method in light of current industry technology and procedures, morespecifically that of agile smartphone app development, and see whether adjust-ments can be made to help small teams steer clear of potentially avoidable stepswhile still gaining insight for design.
3.3 Case study structure
The case study approach is detailed in sections 4 through 6. The results of thestudy are presented in section 7 and analyzed in section 8. In section 9 theconclusions on how CD can be adapted to better suit projects similar to theproject case are discussed further.
9
10
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 undergonerapid growth, and has expanded to o�ces in Oslo, Helsinki, London and Munich.
At time of writing the company has over 500 employed consultants working at avariety of customers’ o�ces, mainly in the Stockholm region. Since the numberof new hires per year has increased consistently, the company’s management hasbeen looking to develop tools that would make it easier to contact employees,and also make consultants’ skills more accessible to co-workers. This wouldmake it easier to find assistance on a peer-to-peer basis and facilitate puttingtogether teams for new projects.
4.2 Objective
The objective as presented by the Netlight management was the following: takeinternal communication to the next level using smartphone technology.
This has been a vague objective, and in order to reach a solution it was firstnecessary to identify and investigate how employees communicate, as well aswhat di�culties were experienced in workplace routines. Using CD to conducta design pre-study to elicit requirements was well motivated in this case, sincethe aim was vaguely specified and the client was seemingly unaware of theconcrete company needs. Examining these factor were necessary in order toproduce a concept of an improved future workplace.
The goal of this project was to deliver a working pilot product as a proof ofconcept of the design produced through the use of CD. The pilot product didnot need to be fully implemented, but should convey the functionality of theapp.
It is worth mentioning that while there exists commercial o↵-the-shelf servicesthat would satisfy some of the requirements found during the case study theclient had already opted for a custom solution, exploring the possibilities of anin-house mobile app.
4.3 Communication and organizational structure
Netlight has its employees organized in a network structure. This is a modernform of organizational structure that is based on social network theory, andregarded as more flat [21] than classical hierarchical structures, in that it is moredecentralized and flexible, allowing direct peer-to-peer communication betweenemployees from di↵erent parts of the company.
11
Netlight is divided into four departments: Operations (Accounting, IT, FirstImpression, HR), Management, Sales (Engagement Search (ES), Talent Search(TS)) and Consultants. Members of all departments communicate freely witheach other.
There currently exist a number of options for peer-to-peer communication withinthe company. In addition to email and telephone contact information availableon Rebel, the company information wiki, there is an extensive social chat sys-tem, Yammer2. 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 forproductive teams. Aside from Yammer, most internal communication is donethrough Skype3.
4.4 Competence cells and knowledge sharing
Developing talent and expertise among its employees is one of Netlight’s highestpriorities. Thus, tools have been created to promote knowledge sharing. Thisagenda is manifested in the form of CCells and EDGE. The former are groupinitiatives driven by employees themselves who want to either learn about aspecific subject, or teach others about it. Many of these CCells are focused ontechnology or business, but there are also CCells for casual hobbies and sparetime interests. The organizers of CCells have resources supplied by the companyat their disposal for holding seminars, talks or lectures.
EDGE is an initiative that summarizes the ways in which Netlight employ-ees maintain, develop and share current valuable knowledge and competences.There are EDGE seminars that educate interested employees and new recruitsabout new technologies and development techniques, as well as EDGE Academywhich is held on evenings during one week of each year and may include speciallyinvited guests.
Knowledge sharing and talent growth are deemed important to the continuedsuccess of the company, and so creating an information technology basis forthem has been an underlying focus of this project.
4.5 Company growth and expansion
While currently having a physical presence in Stockholm, Oslo, Helsinki, Londonand Munich, expansion to multiple new countries is being planned as branchorganizations throughout northern and western Europe. This means that any
2Yammer, Inc. is a freemium enterprise social networking service that was launched in2008 and sold to Microsoft in 2012.
3Skype is a freemium voice-over-IP service and instant messaging client, currently devel-oped by the Microsoft Skype Division.
12
application being developed must ensure scalability and maintainability so thatit can grow with the company. Because of this there are also challenges regardinginternationalization.
4.6 Previous work
A year prior to the start of this project, an attempt was made to produce asolution to the problems described in section 4.1. The result of that projectwas an iOS app called Koala, where the user could search for and view infor-mation about employees and customers. Information about the location of anemployee had to be provided by that employee themself, through a check-infeature which required that they were present at the location at the time ofaction. The app could also access information about which project a given con-sultant was attached to. The customer information consisted of company nameand country. Koala had its own back-end, where information about employeesand projects was retrieved from Netlight’s enterprise research planning (ERP)system and then cached. The back-end was taken down at some point in timeafter the departure of the developer, which caused the app to no longer functionas intended. Koala is no longer maintained.
In 2013, the CCell for mobile platforms collectively developed an iOS app calledOne Netlight, where the user could browse Netlight employees by name and seetheir photo and telephone number. One Netlight got its data by scraping theemployee directory wiki page. When some part of a page changed in layouthowever, bugs got introduced which made the app practically unusable. Thesebugs were never fixed.
Another tool created in 2013 was Net-CA, a responsive web interface created forboth desktop and mobile browsers, that allows the sales department to quicklyfind available consultants. The employees can be filtered and sorted accordingto skills, experience and earliest available date. Contacting the consultantsin question cannot be done through this interface. Net-CA is developed andmaintained internally. The sales department enters information about eachconsultant into the application’s back-end database (which also gathers datafrom the ERP system), so the consultants themselves typically do not interactwith the system directly.
13
14
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 betweenFebruary 10 and March 21 2014, with the intent of mapping the requirementsof a communications app that would assist the employees and management ofthe client both currently and for the foreseeable future. The application of CD tothis project was mainly motivated by its compatibility with the characteristicsdescribed in the 2004 publication Interactive Technologies: Rapid ContextualDesign: A How-to Guide to Key Techniques for User-Centered Design by KarenHoltzblatt, Jessamyn Burns Wendell and Shelly Wood [1]. Many fundamentalprerequisites for conducting a CD study were deemed compliant with the natureof the project—such as having a core team of two people, preferably a designerand a developer (formally taken on by Ekman and Martinsson respectively).However, Holtzblatt et al. recommend that the third role (in this case theworkplace practice professional) be included to some degree. The duties of thethird role were shared by several available stakeholders—mainly the two projectsupervisors, 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 byHoltzblatt et al. in their publications of the Rapid CD method [1]. In contrastto the other versions suggested (Lightning Fast and Lightning Fast +) it has notbeen stripped of any steps in the design process, but instead usually requiresconsiderably longer execution time. It was reasoned that a thorough use ofthe method in its entirety would give the project results a strongly motivatedfoundation that would add the most value to all parties involved. In this chapterthe 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 parameterswere picked to allow for a lightweight execution in as short a timespan as possi-ble. This was due to the influence of two factors: the sparse number of helpersavailable at the client’s headquarters, which limits the number of possible inter-viewees and consequently the interpretation of that data; and the time requiredto 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, whichserves 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. Inthis context, “interview” does not mean eliciting answers to a set of writtenquestions during normal dialogue. The idea is instead to watch the end-user
15
carry out their daily work routine, and to make notes of how they solve problemsor tasks. The interviewer will occasionally interpose questions to clarify certainactions or to ask the interviewee how they are reasoning. In some regards thisis more similar to a set of job shadowing procedures than interviews.
Finding the right interviewees require analysis of the system context. The num-ber of interviewees that can be accommodated depends on the type of functionthe 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 donecarefully so that the results from the survey will fairly a↵ect the direction ofdesign. Thus it is also important to remember to look for relevant di↵erencesand likenesses between candidate interviewees when sampling the end-users.
If the interviewer notices that it is unlikely the interviewee will run into situ-ations that would provide data relevant to the FRCD process, the interviewerhas the ability to collect retrospective accounts of previous activities. These ac-tivities should not be more than two weeks old. When collecting a retrospectiveaccount, the interviewer asks the interviewee to walk the interviewer throughthe event by repeating the actions as they were done the first time. If the inter-view has to take place outside of the actual work place, e.g., for confidentialityissues, the interviewer will have to rely on retrospective accounts.
It is preferable for the interviewer to take notes on paper, both to be able tofollow the interviewee around should it be necessary and to not seem excludingby 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 forinterpretation sessions. Interpretation of CI data should happen within 48 hoursof completing the interview, to make sure that it is still fresh in memory. Presentat this session are the FRCD team members and any possible helpers.
There are several roles in an interpretation session. The interviewer reads theirnotes from the CI interview and the note taker constructs notes based on theinput from all team members. Additionally there can be any number of generalteam members present, one of which can also be responsible for creating workmodels (explained in section 5.1.4). If the team is bigger than the standardof two members, there can also arise a need for a moderator. This person isresponsible for keeping the interpretation discussion on track.
The first step of the session is to create user and organization profiles. Eachinterviewee is represented by a code instead of their name, to keep their identityconfidential. The profiles describe characteristics of the users and organizations;such as age, years of experience and size of the organization. The intervieweruses the profiles to introduce the organization and user to the interpretationteam. After capturing the profiles, the interviewer presents either a photographor a drawing of the physical workplace the interview was conducted at, to helpthe participants contextualize the interview information.
16
When walking the rest of the team through the interview, the interviewer goesthrough their unabridged notes and recollections. The session participants in-terrupt and ask questions to elicit deeper insights from the rest of the team. Ifany of the participants notice any information they think constitutes a key ideafor the interview, they call for it to be captured. The note taker writes all ofthese key ideas down. In FRCD, these are known as a�nity notes.
Relevant things to capture are interpretations of problems, events and oppor-tunities in the workplace. If any of the session participants have design ideasor further questions for the interviewee these are also written down. They arehowever not discussed at this session, since the design comes at a later stagein the process and questions should be directed at the person who can answerthem. If the interviewee has said anything during the interview that can beused later as a quote to highlight a certain issue, this is also captured. Whilethe interviewer is going through their material, one of the participants capturesthe 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 tostakeholders and other interested parties.
5.1.4 Work modeling
Work models provide di↵erent views on the structure of how end-users conducttheir work, and are drawn during the interpretation session. Two of the standardCD work models, the cultural and flow models, are not a part of the rapid variantof 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 observedevent or a retrospective account from a Contextual Inquiry interview. Togetherwith the actual steps themselves, triggers are captured to show what situationmade 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 theuser experiences an unexpected problem, this is marked as a breakdown. Thesequence models are consolidated, as described in section 5.1.6, to show commonpatterns between di↵erent users.
The physical model is a depiction of the physical environment, including theobjects in it, where the user does their work. It can show how the workspace isused 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 isstructured, how and when the it is used and with what intents.
When the work models are completed, some aspects of them can be used towrite additional a�nity notes. Breakdowns and intents are captured for allmodels, together with issues specific for the di↵erent models.
17
5.1.5 Building the a�nity diagram
The a�nity diagram represents a first unified view of the major issues thatneed to be addressed in the resulting design. The diagram is built from thea�nity notes written during the interpretation sessions. Where each contextualinterview highlights the key issues and work structure of an individual, the finala�nity diagram is a tree structure that can be used to gain higher-level insightsand show the hierarchical relation of these. In preparation for this step of theFRCD process, all a�nity notes need to be put on pieces of paper that can beput on a board.
Constructing the diagram starts with getting all the a�nity notes up on theboard. Notes relating to a common observation are put in a column together. Ifa column gets too big, meaning it has more than around six notes, it generallyshows that there are other distinctions in it that can be broken out into itsown column. When all notes are either in a column or discarded for not fittinginto one, the columns are combined into higher-level observations. The resultinggroups are then divided into top-level ideas that complete the tree-like structureof the finished diagram. All note groups have a description written in the voiceof the end-user, to make the FRCD team consider the observations from theusers’ point of view.
Figure 1: Structure of an a�nity diagram.
A column represents a key work distinction that will be relevant when design-ing the prototype. A group of columns represents a theme common betweencolumns, and the top-level groups describe a part of the big picture, e.g., ma-jor steps of a process or a communication strategy. If the FRCD team is ableto enlist helpers to assist in building the a�nity diagram, the time needed tocomplete it can be shortened substantially; especially the first phase since it iscloser to being linear in nature than later phases.
5.1.6 Consolidating models
FRCD involves capturing three work models, but only the sequence model isconsolidated. The physical and artifact models are kept as auxiliary resources.The Lightning Fast and Lightning Fast + versions of CD do not include modelconsolidation.
18
Sequence consolidation includes looking at tasks from di↵erent people whereall have di↵ering triggers, intents, steps and breakdowns. The idea is to showabstract underlying steps common between people doing di↵erent tasks withdi↵erent intents and experiencing varying breakdowns, and can therefore beused 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, orsupporting the task in a new system. Sequence consolidation is preferably donein groups of two, but the first consolidation should be done with the whole groupto establish a common understanding of how the process is going to work.
The first part in consolidating the sequences consists of choosing the three thatare most central to the work, while also being detailed enough and havingoverlapping steps. Then the triggers for each sequence are identified. Sequencesare comprised of a number of steps, and sets of steps that can combined into ahigher-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. Aconsolidated 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 a�nity notes and interview material gathered previ-ously during the investigation. This part of the CD process is only included inFRCD. A persona does not describe a single person interviewed, but rather acombination of attributes from all users in common job roles and with commonneeds. Personas have a one-page description that summarizes who they areand what they do. The description includes goals, tasks and roles. Goals arehigh-level accomplishments that the persona tries to achieve, or tries to sustainover a period of time. Tasks are discrete pieces of work that can be attributedto the persona. Roles described in the text are the di↵erent responsibilities thepersona has in their daily work.
Personas provide the core team and stakeholders with more context, whichis useful when considering the design. With more tangible knowledge aboutthe users the FRCD project is going to support, the more informed decisionsmembers and stakeholders of the FRCD team can make.
5.1.8 Walking the a�nity model and consolidating sequences
When the a�nity model is finished and sequence models have been consolidated,the team proceeds to walk the models together with stakeholders, sometimesreferred to as the wall walk. FRCD suggests that the team should have adedicated room where they can have keep all relevant progress visible on the
19
walls for all who are interested in following it. Walking in this context meansto 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, holesand questions. Participants may come up with not only features they see theproject being able to provide; but also strategies, concepts and implementationpossibilities. These are collectively referred to as design ideas. Instances wherethe a�nity 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 exposeexpectations that were not necessarily accurate at the outset. Questions are re-lated to holes but di↵er from them in that they raise concerns about informationthat 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 andchallenges outlined by the previous steps, a visioning session should be held.These meetings are supposed to generate a conceptual vision of what the futureworkplace or context of use will be like when the project has been completed,not necessarily restricted by any of the technological constraints that may applyduring actual implementation. The sessions are done in groups of no more thanten, but should include as many of the stakeholders as possible. If developmentis agile, then it will most likely benefit from a common vision shared by bothdevelopers and owners.
The visions themselves consist of large hand drawn pictures that depict thefuture, as altered by the project result, from the perspective of the intendedend-user. The visions are high-level, without much implementation or userinterface (UI) details. However they should not be vague, and ought to producea set of usable user stories based on the tasks in the sequence models. Ideallythe meeting will produce several visions which can then be compared, analyzedand consolidated into a single, finished vision that comply with most of therequirements 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 designthrough prototyping. First the storyboards and visions are walked in orderto reiterate the functionality the design should support. Then brainstormingand hand drawing of UI elements start, producing a multitude of approachesand angles to addressing the features. These hand drawn prototype UIs arepreferably made on paper in the interest of time, as each new design is likely tobe reworked very soon. Fast and informal evaluations of the early prototypesare made, scrapping the unfavorable versions and keeping promising UI layoutsand metaphors.
20
Construction of wireframe UI models begin once the paper prototypes resemblethe finished product. These wireframes are often not hand drawn, but are stillprinted and cut out on paper and are intended for formal user testing withmanually interactive elements. Paper prototype interviews are then held whererepresentative usability testers are given tasks to accomplish in the new UI.These interviews may di↵er, depending on whether the project is a refinementof an existing system with experienced users or a completely novel invention.The point of the interview is to identify poor usability or ine↵ective designmetaphors so that the UI can be iterated and improved before development.
Once the prototype wireframe UI has been iterated enough times to produce areliable and promising interface that can support all the wanted features fromthe storyboards, a final requirements specification for implementation may bewritten and reviewed by the project owner.
5.2 User-centered agile development
While CD lays the foundation for a user-centered development project by con-ducting a thorough pre-study, or Phase 0 [19], the implementation of this user-centered system should also adhere to a predefined method or process in order toensure the correct realization of the project vision. In relatively short projects,such smartphone app development projects of a scope similar to ours, it has be-come increasingly popular to utilize agile development methods metods such asScrum and XP—especially in user-centered software projects where the end-usershould be very much involved.
5.3 Software setup and revision control
Since the targeted platform was iOS 7, the main programming integrated de-velopment environment (IDE) for the development phase was Xcode4.
All source code were to be managed with Git5 on the company’s private GitHub6
profile. Locally the versioning was controlled with SourceTree7 in conjunctionwith the built-in capabilities of Xcode.
In order to be able to access the client’s ERP systems any device running orsimulating the application would have to be connected to the company virtualprivate network (VPN). For this the application Tunnelblick8 was used.
4Xcode is an IDE created by Apple Inc. used for any and all native development for Apple’soperating systems: iOS and OS X.
5Git is distributed revision control tool and software distribution management systeminitially designed by Linus Torvalds of Linux fame.
6GitHub is a Git-oriented online service and portal for source code management anddistribution, often used by—but not limited to—open source projects. It is available onhttp://www.github.com
7SourceTree is a native Git and Mercurial client, developed and distributed by Atlassian.8Tunnelblick is a free, open source GUI client for OpenVPN on OS X.
21
22
6 Design and development results
6.1 Carrying out the CD study
6.1.1 Conducting CI interviews
Based on the suggestions by Holtzblatt et al. in their work, four work groups(three consisting of two interviewees each, and one consisting of four) wereinterviewed at the client’s Stockholm o�ces. These ten interviewees wouldthrough their work habits and job roles provide insight into the company’scommunication structure — what communication and knowledge sharing toolsare used, and how they are used by the employees. Conducting two CI interviewssimultaneously were done in the interest of time, since two FRCD team memberswere available.
The work groups to interview were: External Consultants, who are workingo↵-site; Internal Consultants, currently posted on in-house projects; Sales Rep-resentatives, both Talent Search (TS — recruiting) and Engagement Search(ES — project sales); and Operations, who are further divided into human re-sources, Accounting, First Impression and Internal IT. The groups were dividedas follows: Consultants, two external and two internal (two of them senior andtwo of them junior); Sales, both TS and ES as before; Operations 1, consistingof one employee from FI, and one from HR; and Operations 2, with one fromAccounting and one from Internal IT. See table 2 for a summary.
Consultants Sales Operations 1 Operations 2CI 1 External x2 ES HR AccountingCI 2 Internal x2 TS FI Internal IT
Table 2: CI interview coverage and structure.
In order to compensate for the lack of insight into the working habits com-munication of o↵-site consultants the CIs would be supplemented with regularinterviews with a sample of these, but after working hours.
Interviews with Operations 1 and 2 were carried out first. This was in part due tohigher availability, but they were also chosen first to avoid making any beginnermistakes on the valuable consultant as an interviewer. This was followed by theinterviews with sales, and then the consultants — which were harder to schedulemeetings with. As the two intended interviews could only be performed on-site, two supplementary interviews with experience consultants were scheduledat a customer’s o�ces in Stockholm. Another supplementary interview wasconducted with a recently hired external consultant who had never been postedat Netlight headquarters, as they had been assigned an o↵-site project on thefirst day of employment. The purpose of these supplementary interviews was toacquire insight into the working conditions of employees that are geographicallysecluded from company headquarters, and in what ways their experiences di↵erfrom consultants on internal projects.
23
The interviews were held at the desks of the interviewees during normal workconditions. Generally they were conducted before lunch, starting around 10 AMand lasted between 90 and 120 minutes. The interviewer sat next to the inter-viewee and took notes of the habits and work performed, asking questions aboutthe use of tools and software, communication norms and personal preferencesregarding communication and use of available applications. All the while theinterviewees were encouraged to show their process instead of simply retelling it,as is promoted by the FRCD principles. When the interviews were nearing theirends the interviewer began the wrap-up process, which constitutes quickly goingthrough the notes and summarizing the interview to ensure a correct and faircomprehension of the interviewee’s job role responsibilities and their execution.When possible the interviews were audio recorded to prevent loss of data.
6.1.2 Interpreting and consolidating inquiry results
After each interview was ended they were interpreted as soon as possible in asecluded room. These sessions were held without the use of helpers, becauseof practical reasons – there was simply not enough time to adapt the sessionsto the schedules of other stakeholders, who also had limited insight into andunderstanding of the methods used. This case, where only two active projectmembers were present, also meant that not all of the recommended roles to bepresent were necessary. Instead, the interviewer examined their notes from theinterview, and systematically retold the observations that had been made. Thus,the interpretation sessions resulted in a list of a�nity notes for each interviewaccompanied by artifact notes, insights, design ideas and observed or retoldsequences (which are further labeled as triggers, intents and breakdowns).
Per FRCD protocol, certain sequences should be noted from each interview thatdetail the end-user’s interaction with the system being evaluated. However,since this project’s focus was not improving an existing tool per se, many ofthe sequences observed were peripheral and probably had very little influenceon the needs that could be satisfied by a smartphone app. For example, manysequences detailed regular job role duties, such as answering email from internalsta↵, co-workers or external parties. While some email correspondence withinternal sta↵ could be relevant to the context of designing the app, the usabilityof an email client is far beyond the scope of this project. This lead to a moregeneral level of inspection during the interviews, as the interviewer was tryingto discern the overall communication paths and tools that together make up theinternal information infrastructure of the client, while still capturing low leveldetails such as specific use cases of existing tools, frustrating work activities andpersonal preferences regarding communication and services available.
6.1.3 Building the a�nity model and diagram
Prior to constructing the a�nity diagram the entire set of a�nity notes gatheredfrom the interpretation sessions were checked for relevance to the scope of theproject. Notes that covered problems, observations and insights strictly outside
24
of the project scope were discarded, and all other observations were writtendown on sticky notes according to recommendations from Holtzblatt et al.
The paper notes were then organized into smaller categories based on the typeof requirement the observations related to most strongly. When categories grewtoo large and inclusive they were taken apart and divided further into moreexplicitly detailed ones. When the groups had reached su�cient sizes betweenthree to ten a�nity notes each the relations between categories were examined,which led to another hierarchical level of a�nity. A third and final categorizationwas made which resulted in three main groups of observational data. Thesewere: Networking and overview, Employee profiles and Knowledge sharing. Allother category notes were written in the form of a statement made from theperspective of the end-user, both on first and second levels, such as “As a userI want to be able to do X”. One of the top-level groups is described below infigure 2.
Knowledge sharing
I feel likeparticipating in
CCells is important forcultivating my skills.
I want betterinsight into whatCCells do and
how to join them.
I want to stayupdated on thediscussions in
the CCells I follow.
Knowledge-sharing iscentral to problem solving
and personal growth.
I want to sharemy knowledge.
I want to beable to find
someone with acertain skill set.
Figure 2: Example of the tree of a top-level categorization of a�nity notes.
The result was a hierarchical tree with three main branches: Networking andoverview, Employee Profiles and Knowledge sharing. These three correspond tothe chief areas of concern within the project’s universe of discourse [22]. Theemployee profiles branch dealt with the need for end-users to be able to look upcontact information of co-workers in various scenarios, the knowledge sharingbranch contained all notes related to CCells and other knowledge-sharing activ-ities, and the networking branch held all observations related to a big pictureapproach to making contact with parts of the company.
When the entire a�nity diagram was finished the structure was recorded, writ-ten down and later remodeled in digital form for easy access and review. Beforemoving on to visioning and storyboarding though, the a�nity and interviewdata was draw upon to build personas. Three distinct personas were decidedupon: a mid-level o↵-site consultant with two years of experience, and a strongpresence on Yammer and in the competence cells; a slightly more junior salesagent with previous business experience and varying degrees of participation indi↵erent social and professional groups and cells; and an operations employeewho prefers using team communication tools like Skype as opposed to Yammerwhich he felt was more directed toward the consultants. The personas consisted
25
of one page of composite descriptive material each, supplemented by a stockphotograph conveying a fitting personality.
6.1.4 Visioning seminars and storyboarding
A visioning session was held together with stakeholders and end-users at theclient’s o�ces in order to build the vision based on the a�nity diagram. Thethree main branches of the a�nity diagram were one by one presented anddiscussed. Three visions were created on whiteboard, each somewhat interactingwith the others, that detailed how future users would be able to interact inthe context of the workplace. The session led to omission of some plannedfeatures (e.g., reminders of seminars), and inclusion of new ideas into the finalconsolidated vision.
Some improvisation with respect to the session structure had to be made thatdeviated from the formula suggested by Holtzblatt et al. The main problemwas that most stakeholders from the client were busy on the date of the session,so the seminar was instead held with auxiliary stakeholders and end-users thatwere interested in the project. A rather large group of people attended theseminar, so a single presentation was held in lieu of a proper wall walk.
6.1.5 Formulating system requirements and data dependencies
When forming the vision of the future workspace many dialogues were heldwith internal IT and consultants working on other internal projects, as well asproduct owners of the various back-end systems at the company. It turned outthat most of the data that the vision called for would be available from oneor more of the database systems or their middleware interfaces, but there wassome concern regarding a number of the intended features.
The most troubling features from a back-end standpoint were those related tobrowsing, viewing and joining CCells. This was simply because there was at thistime no centralized portal for CCells. Di↵erent services, such as Rebel and Yam-mer, were used to view CCells. The information available from these resourcesis however not always up to date. E.g., there are no common conventions forhow CCell leaders inform the members of upcoming meetings. This informationcan be spread either through the email list, through Exchange calendar invitesto all members or by posting on Yammer. This means that someone trying toview when the next upcoming meeting is will perhaps not be able to find thisinformation without asking a member of the cell. Similar to the above not allcompetence cells keep their information on Rebel updated, resulting in a lack ofinsight into the activity of the cell and outdated information potentially seem-ing current. The lack of reliable sources of information in this area lead to theexclusion of competence cell functionality from the prototype.
Other data that is hard to obtain is the work location of o↵-site consultants anda summary of skills and expertise for all employees. The only customer locations
26
currently stored in the clients’s systems are their billing addresses, which are notnecessarily the same as the address of the place where the consultant is stationed.For the prototype, customer locations were randomized within Stockholm citylimits. The addresses for Netlight o�ces were available however, which meantsome employees’ locations could be shown correctly.
Skills and expertise are only available from consultant resumes, which are Mi-crosoft Word documents. As such there is no database where one can get rele-vant information about a specific employee’s skills and expertise. The resumesare also not standardized enough to allow for reliable scraping. This data wouldbe available by soliciting it from the users, and from LinkedIn should the useraccept it.
6.1.6 Choosing online wireframing over paper prototyping
The standard way of designing user interfaces (UIs) in FRCD is by using paperprototypes first, and then continue on to more detailed wireframes and mock-ups. In this project, the first step was skipped and instead Flinto9, an onlineprototyping tool for smartphone apps was used. That way focus could be onmore high-level design cues in favor of low fidelity structure and navigation lay-out (which was deemed suitable for standard industry design patterns). Theliterature discourages this and suggests that starting prototyping on paper ispreferable [1]. The authors’ arguments for this are grounded in experiences withprojects that are di↵erent to an extent that warrants revisiting the motivationsbehind the discouragement.
A more detailed motivation for the decisions made against paper prototyping,and its e↵ects on the project results, can be found in section 8.5.
6.1.7 Designing prototypes
Based on the arguments in the previous section (and further in section 8.5),the paper prototype stage was skipped and instead the wireframing stage wasstarted directly. With the requirements for the prototype in place, the UI designwas started. To begin, the storyboards were walked to identify what UI com-ponents were needed in the resulting system. Ideas for these components werebrainstormed using a whiteboard, on which all parts of the UI were connected.With the user experience (UX) flow of the system written down, wireframeblueprints of the UI could be created.
The wireframes were created as mockup images, with screen dimensions and UIelements corresponding to iOS heuristic standards [23]. In order to reinforcethe fact that this prototype was not an actual finished design – let alone actualimplementation of the system – it was given a blue color scheme that did notadhere to the company branding guidelines. The prototype was created as a
9Flinto is a web-based tool for smartphone UI prototyping developed and owned by NathanManousos and Kazuho Okui, available at http://www.flinto.com
27
full coverage of the product vision. The thought here was that in the event ofan unfinished implementation of the app, that would probably entail focusingon a single group of features in depth, there would be a complete and tangiblemodel of what was left to build.
The wireframes were created in Adobe R� Photoshop R�10 and assembled in Flintoone view at a time. Most UI elements could be made according to conventionaldesign norms and rules, but a few of them had to be iterated and informallytested by users. The presence of the Flinto prototype on a real physical andinteractive device made it easy to show the envisioned system for other stake-holders and users. Some testers were even fooled by the realism of the prototype,despite the false coloring and rudimentary design. The reasoning for this wasthat it could possibly be confusing for less technologically knowledgeable clients,and may cause misunderstanding. This problem is discussed in section 8.5.3.
An Android version was derived from these wireframes later, with some device-specific changes to the UI in compliance with common Android user interface(UI) metaphors. This was done mainly as part of the concept deliverable in-tended for the client, and completed after the iOS prototype since the imple-mentation of a native Android app was not in the project’s scope.
6.1.8 Performing prototype interviews
The process of evaluating and testing prototypes described in FRCD provedtoo impractical to fully apply to the modern version of the prototypes designed.First of all the prototypes had not actually been constructed from paper, mo-tivated by the reasoning disclosed in section 6.1.6, section 6.1.7 (and furtherdiscussed in section 8.5.1), which obviously demanded alterations to the recom-mended procedures.
The most drastic changes were in preparation and setup. Using an actual mo-bile device for testing instead of loose paper models spread out on a table orsurface was of course easier to manage, while making a more serious and realisticimpression on the user. Since the users were able to handle the prototype like areal app – with exception to some interaction techniques like swiping and pinch-ing – the experience was made more realistic, and natural interaction with thesystem could be observed from an end-user’s perspective. However, the speed ofinteraction was an unanticipated increased which made it harder to take notesof the users’ actions. Interrupting the interaction test was also inadvisable tosome extent, as the users’ true actions and reactions were desired.
Another aspect of the interviews that changed was time consumption, whichwas often reduced to less than ten minutes for a complete walkthrough of theapp and its functions. This stood in stark contrast to the two hours of testingrecommended in FRCD, which for all intents and purposes seemed unnecessaryin this instance. However, the allotted time was enough to elicit exhaustiveinteractions and comments in all interviews.
10Adobe R� Photoshop R� is a graphics editing desktop application developed and distributedby Adobe Systems.
28
6.2 Concluding design and preparing for development
6.2.1 Features designed during the FRCD study
A full description of features and designs conceived during the design phasecan be found in section 6.3.1. However, as a means of motivating the strategicdecisions made in this section, the main feature groups that were designed fromthe three branches of the a�nity model (Employee profiles, Knowledge sharingand Networking and overview) will be briefly outlined. These feature groupsare presented in table 3 on page 30.
6.2.2 Writing user stories and concept specification
User stories were composed in the form of single-sentence descriptions of a taskbeing executed, in accordance to the recommendations by Beyer [19, p. 41].They were all written from the perspective of the end-user, beginning with thephrase ”as a user. . . ”. They were written on such a detail level that they eachconveyed the need for a distinct and delimited application feature. The storieswere collected and organized in Trello11. In total 40 user stories were derivedfrom the vision. The collection of user stories was handled as a backlog offeatures in preparation for the agile implementation phase.
Once the FRCD design phase had been concluded, its collective material wasreviewed to ensure consistency and then compiled together with descriptionsand instructions into a final concept specification document. This documentwas then handed over to several departments and CCells at the client duringpreparations for the development phase. The motivation here was twofold: firstit was meant as an opportunity for feedback and discussion with the client, tocheck if the vision and design had succeeded in correctly addressing the client’sneeds; and also it was meant to engage influential persons in its realization, pro-longing the product’s expected lifecycle and encourage continued development.Excerpts and themes from this document can be found in section 6.3.1.
6.2.3 Adopting an agile development process
A number of problematic factors came into play when planning the develop-ment phase. For one, the team consisted of only two full-time programmers(occasionally joined by the two supervisors when solving back-end problems),and only a few other persons could be considered actively involved stakehold-ers. These other stakeholders were only peripherally engaged in the project,and mainly interacted with it through weekly reports. This limited the possibleuse of the classical roles traditionally employed in agile development methods.Another limiting factor was time remaining, which meant that only short sprintsor iterations could be used.
11Trello is a web-based project management application developed by Frog Creek Software,available at: http://www.trello.com.
29
Feature Description
1.0 Search1.1 Searching Allows the user to search among employees and
projects using names and skills.1.2 Employee profiles Detail view displaying information pertaining to a
specific employee.1.3 Project profiles Detail view displaying information pertaining to a
specific project.1.4 Contact info Telephone number and email address enabling.
calling, texting and sending emails to an employee.1.5 Add to favorites A bookmarking feature that creates a shortcut
to a specific employee.2.0 Favorites2.1 View and Control Lists mentor, team members and favorites.2.2 Model The data structure representation of a
bookmarked employee.3.0 Events3.1 Browsing events Lists active events to which the user is invited.3.2 Creating events Creates an event with description, location,
time and invited users.3.3 Manage responses Enables responding to invitations.4.0 Overview4.1 Current location Shows the user’s current location on the map.4.2 Display o�ces Shows all the client’s o�ces on the map.4.3 Display customers Shows all the customers’ locations on the map.4.4 Display projects Same locations as the customers but with added
UI elements.4.5 Display employees Same locations as those above, but with added
UI elements.5.0 CCells5.1 Browsing CCells Lists the all the CCells5.2 Detailed info Detail view displaying information pertaining
to a specific employee.5.3 Joining CCells Allows the user to easily apply for a CCell
membership.6.0 Settings6.1 Download data Updates all local data from the back-end server.6.2 Universal contact Adds a universal native contact containing
all employees’ phone numbers.6.3 Lunch roulette Automatically matches employees for suggested
lunch meeting opportunities.6.4 LinkedIn sync. Makes more detailed user data, such as skills,
available for use throughout the app.6.5 About view Text view that describes the project and links
to the Flinto prototypes.
Table 3: Suggested application features, grouped by the six navigation itemsdesigned for the main menu.
30
As such decision the decision was made to not strictly adhere to one formalmethod, such as Scrum or XP. Instead central themes from both methods wereborrowed while other themes that were not considered as appropriate were omit-ted. Development would be done in Scrum-like sprints where work would bebased on a backlog of user stories. Neither the Scrum Master role from Scrumor the Product Owner role from Scrum or XP would be formally used, insteadthe responsibilities of these roles would be shared between team members.
Much of the programming was done using the pair programming practice com-monly seen in XP as this was the most natural work form for the team members.The concept of having an experienced end-user on the team as in XP was touchedupon by keeping the supervisors informed of prioritizations and demonstratingnew app functionality as soon as possible. Input from the supervisors helpedwith prioritizing user stories, as they could help give a better understanding ofthe amount of work needed to complete certain user stories from a back-endperspective.
Since the time frame of the project was relatively short, there was no opportunityto incorporate the use of XP’s velocity or Scrum’s burndown rate to predict thework capacity for each iteration.
In the last iteration, the XP idea of a programmer’s holiday was utilized toensure product stability and that the project would be prepared to hand overto the client at the end of this project.
6.2.4 Release planning and iteration schedule
Not all features designed during the FRCD design phase could be implementedduring the development phase. This was plain to see, due to the limited time(six weeks) allotted for implementation, and also because some back-end re-quirements could not be reconciled with the data available from the client’sERP systems. Therefore priorities had to be made when choosing which fea-tures would be implemented.
Of the six feature groups from the design (Search, Favorites, Events, Overview,CCells and Settings) some direct analytical observations could be made. Firstly,the back-end system for managing CCells would soon be rebuilt. Therefore theprospect of focusing attention to that feature was judged too risky, in the interestof time. Secondly, while implementing the event feature seemed promising,it was noted that it required some level of critical mass in terms of end-useradoption in order to function as intended. This was simply not possible sincethe app would only be implemented for iOS.
Focusing on this particular group of features was too much of a gamble, sincethe aim was to leave behind a product that had functional value for the client,and thus more safely ensure its continued development. Both these two fea-ture groups also heavily depended on employee profiles being implemented, asillustrated in table 4.
31
In addition to this the geographical Overview feature was a liability, due tolocation data not being available for customers or projects. This feature alsodepended heavily on projects and employee profiles already being implementedin the app (see table 4).
Feature Feature Data Commentdependencies availability
1.0 Search1.1 Employee profiles – Partially Skills missing1.2 Project profiles 1.1 Partially Address missing1.3 Contact info 1.1 Available1.4 Add to favorites 1.1, 2.2 Local2.0 Favorites2.1 View and Control 1.1, 1.2, 1.4 Available Mentors, teams2.2 Model – Not available3.0 Events3.1 Browsing events 1.1, 3.2, 3.3 From scratch3.2 Creating events 1.1, 1.4, 2.2, 3.1, 3.3 From scratch3.3 Manage responses 3.1, 3.2, 3.1, 3.2 From scratch Critical mass4.0 Overview4.1 Current location – Available4.2 Display o�ces – Available4.3 Display customers 1.2 Not available Address missing4.4 Display projects 1.2, 4.2, 4.3 Partially Address missing4.5 Display employees 1.0, 4.2, 4.3, 4.4 Partially Data is derived5.0 CCells5.1 Browsing CCells – Not available Deprecated5.2 Detailed info 1.1 Not available Deprecated5.3 Joining CCells 5.1, 5.2 Not available Deprecated6.0 Settings6.1 Download data – Available6.2 Universal contact 1.3 Available6.3 Lunch roulette 1.3 From scratch6.4 LinkedIn sync. 1.1 Partially If feasible6.5 About view – Available Flinto links
Table 4: Feature dependencies and available back-end data.
Planning and sorting was done together with project stakeholders, using riskand value definitions from XP. Table 5 below displays risks and table 6 on thefollowing page shows priorities.
Search Favorites Events Overview CCells SettingsDi�culty Medium Low High High High MediumValue High Low Medium Medium Medium LowRisk Low Low High High High LowPriority High Medium None Low None Medium
Table 5: Feature implementation priority from fuzzy logic assessment.
32
Search Favorites Events Overview CCells SettingsCompleteness 0 0 2 1 2 1Volatility 0 0 2 1 2 0Complexity 1 0 2 2 1 0Risk Low Low High Medium High Low
Table 6: Feature implementation risks using XP sorting.
The first iteration would focus on finishing environment setup, API imple-mentation, back-end connectivity, framework integration and rudimentary appnavigation layout. No time would be spent on UI design, although as much aspossible of the basic UX structure. The user stories chosen to primarily workon during this iteration related to the Employee profiles feature group.
The second iteration would be directed toward continued work on the Em-ployee profiles, as well as beginning to implement Overview and networking. Inthis iteration work would also begin to refine UI elements and graphical de-sign. At this point during development real data should be used, instead ofplaceholders.
The third iteration would entail wrap-up work on the prioritized Employeeprofile features. Given that there is enough time, some e↵ort to finish theOverview and networking features would be aimed for, although above expecta-tion. No time would be spent on the Knowledge sharing features, due to missingdata in the back-end databases. Polishing UI and preparing for distribution isincluded in this final iteration.
6.3 Implementing the app design
This section details the result of the development phase. In sections 6.3.2- 6.3.4,it is described how app features were derived from the a�nity model.
6.3.1 App structure
The main features are accessible through the menu shown in Figure 3.
Search & browse is the first view shown when starting the app, and presentsthe user with a list12 view of all of the client’s employees and projects. The usercan switch between viewing employees and projects by tapping a button. Forprojects, the list elements contain customer and project names. For employees,the elements show a photo of the employee, their name, current job role andproject, and a list of their main skills. For projects, the elements contain thename of the project, the name of the customer, the main areas of expertiseinvolved in the project and how many Netlight employees are assigned to theproject.
12List here meaning a vertically scrollable UI component consisting of multiple cells.
33
Figure 3: Main menu view. Figure 4: Search & browse view.
Figure 5: Employee profile view. Figure 6: Geographic overview view.
34
Using the search bar, the user can search for employee names, skill names,project names and customer names depending if projects or employees are shownat the moment.
Employee profile shows a list of information for a selected employee. This listcontains name, C-level13, photo, job role, current and past projects, workplaceaddress, availability (e.g. on vacation or parental leave), mentor, mentees, skillsand expertise, personal description and what Netlight o�ce they belong to. Theprofile also contains an embedded view of a map showing the workplace addressof the employee. Tapping the map takes the user to the Overview feature.Tapping any other employee, being either the mentor or any mentee, takes theuser to that employee’s profile. Tapping any of the current or past projectstakes the user to the profile of that project.
The view has a button that when tapped shows a drop down style list containingthe employee’s contact information. In addition to showing the information,tapping the list items initiates either a phone call, sending a text message orsending an email depending on which item is selected.
If a user navigates to their own profile, an edit button takes the place of thecontact information button. Tapping this button lets the user edit their de-scription as well as skills and expertise. They also have the option to reorderthe skills in the order they want them shown to other users.
Additionally, the employee profile contains a button for adding the employee tothe user’s phone address book and a button for adding them to their Favoriteslist in the app.
Project profile details a certain project. The information in this view consistsof the customer name, project name, workplace address, a description of theproject, the current team members, past team members, the main employeeskills utilized in the project and a map showing the location of the project.Tapping any of the employees takes the user to the profile of that employee.Tapping the map takes the user to the Overview.
Favorites lists a subset of all employees, for quicker access. The user’s mentorand team members are always present, but the user also has the ability to addany employees by using the Add to favorites button in that employee’s profile.Tapping a list item takes the user to the selected employee’s profile.
Events displays a list of upcoming events, and gives the user the ability tocreate new events. Events can be any kind of activity involving more than oneperson. An event list item has a location, a time, a title, photographs of invitedemployees and the option to leave comments. Unanswered event invitations havetwo buttons beneath them, one for accepting and one for declining. A numberrepresenting the amount of unanswered invitations is shown in the main menu(see Figure 3). The user can create a new event using a button available in theEvents view. Tapping it takes the user to a new view where they supply the
13C-level, or consultant level, is the Netlight name for career levels. Only employees withES, TS and consultant job roles have C-levels.
35
title, location and time for the event. By tapping an invite button, the user canuse a modified version of the Search & Browse function to find employees toinvite. Tapping a list item adds an employee to a multiple selection. Instead ofthe employee/project filter, the user can filter employees based on they belongto the user’s team or if their workplace is nearby.
Overview presents the user with a map containing annotations representingemployees. These annotations are clustered together depending on their relativeproximity on the map. E.g., with the map fully zoomed out, each Netlight o�cewould be represented by one annotation. Conversely, each annotation in a fullyzoomed in map would represent all employees at one address. Annotationscontain the number of customers and the total number of employees at thatlocation. Tapping an annotation shows a list of the employees working at thatlocation, each leading to their respective employee’s profile.
CCells shows a list of all CCells, with name and a descriptive image. Tappinga list item takes the user to the profile for that CCell.
CCell profile contains information about a CCell. This information includesthe number of members, a descriptive text, date and summary of the last meet-ing, date and topics for the next meeting. If the user is not a member of theCCell, they have the option to join it by tapping a button. The view also con-tains a list of all members. Tapping an employee item in the member list takesthe user to that employee’s profile.
Settings contains a list of options other features. The user can disable showingtheir location to other employees in the Overview view, disable push messages14
after standard o�ce hours, opt into the Lunch Roulette feature and view infor-mation about the app.
Lunch Roulette lets users opt into a weekly random pairing with anotheremployee. The paired users are notified via a push message, and can thenproceed to schedule a meeting using the Events feature.
6.3.2 Employee profiles
”I want relevant data to be more available” – The app targets this inseveral ways. The information presented in employee and project profiles areall relevant to the end-users in di↵erent ways. Subsets of the information areavailable in other internal systems, but these are only used by employees insome job roles. Consultants, which constitute the largest portion of employees,have access to the least amount of these systems.
”I need easy access to contact information” – Employee profiles and theFavorites feature both address this issue. Since Search & Browse is the initialview of the app, the user can directly search for a name. The Favorites viewtakes two taps to access, first the menu and then the Favorites list item.
14Push messages in the context of smartphones refers to messages sent from a server to aset of subscribed clients that may be displayed as notifications viewable outside of the app.
36
”I want to know what people do” – In all instances where employees arelisted, their current project (for consultants) or job role is always visible. Thisinformation is also available in employee and project profiles.
”I want to know where people work” – The workplace locations of employ-ees are shown in each employee profile, as well as in project profiles for thoseemployees currently on the project.
6.3.3 Knowledge sharing
”I feel like participating in CCells is important for cultivating myskills” – The CCell functionality in the app makes it easier to join a CCell,by letting the user join by tapping a button instead of as previously having tofind the CCell’s email address and send a request. The app also makes it easierto get an overview of the activity in CCells, by collecting them in one placeand listing their meeting times together with summaries of what was discussedduring past meetings and what topics are going to be discussed during futuremeetings.
”Knowledge sharing is central to problem solving and personal growth”– Knowledge sharing is the basis for many of the features in the app. Users haveeasy access to both the knowledge of colleagues and the collected knowledge ofCCells. Colleagues can be found both based on what project they are on andwhat skills they have. The integration of CCells gives the user the ability toeasily find multiple colleagues with knowledge in one area, and also gives themthe opportunity to get involved in the activities of the CCell. Users can alsoutilize the Events feature to create knowledge sharing sessions based on theirskills and expertise.
6.3.4 Networking and overview
”I want the existing systems to be used to their full potential” – Theapp is making existing information more visible and easier for employees toconsume. What was previously only available for some employees gets collectedin one place.
”I want to feel like I’m a part of Netlight as a whole” - Through mostof the above mentioned features, the app helps employees expand their pictureof Netlight. With the Overview feature, employees get a more spatially com-prehensive understanding of the presence of the company. Using the employeeprofiles together with the list in Search & Browse, users can more easily get asense of who all employees are. Seeing the names of employees together withtheir picture also makes them easier to remember.
”Meeting people in person is important to me” - By simplifying theprocess of getting in touch with colleagues, providing an easy way to sched-ule meetings and enabling users to identify nearby colleagues, the barriers forchoosing to meet in person are lowered.
37
6.3.5 Pilot product app
Out of the ten features presented in section 6.3.1, four of them were imple-mented fully, two of them were implemented partially and four of them werenot implemented at all. See table 7 below.
Feature Implemented Partially Implemented Not implementedSearch & Browse xEmployee Profile xProject Profile xFavorites xEvents xOverview xCCells xCCell profile xSettings xLunch Roulette x
Table 7: The state of implementation of proposed features
The app is constructed using the model-view-controller (MVC) design pattern.Employees, projects and customers are represented as models in the app. Theuser interacts with these models through view controllers representing featuresor parts of features.
The back-end is written in Java, and is based on the structure of other internalNetlight systems. It handles the collection and exposure of data. Some detailsabout employees, such as their photo and contact information, are retrieved fromthe client’s Active Directory (AD)15 using LDAP16. Customer and project data,as well as other employee data, is retrieved from Agresso using SQL queries.This information is available to the app through a REST API.
Authentication using AD is in place, but has access only to a test environment.This lead to hard coding of the test credentials into the app, with the intentionto have it replaced with an actual user authentication process as soon as theclient approves the use of the live AD with the app. Also, synchronization ofemployee and customer data is initiated manually. Users are reminded once perweek to download the latest version of the data.
Some of the main features are shown in figures 7, 8, 9 and 10 on the next page.
15Active Directory (AD) is a directory service implemented by Microsoft for Windows do-main networks.
16The Lightweight Directory Access Protocol (LDAP) is an open, vendor-neutral, industrystandard application protocol for accessing and maintaining distributed directory informationservices over an Internet Protocol (IP) network.
38
Figure 7: Main menu view. Figure 8: Search & browse view.
Figure 9: Employee profile view. Figure 10: Geographic overview view.
39
6.4 Implementation schedule
6.4.1 Iteration 1
The projected goal of iteration 1 was a functioning app with the most vitalparts of feature group 1 implemented (see table 3) – being able to search amongemployees based on names, search among projects based on clients, viewing em-ployee profiles with placeholder information as well as project profiles containingdummy data. The data structures needed for this feature group were to be fullyimplemented by the end of this iteration. If possible, work on feature group 2(see table 3) would begin as well.
In some ways the roles of designer and developer persisted from the FRCDphase, with the team member previously designated as designer focusing onfront-end, and the developer on back-end. These roles were informal and onlylived on as a practicality since those areas were where each team member feltmost comfortable and had the most prior experience.
Setting up the development environment was finished quickly, in part due tothe low overhead of the team only consisting of two developers. Some parts ofthe system architecture was established with the use of CocoaPods17, in orderto quickly set up basic functionality such as network connectivity. Using Co-coaPods meant that more time could be spend implementing application specificfeatures over platform formalities.
During the early stages of the first iteration no real data from the client’s ERPsystems were used. Instead dummy data and placeholder images were usedto construct the first version of rudimentary UI layout. Halfway through theiteration access to the ERP systems was granted and the app could be populatedwith actual data, managed locally through the use of Core Data18, and on server-side by custom software written by the project supervisors. The connectionbetween the two was based on a REST API 19 written in collaboration with thesupervisors.
Toward the end of the iteration user portrait photos were integrated, alongwith the finished feature for employee and project searching, and functionalityfor directly contacting employees by calling, texting or sending emails from theapp.
In summary the iteration was executed according to plan, even being slightlyahead of schedule. This was due to the help provided by the supervisors withback-end development, which would otherwise be outside the scope of thisproject.
17CocoaPods is a directory for open source Objective-C libraries and external dependenciesto be used in Xcode projects, available at http://www.cocoapods.org
18Core Data is an object graph and persistence framework provided by Apple in the MacOS X and iOS operating systems.
19Representational state transfer (REST) is a software architectural style, most commonlyusing HTTP to provide applications with networking capabilities.
40
6.4.2 Iteration 2
At the start of the second iteration it was noted that work had progressedfaster than anticipated. Since feature groups 1 and 2 were well underway andusing real data, together with basic setup for feature group 6 being readied,implementation of the Networking and overview features of group 4 (see table 3)was started. There was slight overlap with the Employee profiles feature group,since that view contained map elements as well (more information on featurescan be found in section 6.3.1).
During this part of implementation the UI was styled according to the client’sbranding guidelines, and an e↵ort was made to improve on visual aesthetics andpresentation. To this end animations were used to convey navigation cues, anda lot of programmatic fine-tuning was necessary for a majority of UI views.
The app was also given a login screen, about view, and a side-menu used forfeature group navigation. Also, mentorship connections were fully implementedand project data connections to the correct employees was troubleshot. Manyfeatures proved di�cult to implement during this iteration since much back-enddata, although accessible, turned out to be in worse condition than estimatedduring the design study. This prompted changes to data management andpresentation.
This iteration was more challenging than the previous, and while work wasstill ahead of schedule that advantage had been reduced somewhat. In termsof backlog progress, velocity was reduced during the iteration, mainly due toincreases in development complexity.
6.4.3 Iteration 3
When the final iteration began it was decided that no more features wouldbe implemented. Instead during these last two weeks work would be orientedtoward wrapping up development, tidying up code, documenting functionality,debugging existing features and polishing UI.
A document was authored that described all development details and instruc-tions for further work, and was handed over to the client, as well as beingpublished on Rebel, the company wiki. The app was presented and tested on-site at client headquarters by end-users. Preparations for publishing the appon a private enterprise server were made together with members of the mobiledevelopment CCell.
All in all the development phase resulted in a product above expectation, butstill not a full implementation of the design devised through FRCD.
41
42
7 General results
7.1 Applicability of Rapid CD
During the course of the case study, as many as possible of the steps in RapidCD were included. It was found that most parts of the process are applicablefor smartphone app design and development, a few are not as suitable, and thatsome would benefit from modifications.
Contextual Inquiry and interpretation - the contextual inquiry portion ofRapid CD was the one that proved most valuable, as could be expected. Thequality of the data gathered in this step was very high, especially comparedto the hypothetical case of a standard question-based interview. Through in-terpretation many valuable, and sometimes unexpected, insights were gainedregarding the needs of the company employees.
One of the common needs identified for o↵-site consultants were a fast and easyway to spontaneously plan lunches and lunch meetings for nearby colleagues.This lead to the inception of the event feature in the system vision. Perhapsmost importantly the interviews provided a thorough insight into the innerworkings, systems and structures of the company, which helped motivate laterdesign choices.
Data consolidation - Work models and artifact models did not prove veryuseful in the case study. Since the main focus was on communication and smart-phones however, information about the artifacts used for this was not captured.All of the end-users were in possession of a smartphone and a laptop computer,which for most of them made up their entire workspace. This, together withthe fact that most of the end-users often switch desks, lead work models beingdisregarded. The sequences captured did not lead to any sequence models thatwere deemed to be of a high enough quality to be included in the study.
Building the a�nity model - This exercise proved highly valuable for thisparticular project, and constituted the cornerstone of requirements analysis.The lack of an assigned room for the core team started to become an inconve-nience here, as all of the a�nity diagram was constructed by notes were writtenon sticky notes. The diagram had to be manually assembled and disassembledon a large, movable whiteboard for each a�nity diagram construction session.
Some digital representation of the a�nity diagram would perhaps have beenpreferable in the interest of time, but the act of physically moving, grouping andrearranging the paper notes while discussing them was experienced by the teamas both helpful and pedagogical. The constant interaction with the physicalnotes made it possible to digest, understand and remember the observationsfrom the CI interviews better. Additionally, the clearly visible and accessiblewhiteboard was very easy to show to stakeholders and interested parties.
Visioning - This was an important session of interaction with the end-users.While some subjects had been cautious or reserved during the CI interviews, the
43
collaborative setting of the visioning seminar made the end-users feel involvedand were able to get their voices recognized. Not only was this step importantfrom the viewpoint of user-centered design by creating the foundation for UX,but it also provided an excellent opportunity for technical feedback and pointerssince many of the attendees were working on internal projects and systems.Being able to discuss feature ideas with technical personnel otherwise uninvolvedwas a great opportunity for constructive criticism and design.
The event was advertised toward a wide group of employees, and snacks wereserved during the meeting in order to both attract attendees and keep theenergy level up during the later hours of the workday. The authors would adviseother groups applying this process step to do the same, in order to promote apositive, creative and casual atmosphere where attendees could freely voice theirthoughts.
The resulting consolidated vision (drawn on whiteboard) also functioned as aninclusive and complete high-level interaction map from which all storyboardswere consequently created. The exercise of consolidating the partial visions wasperceived as a very rewarding and important aspect of UX design. As with thea�nity model, the whiteboard on which the consolidated vision was drawn wasavailable for anyone at the o�ce to look at.
Storyboarding - While the storyboarding sessions were a good opportunityfor UX design and were an e↵ective way of processing the consolidated visionin terms of concrete system interactions, the app being designed was perhaps abit too small in scope to really benefit from the storyboard design in the longterm. In retrospect only the backlog items constructed from the storyboardswere actively used during the development phase.
The vision consolidation session was perhaps more productive for a project ofthis scale. If the project had been larger in scope and had included more func-tionality and usage patterns (or meant for a non-mobile device) a single consol-idated vision would probably have been insu�cient, and individual storyboardsare easier to explain to stakeholders or a larger group of developers.
However, for the small team and relatively small product in this project thestoryboarding could reasonably have been diminished to direct backlog entrywriting based directly on the consolidated vision. The team of (front-end) de-velopers did not change during implementation, so no new people had to beintroduced to the UX storyboards. In the case of a longer development cy-cle and a changing set of team members, having storyboards on hand wouldprobably have been a good investment.
Product and system requirements - The process of gathering technicalspecifications and evaluating back-end resources was a much longer process thanwhat could be scheduled for a day or two of the design process. This was becauseof practical circumstances, such as technical personnel and authoritative personsbeing scarcely available during working hours. Therefore these meetings had tobe conducted in parallel to the Rapid CD process whenever possible.
UX-related requirements were created in the form of backlog entries based on the
44
storyboards. These did not require negotiations with non-core team members(that is, the type of stakeholders referred to as ”chickens” by Holtzblatt et al.,as in contrast to ”pigs” who make a greater investment into the project [1]),and were created with platform-specific considerations in mind by the core teamalone – in the correct section of the Rapid CD process sequence.
Constructing personas - Since the purpose of the personas is mainly to in-troduce new stakeholders, helpers or team members to the project as a partof walking the a�nity model and consolidated sequences, they did not proveespecially useful during this project. This was mostly because the majority ofinvolved personnel were employed by the client—and thus already well versedin the variance of job roles there. They did however help consolidating the bigpicture of the system’s end-users, and did bring light to some questions aboutjob roles, which brought further insight into the client company.
Paper prototyping - As described in section 6.1.6, paper prototyping wasskipped in favor of digital prototyping. Though testing and demonstrating morehigh-level design concepts of the app was easier by using digital prototypingtools, a lot more e↵ort had to be placed in producing images early on. Thiswas not a major issue since the team had reasonable experience in the field,and it proved crucial that the entire UX flow and layout had been sketched anditerated a few times on whiteboard.
Prototype interviews - Overall, the prototype interviews did not turn out asplanned. Instead of carefully laid out paper models being thoroughly walkedthrough over long interview sessions they were mostly quick demonstrations ofthe app concept shown on a smartphone. The user would typically go throughmost features without needed intervention, only pausing to give design feedbackor pose questions about a specific feature and how it would work. While thisdeviates from the Rapid CD guidelines it was in retrospect much more appro-priate to the nature of the product. Performing usability tests using generic UIelements outside the context of an actual platform seemed detrimental to theprogress of the prototype.
7.2 Rapid CD for small teams
Rapid CD is constructed with a core team of two people as the model. Theexpectation is that the team has access to other individuals, referred to ashelpers, which can come in at di↵erent points to assist. During this project,there was very limited access to helpers, since the client’s employees are mostlyconsultants busy working on projects of their own. For the visioning seminarhowever, there was an opportunity to assemble a number of helpers.
Had it been possible to enlist the help of more client employees, more valuableinput from the end-users could have been collected. From a time perspective,there was no issue of running out of time at any point. On the contrary, work wasconsistently slightly ahead of schedule. This is likely due to the smaller scopeof the project compared to the ones mentioned in the Rapid CD literature.
45
7.3 Digital complements to paper prototyping
As mentioned earlier in sections 6.1.6, 6.1.7, and briefly in 7.1, the paper proto-typing stage of the Rapid CD process was omitted in favor of digital prototypingtools. The reasoning behind this decision and its repercussions are further dis-cussed in section 8.5.
7.4 Agile
The agile principle of only developing small, incremental releases proved a goodfit with iPhone app development. Most of the development was done on rela-tively high level, meaning that for the most part it was possible to build whatwas planned without having to make use of lower-level language features thatwould potentially increase the di�culty of development. This, together withthe fact that the development environment takes care of a lot of the overheadthat could be present when developing for other platforms contributed to theease with which the app could be incrementally developed.
The agile method used was a combination of general agile principles, as well asprinciples and practices from Scrum and XP. The end results worked very wellfor the situation in this project. A summary of what was incorporated fromexisting methods is shown below.
General
• iterations - the development phase was divided into three iterations, eachtwo weeks in length.
• small, frequent releases - although there were no actual product re-leases, progress was demoed to stakeholders at least once per iteration,either in person or via screenshots or videos.
• user stories - to define what needed to be built, user stories were created,which were then stored on an online service.
Scrum
• backlog - all user stories were stored in a product backlog, while thestories being worked on during a particular iteration were stored on asprint backlog.
• roles - the role of ScrumMaster was not used, but together with theproject supervisors the development team did take on the role of productowner. More preferable would have been if there had been a stakeholderavailable to take on the role of product owner.
46
XP
• pair programming - for many of the more di�cult sections of imple-mentation, pair programming was employed to increase quality of codeand to help get through that particular piece of work faster.
• refactoring - code was refactored to increase readability and performancewhenever possible, and especially in the last iteration when preparing tohand over the app to the client.
• customer always available - in this case the thesis project supervisorscould be considered the customer. They were always available for feedbackand questions, albeit not always in person.
47
48
8 Discussion
8.1 Case study reflections
8.1.1 Planning
Dividing this project into equal parts design and development was a decisionmade early on. It was mainly motivated by the time requirements stated byHoltzblatt et al. for an inclusive but intensive focused rapid contextual design(FRCD) study [1], which left only an equal amount of time for implementation.It was decided that a full implementation was not needed to prove the applica-bility of Rapid CD for a knowledge sharing smartphone project, and that onlya pilot app or proof of concept (POC) would be delivered to the client.
One mistake was not allocating quite enough time for post-implementationfollow-up, which led to the usability study feeling slightly rushed. It was de-bated as well whether a formal usability evaluation was applicable or relevant,since only parts of the designed features were implemented in the final release,and some parts of the UI still utilized dummy data.
Had the e↵ort been made far in advance, it might have been possible to get morehelpers to contribute. This would still not be guaranteed, since the consultantsat the client’s o�ce can suddenly be called to work at another location.
8.1.2 Execution
In retrospect the project plan played out as intended, nothing which was origi-nally included in the plan had to be omitted and very few last-minute compro-mises had to be made in order to stay on schedule. Sometimes during the laterstages of the design phase the time allotted for certain steps intruded on eachother, but no deeper issues than that were experienced.
One thing that could have been added would be smaller UI evaluations at theend of each sprint, to see if there were any tweaks that could have been madeto the design. This would have required some planning and thought into in howto evaluate the UI though, which in turn would have required time.
8.2 Quality of results
8.2.1 Project results in relation to client requirements
The project status was presented to stakeholders and end-users at four o�cialevents. First at the visionary seminar during the design phase, then twice for theMobile CCell (one during development and one after the last sprint had ended),and once at the final thesis project presentation at the client’s headquarters. At
49
each instance both stakeholders and end-users were encouraged to leave feedbackand discuss the features of the app. This lead to the end-users feeling at leastsomewhat involved in the process, according to talks with employees.
These o�cial presentations were also a good opportunity to present ideas to ex-ternal consultants who were otherwise di�cult to get in touch with—an end-usergroup largely underrepresented since they embody the majority of employees.
Certain stakeholders, such as supervisors, mobile developers and internal projectmanagers, were much more involved in the process during both design anddevelopment. These interactions mostly took place in the form of meetings andinterviews. This was important since it was always desired to stay on the righttrack, and not overlap with other internal projects and use the most relevantdata and tools accessible.
The cooperation between developers and end-users through Rapid CD provedfruitful – the project resulted in a design that seemed to address the issuescurrently experienced by the client well. The study also pointed out somediscrepancies and concerns both in terms of the quality of internal databasesand social mechanisms in the company, nothing critical but areas of possibleimprovement. Most of these issues were in some way addressed by the appconcept, while others (such as missing or flawed back-end data) restricted theprogress of the implemented app and thus prompted further inspection of thesedetails.
At the end of the project the collected work was handed over to the client, andsteps were taken to ensure that the project would live on through continueddevelopment for iOS as well as Android. Enthusiasts and developers commentedon the usefulness of the app, even in its current state of implementation, andemphasized the importance of taking this project forward in the future.
8.3 Evaluating UI and UX
It was debated whether or not time would be devoted to a formal evaluationof the developed UI, in order to estimate the end-users’ ability to understandand use it. The conceptual design had already been evaluated with the end-users during the prototype interviews, in the form of demos and open-endedinterviews, which were a source of subjective data. However, the prototypeswere only drawn as wireframes with limited UI elements and graphical design.The final implementation could therefore had been evaluated more thoroughlywith methods like cognitive walkthroughs20 or formative evaluation21. Whetheror not a formal study would yield outcomes of practical or academic value wasuncertain, since the app was only a partial implementation of the concept.
20Cognitive walkthrough is a usability inspection method where interfaces are evaluatedbased on their usability by letting representative users ”think aloud” while using the interfaceto complete specific tasks.
21Formative evaluation is a usability inspection method used during evolving stages ofsystem design in order to assess usability or performance by rating representative users’ actionsbased on a set of metrics. It is often used in conjunction with summative evaluation.
50
A brief and informal heuristic evaluation22 based on the human interface guide-lines for iOS 7 [23] decided that the app adhered to them correctly. There weresome discussion regarding the use of a side menu instead of a tab bar for basicnavigation, but the decision to use a side menu was strongly motivated by thefact that five items is a recommended maximum for an iOS 7 tab bar whilethe app design called for six. Another case was the semi-novel features in thecustom map implementation, where clustering was used, as well as callout viewsin the form of table views. While unconventional, they were not found to violateany of the recommended usage patterns for iOS 7.
The last disputed part of the app’s UI was the possibility for recursive navi-gation. This means for example that the user may navigate from employee Ato employee B, and then from employee B to employee C, pushing new viewson the same navigation stack. However, there is nothing stopping employee Cfrom being equal to employee A, which may lead to something of a loop. Thesame goes for employee profiles and project profiles. While this is considered anintended feature when navigating to new employee profiles, the navigation stackwill grow if the user tries to navigate backwards without using the designatedbutton, which may lead to an unintuitive UX pattern when popping the viewsfrom the navigation stack for backwards navigation. Whether or not this fea-ture can be avoided without introducing additional unexpected and unintuitivebehavior remains unclear. It should be noted that the same problem existed ina previous attempt at an internal communications app (see the Koala app insection 4.6).
8.4 Method analysis
8.4.1 Properties of smartphone development and design
Modern smartphone app development teams usually range in size from one tofive core team members23, and development cycles are seldom longer than a fewmonths between releases. Even simpler apps may be developed and releasedwithin a couple of weeks, but whether or not these short projects require adesign pre-study is arguable.
The FRCD team in this case study consisted of two core members—perhaps themethod would have been altered di↵erently if this had been a larger smartphonedevelopment team. In any case the FRCD method calls for two or three des-ignated roles. In a larger development team those unassigned these roles mayact as helpers during many of the method steps. In the case of a single-persondesign team the applicability of Rapid CD may be compromised, since many ofthe activities are based on gathering and digesting end-user data in pairs.
22Heuristic evaluation is a usability inspection method where interfaces are evaluated basedon their compliance with a set of recognized usability principles, or heuristics, for a particularplatform or interface type.
23It should be noted that some apps require a great deal more workers, e.g., games andgraphics-heavy applications. However, not all of these artists and engineers are included inthe core smartphone team.
51
While assets and elements for smartphone UIs are often well-defined and de-lineated with a substantial set of guidelines and market examples, each appproject that aspires to either commercial success or some level of aesthetic qual-ity rely on a designated designer or design team for UI and UX. Design is usuallybest done one sprint or iteration ahead of development. In small projects thisnormally means simply implementing a finished design in a single sprint.
The base of end-users for a certain app may vary widely, but one common factremains – they are smartphone users of a known platform, and certain expec-tations regarding interaction metaphors and usage patterns can be maintained.As long as the design keeps to staple interaction techniques and UI elements theusability of the app can be somewhat ensured. Novel UIs however may requireexplanation or tutorials.
8.4.2 Applicability of Rapid CD
The application of Rapid CD to this project was in the end successful, but someparts of the method seemed more relevant than others in this particular case.Here it will be discussed what steps may be omitted and which may be givenadditional time, depending on the team’s conditions.
There are many factors weighing in on the team’s decisions when planning andchoosing a method or process, such as team size, time span, team experience,team location in relation to the customer (and each other), equipment avail-able, budget, and requirements given. There may also be external or internalconstraints that bind the team from using or applying certain tools or processes.
Holtzblatt et al. introduce three distinct versions of Rapid CD, Lightning Fast,Lightning Fast + and Focused Rapid CD [1], which are described in more detailin section 5.1. In every instance or project the process may be used di↵erently,cherry picking process steps or using a predefined variation. However, the keypurpose of Rapid CD is gathering end-user data. The process as a whole canbe used by any project that requires a more fleshed out usage context for thedesired product, even if no technical development is involved. It is also preferredfor projects with a small scope and well-defined job roles.
The defining characteristics for the project case were first of all that while thebase of end-users was well known, very little was known regarding requirements,end-user needs, usage context, pre-existing systems, or project goal. This alonemeans that the project would certainly gain from some adaptation of RapidCD. In addition to this the development team was small, its time frame wasrelatively short (about three months), there was little risk of core team membersquitting or being replaced, only a few stakeholders would be actively involved,there would be no designated development room or workspace, the team hadreasonable experience in both design and development for relevant platforms,and the project would be aimed at smartphones.
Because of the fact that the project would be commenced and concluded in aspan of six months, Rapid CD was chosen. There are many more design methods
52
with considerably longer time requirements, but Rapid CD was designed in2005 to cater to the needs of projects with smaller scopes. The six week longfocused rapid contextual design (FRCD) version was chosen in order to allowfor evaluation of all stages of the process.
8.4.3 Introducing additional qualification parameters
While the variations of Rapid CD are a good start-o↵ point for project designplanning, the decision between them is mostly based on the team’s relationshipto two primary parameters:
Time - The time available until project deadline.
Scope - The size of the project and the amount of work to be completed.
Similar to the definition of small teams, ”small projects” in this context willrefer to a project with both relatively short time duration (not more than sixmonths) and limited scope (developing only for one or two platforms, and witha workload that matches the duration). A more detailed set of metrics willnow be defined, from which a project’s compatibility with certain aspects ofRapid CD can be measured for small projects. These four heuristic qualificationparameters depend on and a↵ect the two primary parameters as follows:
Team cohesion (TC) - This parameter depends on internal team dynamics.A strong team cohesion means that the team is well organized and put together,and that there is little risk of team members leaving the project or being re-placed. Team cohesion is vulnerable in projects with long duration and largescopes. Large teams are more prone to replacements, but the consequences ofa missing team member are less dire.
A typically strong team in terms of cohesion is a team composed of around twoto four core members with prior cooperation experience and good chemistry,preferably in a small project with short duration and limited feature scope. Ateam with poor cohesion would consist of either too many or too few membersin relation to time and scope, and where there is risk of members not being ableto work full time during the length of the project. Team cohesion may a↵ectthe applicability of almost all Rapid CD steps, but in particular contextualinquiry interpretation, data consolidation, storyboarding, prototype mockups,UI design, and of course implementation.
Team presence (TP) - This parameter depends on external team dynam-ics. A strong team presence means that the team is able to work closely withstakeholders and end-users, preferably by having an on-site room or workspacesuitable for wall walking. Presence is a two-way channel of communication be-tween the core team and stakeholders. Poor team presence may just as wellbe caused by stakeholder unavailability as by the core team. Presence is alsoimplicitly based on openness and team member communication skills. Teampresence may a↵ect the applicability of Rapid CD steps like contextual inquiry,wall walking, personas, visioning, and prototype interviews.
53
Team aptitude (TA) - This parameter depends on internal resources andskills. It depicts how experienced the team is, and how many areas of expertisethe core team covers. A strong team aptitude means that the team’s capabilityfor good design and development is adequate, and that the core team memberscan use their insight to speed up or improve the project process. Team apti-tude stands in direct correlation to the scope possible to complete within giventime. The interplay between a team’s cohesion and aptitude a↵ects the team’schance of success. If the individual members of the core team are skilled in allnecessary areas but lack cohesion, the amount of scope implementation possibleduring available time is decreased. Team aptitude may specifically a↵ect the ap-plicability of Rapid CD steps like storyboarding, prototyping, design iteration,requirements specification, and implementation.
Team resources (TR) - This variable depends on external resources andskills. It depicts how accessible necessary expertise and aide is to the team, andhow much the team depends on it. It also includes how accessible and definedend-users are. Having strong team resources means that the team is able toacquire anything it needs from the stakeholders, end-users, or external partiesupon request. Good team resources can compensate for poor aptitude, meaningthat having graphical resources available on-site may o↵set lacking a designateddesigner.
Team resources relies on team presence, and can only be utilized fully if presenceis strong. If the team has access to plenty of assistance but lack presence, theamount of scope implementation possible during available time is decreased.Team resources may a↵ect the applicability of contextual inquiry, wall walking,visioning, prototype interviews, requirements gathering and implementation.
8.4.4 Qualification parameters applied to case project
In retrospect the qualification parameter metrics can be applied to the con-text of the project case to see how they interacted. Team cohesion was strongthroughout the project. Both core team members were able to work full time,and cooperation worked well – according to expectations. While time was fixedby contract, the project scope was up to the team to delimit. Thus, the rel-atively expansive project scope did not damage cohesion. The team size wasdeemed appropriate for the project, and overall the impression of this parameterhas been solid.
In contrast, the team presence during the project was lacking. The distancebetween the team members’ living areas and site location demanded a ratherlong daily commute (2.5 hours round trip). This lead to the site only beingvisited on average four days per week during the design phase, and only oneto two days per week during development. Also there was no dedicated roomavailable on-site, which negatively a↵ected the possibility for wall walks, etc.
Team aptitude was estimated to be fairly strong. Together, the two team mem-bers shared experience and skills in both design and development that was ableto span most of the areas relevant to the project. Even though practical experi-
54
ence in Rapid CD itself was lacking, the tutelage of the thesis reviewer alleviatedthe situation. The areas perhaps not as strongly covered were those related tothe client’s particular back-end systems. However, due to scope delimitationsand external resources this was manageable.
The team resources parameter was deemed adequately strong. The client com-pany being a technical consulting firm meant that most know-how and technicaladvice needed was within reach. The body of end-users was well defined andeasily approachable, meaning that the contextual inquiry portion (the founda-tion for every CD study) was made easier to perform. The two thesis projectsupervisors were very helpful and proved a good aid in back-end developmentwhere access was restricted. The positive attitude of involved stakeholders hada major part in the success of the project. One problem was that many stake-holders were busy during working hours, which impeded scheduling meetings.Also, as described previously in section 8.4.3, the lacking team presence a↵ectedthe ability to perhaps fully access the resources. In summary the profile of thecase project is illustrated in table 8.
Parameter Poor Lacking Adequate Fair StrongTeam cohesion xTeam presence xTeam aptitude xTeam resources x
Table 8: Qualification parameters applied to the case project.
8.4.5 Qualification parameters applied to fictional examples
Let’s demonstrate these qualification parameters in the context of a few exampleprojects, and illustrate how they may guide method considerations. All projectshere are defined as ”small” in nature, with timespans less than six monthsand teams with five or fewer members. In table 9 a fictitious project groupthat lacks experience in UX and UI design is depicted. However, they haveabundant resources, a designated project space, and are able to be highly presentduring the design study. Thus the project team would do well in focusingattention and allocating time for meticulous prototyping, preferably with papermodels initially, and designing in multiple iterations. Emphasizing personas,wall walking, storyboarding, prototype interviews, and UI iteration would likelybe considered advantageous.
Parameter Poor Lacking Adequate Fair StrongTeam cohesion xTeam presence xTeam aptitude xTeam resources x
Table 9: Qualification parameters for example project 1, a project team withlacking design aptitude.
55
Another, more complex example is given in table 10. Here the team compositionis volatile. Due to the time and scope of the project, not all members will beable to fully attend the planned design phase. Also, the team must be locatedremotely from the usage context of the product app. Luckily, the team’s externalresources are strong, and the body of end-users is well known with significantpre-existing user data. The external resources available compensate for the poorteam cohesion and as such the overall aptitude is fairly una↵ected.
In such a scenario the team ought to review their primary parameters: timeand scope, perhaps planning a longer design study to be able to a↵ord any sta↵losses, and being able to fully carry out the Rapid CD process in order to ensurehigh usability. Another red flag is that the team may be eluding themselves asto how much assistance they may be able to gain from their resources, due totheir poor presence. If their end-user data is solid, they may be able to omitstages like persona creation. But personas are part of the wall walk, which maybe important in the case of team member replacement.
Parameter Poor Lacking Adequate Fair StrongTeam cohesion xTeam presence xTeam aptitude xTeam resources x
Table 10: Qualification parameters for example project 2, a project team withpoor presence and volatile team composition.
8.5 Digital and physical prototyping
8.5.1 The prototyping process
Normally the Rapid CD method suggests that paper prototyping should beused as a first step of testing the vision of the future workspace. This is espe-cially preferable when redesigning an existing tool or system, since the entireexperience is broken down to core components, crudely represented by pieces ofpaper. This has a number of advantages for redesign. For starters, the testerwill not be distracted by visual design factors but focused on structure andfunctionality. [1, p. 248]. Furthermore the tester will not be able to rely ontacit preconceived notions, misconceptions, or user experience (UX) flaws thatmay have been present in the previous system.
Paper prototyping has other appealing properties as well. Very little time isneeded to create a full paper model of a system UX, as compared to wireframing.Paper prototypes may also be modified or amended quickly during interviews.Low fidelity prototypes are a small investment and few things can go wrong.The errors that may occur are almost strictly related to handling all the separatepieces of paper, meaning that UI elements may go missing, break or get confusedwith other elements by accidents during interviews.
56
There is also an overhead that grows with the size of the system, slowing downor causing intermittent interruptions during interviews. Holtzblatt et al. recom-mends acting out these problems with excuses of technical di�culties, such asa temporarily slow server. [1, p. 264] But they also emphasize careful prepara-tions, so if handled properly physical prototypes should have low overhead andpose low risks for the project team, and is imperative when trying out noveldesign concepts or metaphors in large-scale projects.
Wireframing and digital prototyping are not alternatives to paper mockups.Rather they are a later step in the design chain, often building on the struc-tures and observations made from paper prototypes. If a project team wouldstart prototyping with digital wireframes directly they run the risk of wastingtime on inappropriate features, miscalculated or untested UI or UX sketches,or otherwise unwanted parts of the design. However, it should be noted thatdigital wireframe prototypes are not the last step in the design chain either,and do not utilize fleshed-out visual design. It is an intermediate step betweensketch and product.
8.5.2 Prototyping in this particular project
There are several factors that lead to the use Flinto over paper prototypes inthis project, despite the advice given by Holtzblatt et al. [1, p. 248] The mainconsideration was that there was only enough time allotted in the project planfor one round of prototyping, due to the conflict between using as many stepsas possible of the highly inclusive FRCD process and only being able to do thisin a six week time span.
Other factors weighed in on the choice to omit physical prototypes. Firstly thesmartphone platforms have a relatively small set of design elements, which intheir basic forms are standardized and well-known for users on the particularplatform (especially so if the majority of end-users are technologically proficient– or even developers themselves – such as the consultants working at Netlight).
Secondly the projects described in the related literature are in general muchlarger in size and scope than this project, sometimes requiring novel UI elements,meaning that they have a larger need to be able to quickly replace and moveparts of the UI before going on to create a wireframe of the whole system. Inthe case of using Flinto, this simply becomes a case of switching an image foranother and redrawing a few connections. It would also not be unreasonable toassume that online wireframing tools available at the point in time when theliterature was written, ten years before the writing of this thesis, were not aswell suited for quick changes in architecture as Flinto and its contemporaries.
Thirdly, using Flinto to conduct the prototype interviews it is possible to see theuser interact with the system in a way that closely resembles how they wouldwith the actual app. This becomes possible because of the fact that Flintowireframes can be interacted with in most ways possible on a smartphone andcan be launched and viewed on the user’s own device. Prototype interviews willalso be faster since no modification of the prototype is performed during it.
57
When a wireframe is launched on a device, the user automatically sees the latestversion available. Giving a user access to the wireframe is just a matter of givingthem a hyperlink, which means that spreading it to a wider audience is easier.A wider spread does not necessarily mean more qualitative data, but in thiscase where most of the users were o↵-site it became easier to get more feedback.
It should also be noted that both developers on the team have had previous expe-rience in designing and developing graphical wireframes, mockups and standardUI for iOS apps. This was also a driving motivation for skipping the paperprototype phase, as what stood to gain from testing low fidelity sketches ontechnological professionals seemed insignificant when there was already a goodunderstanding of how to design such a UI according to industry practice.
Thus the limited time available, together with the predefined and delimitedbody of UI building blocks provided for developers, and previous experience ledto the conclusion that paper prototyping in this case could be left out in favorof more in-depth use of modern digital tools. However, despite these advantagesof digital prototyping some problems – both unforeseen and anticipated – aroseduring prototype interviews and testing.
As described in section 6.1.7, during the interviews some testers were obliviousto the fact that they were only testing a Flinto prototype and not a real iOS app,despite many of the cues and instructions provided. This lead to the questionsof whether or not prototypes can be too realistic, and what adverse e↵ects maybe caused by digital prototyping. This will be further examined in section 8.5.3.
8.5.3 Trade-o↵ considerations
The digital approach to prototyping in lieu of using physical pieces of paperstreamlined and facilitated some aspects of the process, while slowing downothers. For example, creating full wireframe mockups of every view in theenvisioned app and then updating them based on feedback was more demandingthan sketching them on paper. Other consequences of digital prototyping asopposed to paper models was that moving UI parts could not be done on the flyduring interviews, nor could notes or corrections be made on the model itself.
For a team attempting to use Rapid CD or any other user-centered methodencompassing prototyping the authors recommend that they are well acquaintedwith producing graphical wireframes and mockups, as well as designing UXprocesses for the platform in question, before they should abandon the paperstep. They should neither attempt this if the system is large (as in containingmany features, views or use cases), or is used by a highly inhomogeneous baseof end-users.
Distribution and thus demonstration was drastically sped up with the use ofFlinto, facilitating the process of showing stakeholders and end-users visionsand ideas in a real context. But while Flinto provided functionality for receivinginstant user feedback this feature was never used, since it was argued that itdiverged from the user-centered core values of the project. The feedback that
58
was processed was instead that which was gathered directly from the prototypeinterviews, where users could be seen interacting with the app and their opinionscould be explored in person.
In summary, digital prototyping should not be thought of as an exclusive alter-native to classical paper prototyping with physical analogies. However, manyof the modern digital tools (such as Flinto) are significantly easier to manip-ulate, organize, layout, test and distribute than wireframe images alone. Thisplaces modern digital prototyping as a complement to the traditional paper-wireframe-mockup design process. There are trade-o↵ aspects to every projecthowever, and it may not always be clear what steps to do in what circumstance.Appropriate procedures are recommended in section 9.3.
59
60
9 Conclusions and future work
The goal of this thesis was to investigate the possibilities of adapting the RapidContextual Design (CD) process for modern smartphone application develop-ment. Together with this goal, the following three questions were investigated:
• how applicable are CD and agile development methods when designingand developing new smartphone applications?
• how can a core team of two people best adapt the CD process to suit theirlimited resources?
• are modern, digital prototyping tools viable replacements or complementsto the conventional paper prototyping process?
To find the answers to these questions, a case study was performed at NetlightConsulting AB where Rapid Contextual Design and agile development methodswere employed to design and develop an iPhone app for communication andknowledge sharing.
The results of this case study show that Rapid CD certainly has the potentialto work well with smartphone app development. It is especially a good fitwhen objectives are vague, and when usability is in focus. However, resultsmay vary depending on how the method is adapted to the project. In order toproperly choose, plan and a adapt a Rapid CD version to smartphone projects,a set of qualification parameters expanding on those available in contemporaryliterature may be used. It was found that there are oportunities for updatingthe prototyping component of Rapid CD, but that some further investigation isneeded to determine how this is done best.
In this section, answers to the research questions are presented, work done sofar is summarized, and what future initiatives could be taken to develop theprocess further are described.
9.1 General conclusions
The aim of this thesis has been to explore ways to adapt the rapid contextualdesign process to agile smartphone application development projects. Section 1explains that a successful adaptation could prove valuable to smartphone ap-plication development (as well as software development projects in general)considering the proven benefits of contextual design.
The case study described in sections 4- 6 was successful in terms of satisfyingthe needs of the client. The pilot app that was developed was well received, andwas deemed very attractive as a project to continue development on within thecompany. The client was also impressed with the level of understanding of thecompany and its issues that the Rapid CD process helped gather, resulting inapp features that were all relevant to the end-users.
61
In section 8.4.2, an additional set of metrics called qualification parameters wasintroduced. These are meant to be used when deciding what parts of the Rapidcontextual design (CD) process to include and what parts to skip. They canalso be used when deciding what version of Rapid CD to pick when planning aproject.
9.2 Process adaptation
As introduced during the discussion in section 8.4.3, a set of qualification param-eters have been designed in order to help teams in the project planning phase. Itis suggested that any team surveying their project’s qualifications for Rapid CDobserve these metrics during planning. Analyzing the own team’s qualificationparameters may help when choosing or building a suitable variation of RapidCD, and may in the end increase chances of a quality result.
There are two primary parameters for any development project in this model,time and scope. In addition to these, a deeper set of qualification parametersbased on core team conditions, team cohesion, team presence, team aptitude, andteam resources was presented. More information on how these parameters inter-act with each other and the primary parameters are discussed in section 8.4.3,8.4.4, and 8.4.5.
9.3 Prototyping recommendations
Prototyping has become a very common method of UI and UX design. Com-monly the first stages of prototyping are carried out with paper models, testingnew ideas without having to design an entire interface. For smartphone appdevelopment there are standardized tools, metaphors and UI elements that maymake paper prototyping unnecessarily time consuming in small projects. Espe-cially when digital mockup and wireframing tools that make it easy to test anidea with a large user base are available. The pros and cons of replacing physicalprototyping with digital in certain scenarios have been discussed in section 8.5.
9.4 Suggestions for future work
There are several problems that remain unsolved, and need to be addressedbefore a fully adapted version of Contextual Design for smartphone applicationdevelopment can be published. Here in this final section a few pointers are begiven for future work on the subject.
The main work that needs to be done is to test and validate the usefulness ofthe additional qualification parameters introduced in section 8.4.3. If proven tobe accurate and valuable to project planning, they could potentially be used asa base in expanding the planning and process step composition of Rapid CDand derivative processes.
62
Since the paper prototyping step of Rapid CD was not tested, it is recommendthat it be further investigated in conjection with digital prototyping tools. It hasbeen suggested that digital prototyping could be a viable replacement for paperprototyping, but during which circumstances this would be the case remain par-tially ambiguous. The technique would probably be suitable as a complementarystep to paper prototyping in most project where time is available.
If a team of more than two people was available, more aspects of both RapidCD and agile development methods could be explored. Committing to followinga single agile method and making use of helpers in the Rapid CD process wouldbe interesting paths to pursue.
As noted in the discussion, digital prototyping interviews cannot be performedusing the same interview techniques as those for paper prototypes. This callsfor an investigation into how digital prototyping interviews could best be per-formed and whether or not interview sessions could be tracked using software,for extended analysis purposes.
Finally, we the authors encourage further analysis of development and designprojects conducted by small teams (preferably of varying sizes) where a formalmethod for user-centered design has been applied. It is our thesis that even smallprojects with limited resources can increase their product value significantly byapplying a formal method for design, if adapted properly.
63
64
References
[1] Karen Holtzblatt, Jessamyn Burns Wendell, and Shelley Wood. RapidContextual Design: A How-to Guide to Key Techniques for User-CenteredDesign (Interactive Technologies). Morgan Kaufmann, 2004.
[2] Kent Beck, Mike Beedle, Arie Van Bennekum, Alistair Cockburn, WardCunningham, Martin Fowler, James Grenning, Jim Highsmith, AndrewHunt, Ron Je↵ries, et al. Manifesto for agile software development. 2001.
[3] Jim Highsmith and Alistair Cockburn. Agile software development: Thebusiness of innovation. Computer, 34(9):120–127, 2001.
[4] Kalle Lyytinen and Gregory M Rose. Information system developmentagility as organizational learning. European Journal of Information Sys-tems, 15(2):183–199, 2006.
[5] Peter Abrahamsson, Kieran Conboy, and Xiaofeng Wang. “lots done, moreto do”: the current state of agile systems development research. 2009.
[6] Ken Schwaber. Scrum development process. In Business Object Design andImplementation, pages 117–134. Springer, 1997.
[7] Ken Schwaber and Mike Beedle. Agile Software Development with Scrum(Series in Agile Software Development). Prentice Hall, 2001.
[8] Kent Beck. Embracing change with extreme programming. Computer,32(10):70–77, 1999.
[9] Jan Gulliksen, Bengt Goransson, Inger Boivie, Stefan Blomkvist, JennyPersson, and Asa Cajander. Key principles for user-centred systems design.Behaviour and Information Technology, 22(6):397–409, 2003.
[10] Mark Hartswood, Rob Procter, Roger Slack, James Soutter, Alex Voß, andMark Rouncefield. The benefits of a long engagement: from contextualdesign to the co-realisation of work a↵ording artefacts. In Proceedings ofthe second Nordic conference on Human-computer interaction, pages 283–286. ACM, 2002.
[11] Marta Kristın Larusdottir. Using rapid contextual design at reykjavik uni-versity. In Inventivity: Teaching Theory, Design and innovation in HCI,Proceedings of of HCIEd2006-1 First Joint BCS/IFIP WG13. 1/ICS/EUCONVIVIO HCI Educators’ Workshop, 23-24 March 2006, Limerick, Ire-land, pages 35–39. Citeseer, 2006.
[12] Inka Vilpola, Kaisa Vaananen-Vainio-Mattila, and Taru Salmimaa. Apply-ing contextual design to erp system implementation. In CHI’06 ExtendedAbstracts on Human Factors in Computing Systems, pages 147–152. ACM,2006.
[13] Mark Notess. Using contextual design for digital library field studies.In Proc. ACM/IEEE-CS Joint Conference on Digital Libraries workshop.ACM/IEEE-CS Joint Conference on Digital Libraries workshop Studyingdigital library users in the wild: theories, methods, and analytical ap-proaches, Denver, CO, 2005.
65
[14] Eeva Kangas and Timo Kinnunen. Applying user-centered design to mobileapplication development. Commun. ACM, 48(7):55–59, July 2005.
[15] Sharon McDonald, Kelly Monahan, and Gilbert Cockton. Modified contex-tual design as a field evaluation method. In Proceedings of the 4th Nordicconference on Human-computer interaction: changing roles, pages 437–440.ACM, 2006.
[16] Arianit Kurti, Marcelo Milrad, and Fredrik Alserin. Contextual designof mobile services to support knowledge workers in library settings. InAdvanced Learning Technologies, 2006. Sixth International Conference on,pages 375–377. IEEE, 2006.
[17] Timothy Hoye and Joseph Kozak. Touch screens: A pressing technology. InTenth Annual Freshman Engineering Sustainability in the New MillenniumConference April, volume 10, 2010.
[18] Roy Want. iphone: smarter than the average phone. Pervasive Computing,IEEE, 9(3):6–9, 2010.
[19] Hugh Beyer. User-centered agile methods. Synthesis Lectures on Human-Centered Informatics, 3(1):1–71, 2010.
[20] Robert K. Yin. Case Study Research: Design and Methods (Applied SocialResearch Methods). SAGE Publications, Inc, 1994.
[21] N. Anand and Richard L. Daft. What is the right organization design?Organizational Dynamics, 36(4):329 – 344, 2007.
[22] Heinrich C Mayr and Christian Kop. A user centered approach to require-ments modeling. In Modellierung, pages 75–86, 2002.
[23] iOS Human Interface Guidelines. Apple, Inc, 2014.
66
List of Tables
1 Variants of Rapid CD. LF and LF+ here denotes the ”LightningFast” and ”Lightning Fast +” methods respectively, and FRCDis ”Focused Rapid Contextual Design”. Gray color indicates thatthe corresponding step is not included in that variant. . . . . . . 7
2 CI interview coverage and structure. . . . . . . . . . . . . . . . . 23
3 Suggested application features, grouped by the six navigationitems designed for the main menu. . . . . . . . . . . . . . . . . . 30
4 Feature dependencies and available back-end data. . . . . . . . . 32
5 Feature implementation priority from fuzzy logic assessment. . . 32
6 Feature implementation risks using XP sorting. . . . . . . . . . . 33
7 The state of implementation of proposed features . . . . . . . . . 38
8 Qualification parameters applied to the case project. . . . . . . . 55
9 Qualification parameters for example project 1, a project teamwith lacking design aptitude. . . . . . . . . . . . . . . . . . . . . 55
10 Qualification parameters for example project 2, a project teamwith poor presence and volatile team composition. . . . . . . . . 56
67
List of Figures
1 Structure of an a�nity diagram. . . . . . . . . . . . . . . . . . . 18
2 Example of the tree of a top-level categorization of a�nity notes. 25
3 Main menu view. . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4 Search & browse view. . . . . . . . . . . . . . . . . . . . . . . . . 34
5 Employee profile view. . . . . . . . . . . . . . . . . . . . . . . . . 34
6 Geographic overview view. . . . . . . . . . . . . . . . . . . . . . . 34
7 Main menu view. . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8 Search & browse view. . . . . . . . . . . . . . . . . . . . . . . . . 39
9 Employee profile view. . . . . . . . . . . . . . . . . . . . . . . . . 39
10 Geographic overview view. . . . . . . . . . . . . . . . . . . . . . . 39
68