UPTEC IT 14 015 Examensarbete 30 hp Oktober 2014
Adapting Rapid Contextual Design for Smartphone App Development
User-Centered Design for Small Teams
Carl Ekman Jonas Martinsson ii Abstract Adapting Rapid Contextual Design for Smartphone App Development Carl Ekman, Jonas Martinsson
Teknisk- naturvetenskaplig fakultet UTH-enheten User-centered design methods may be applied by development teams when creating, rewriting, or Besöksadress: replacing software in a given workplace environment. Ångströmlaboratoriet Lägerhyddsvägen 1 These techniques can give insight into the product's Hus 4, Plan 0 context of use and facilitate requirements elicitation. One common method used when designing software Postadress: applications is Rapid Contextual Design. While popular Box 536 751 21 Uppsala in part due to its modularity and adaptability, the process of how to choose a suitable variant of the Telefon: method shows opportunities for improvement. 018 – 471 30 03 Technology has also advanced significantly since the
Telefax: method's inception, making parts of existing literature 018 – 471 30 00 outdated.
Hemsida: By analyzing each step of the Rapid Contextual Design http://www.teknat.uu.se/student 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
Handledare: Marcus Berner, Marcus Fredriksson Ämnesgranskare: Mats Lind Examinator: Lars-Åke Nordén, Roland Bol ISSN: 1401-5749, UPTEC IT 14 015 iv Popular scientific summary in Swedish
Utveckling av datorsystem eller program som ska anv¨andas av m˚anga olika m¨anniskor kan ofta vara en tidskr¨avande utmaning. Att designa ett system som tar h¨ansyn till alla m¨ojliga typer av anv¨andare, till¨ampningar och f¨oruts¨attningar kr¨aver f¨orst˚aelse av sammanhanget i vilket systemet ska anv¨andas, och p˚agrund av industrins v¨axande fokus p˚amobila plattformar ¨arkrav om anv¨andbarhet st¨orre ¨ann˚agonsin. Ett flertal olika metoder anv¨ands f¨oratt samla denna typ av information inf¨oroch under anv¨andarcentrerade utvecklingsprojekt, varav en av de vanligaste ¨arRapid Contextual Design.
Den h¨armetoden introducerades p˚amitten av 1990-talet och har sedan dess an- passats successivt f¨oratt styra olika typer av projekt, fr˚anstorskaliga banksys- tem till utbildningsplattformar, men ¨arfortfarande m¨arkbart sv˚aratt f¨orena med de agila tillv¨agag˚angss¨att som blir alltmer vanliga. Nu har smartphones banat v¨agf¨oren ny generation av mjukvaruutveckling, d¨aranv¨andbarhet och korta utvecklingscykler ¨aravg¨orande faktorer f¨orprodukters framg˚ang, och p˚a grund av detta st¨alls nya krav p˚autvecklare och projektmetodik. De projekt- grupper som utvecklar mobilappar ¨arvanligtvis mindre och med kortare tidsra- mar ¨anvad metoder som Rapid Contextual Design ursprungligen menades f¨or, men kan ¨and˚adra nytta av en anv¨andarcentrerad metod som gynnar produk- tens anv¨andbarhet. Detta g¨aller s¨arskilt i de fall d˚aprojektet har vaga m˚alvid utg˚angsl¨aget.
Detta arbete har under en fallstudie till¨ampat en anpassad version av Rapid Contextual Design till ett mobilprojekt f¨oratt unders¨oka hur metoden kan kortas ned utan att f¨orlora relevans. Projektet utf¨ordes ˚atNetlight Consult- ing AB i Stockholm, d¨arinternkommunikation mellan de ca. 500 anst¨allda skulle f¨orb¨attras genom en mobilapp och samtidigt gynna kunskapsdelning och n¨atverkande. Genom att planera en anpassad projektfas f¨oranv¨andarcentrerad design baserat p˚atekniker och moment i Rapid Contextual Design kunde en projektgrupp p˚atv˚apersoner ta fram en konkret kravspecifikation och slutligen realisera en fungerande applikation p˚atolv veckor.
Unders¨okningen resulterade i en upps¨attning riktlinjer som kan anv¨andas av projektledare f¨or att hitta ett s¨att att inkludera en anv¨andarcentrerad designfas i sitt smartphonebaserade projekt, samt r˚adom vilka moment som kan utel¨amnas under vilka omst¨andigheter f¨oratt korta ner processen eller e↵ektivt anv¨anda begr¨ansade resurser.
v vi Acknowledgements
First of all we the authors would like to thank our reviewer, Mats Lind, for his guidance and advisement during the course of the project.
Next we thank our two supervisors, Marcus Berner and Marcus Fredriksson, for their enthusiasm, commitment and support from day one all the way to the finish line. We would not have reached the result we managed to attain if not for their assistance.
We would also like to show our due appreciation for examiner Lars-Ake˚ Nord´en, assisting examiner Roland Bol and coordinator Olle Eriksson for their time.
Finally we want to thank Emma Rangert and Anders Steinrud for their insights, encouragement and critique.
vii Glossary
Agile refers to a family of development methods that place emphasis on func- tionally working releases developed iteratively in working sprints, making implementation flexible and accommodating to sudden changes in specifi- cation. 1, 6, 9, 20, 21, 29, 61, 63 Android is an operating system used on mobile, touch screen devices (Android phones, Android tablets, Android wearables) and is created by Google Inc.. 28, 50 App is a colloquial short for application, referring to the often light-weight native programs available for smartphones. viii, 1, 2, 8, 9, 11, 13, 15, 24, 27, 28, 30–33, 35–38, 40, 41, 43–47, 49–52, 56–59, 61, 62
CCell or Competence Cell, is a group of employees at Netlight who share a common interest or expertise, wherein which seminars, talks and work- shops may be organized to promote knowledge sharing. 12, 13, 25, 26, 29–31, 36, 37, 41, 49 Client Netlight Consulting AB. 2, 9, 11, 15, 21, 23, 24, 26, 27, 29–31, 33, 38, 40, 41, 49, 50, 55 Customer is a company hiring the services of Netlight. 2, 11, 30, 32
End-user refers to any of the concrete persons intended to use the actual prod- uct, distinct from the abstract term ”user” which could be anyone who interacts with the app. 1, 2, 6, 8, 15–17, 19–21, 24, 28, 29, 31, 41, 43–45, 49–58, 61
IOS is an operating system used on mobile, touchscreen devices (iPhone, iPad, iPod) created by Apple Inc.. 13, 21, 27, 28, 31, 50, 51, 58
Knowledge sharing is the activity through which information, knowledge and expertise is shared across a community or group of people; it is a central theme in knowledge management, which is prevalent in many modern business strategies. 12, 25, 29, 33, 37, 49
Scrum is an agile development framework based on delivering functional 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 Thesisstructure...... 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 Smallteams...... 7
2.5 Relatedwork ...... 8
3 General method 9
3.1 Approach to research questions ...... 9
3.2 Data gathering through process application ...... 9
3.3 Casestudystructure ...... 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 Previouswork...... 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 Workmodeling ...... 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 CarryingouttheCDstudy ...... 23
6.1.1 ConductingCIinterviews ...... 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 Implementingtheappdesign ...... 33
6.3.1 Appstructure...... 33
6.3.2 Employeeprofiles...... 36
6.3.3 Knowledge sharing ...... 37
6.3.4 Networking and overview ...... 37
6.3.5 Pilot product app ...... 38
6.4 Implementationschedule...... 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 Casestudyreflections ...... 49
8.1.1 Planning ...... 49
8.1.2 Execution...... 49
8.2 Qualityofresults...... 49
xiii 8.2.1 Project results in relation to client requirements . . . . . 49
8.3 Evaluating UI and UX ...... 50
8.4 Methodanalysis ...... 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 and Jonas Martinsson as part of the M.Sc. program in Computer and Information Engineering at Uppsala University, supervised by the Department of Informa- tion Technology. The project was done during the spring of 2014, from the 20th of January through the 11th of June, commissioned by Netlight Consulting — an IT consulting firm based in Stockholm, Sweden.
The management of Netlight wanted to better utilize the smartphones carried by their consultants, in order to improve communication and knowledge sharing across the quickly growing company. This project was conceived as an attempt to investigate how this could be done in the form of an app, and how such an app should be designed to best address the needs of the end-users.
Contextual Design (CD) is a user-centered design process for developing appli- cations and interfaces that will be used by a known group of end-users. The design process is based on collecting data by surveying the usage context of the application, and then from there using a series of process steps that among other things incorporate contextual inquiry, visioning and prototyping in order to design a system interface. CD is described in detail in section 5.1.
1.2 Purpose and research questions
The main question this thesis sets out to answer is: how can Rapid Contextual Design be adapted for agile smartphone application development in small teams?
The contextual design process, introduced in 1992, has evolved alongside tech- nological progress, and many di↵erent versions of the process is used today in di↵erent types of software development projects. [1] This study’s aim was to examine CD’s potential in the contemporary smartphone app development in- dustry, specifically considering that the core methods in CD have not changed much since their inception, and the prospect of using certain tools in the process may have become more feasible than earlier. This lead to the following research questions:
how applicable are CD and agile development methods when designing • and developing new smartphone applications?
how can a core team of two people best adapt the CD process to suit their • limited resources?
are modern, digital prototyping tools viable replacements or complements • to the conventional paper prototyping process?
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 project client’s needs for a smartphone application for internal communication and knowledge sharing purposes. The requirements are met with a functional pilot product based on a strongly motivated set of features compatible with a long- term scalable outlook. The resulting app should at least be able to serve as a prototype or proof of concept for continued development.
It is the hope of the authors that the work presented in this thesis could be a starting point towards creating an adapted version of the rapid contextual design process for smartphone application development using agile methods in small teams.
1.3 Limitations and scope
As this was not a development-oriented thesis project, not all the details regard- ing actual implementation were covered. Some notes were made on the database structure and model-view-controller (MVC) pattern used to give an overview of the system.
Scalability and sustainability, in terms of responding to a major increase in the number of end-users, have been underlying themes throughout the entire development process, but reworking the client’s back-end systems to ensure any kind of measurable scalability in performance was too large an undertaking to be included in the scope of this project. Instead, attention was directed towards more interface-related factors, to ensure that the usability of the app would not be impeded by any increase in users during the international expansion the company is currently undergoing.
Ideally, the app developed during this project would have integrations for the client’s many business systems and databases, as well as for external sources of data and services. Such integrations introduced di culties for implementation that would have consumed unexpected amounts of time. Instead features like these were to be presented on a conceptual level with suggestions for further added content and what likely implications these would have on the system.
This communication tool was meant for internal communication between 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 of research has been introduced, the scope of thesis has been defined and the research questions have been declared. The next section, 2 Related theory and literature review, contains relevant theory and reading material regarding the subject matter.
2 In section 3 General method the method used to answer the research questions is defined, while the following three sections (4 Project case, 5 Design and devel- opment methods and 6 Design and development results) describe the case study this method is applied to.
Section 7 General results lists the results that correspond to the method de- clared in section 3, based on the data acquired through the case study in sections 4-6. These results and findings are then processed and discussed further in sec- tion 8 Discussion. Finally in section 9 Conclusions and future work conclusions are drawn and recommendations are made about the adaptation of contextual design.
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 of developing software based on non-changing plans. The Agile Manifesto, written in 2001, details how its authors sought to introduce Agile as a better way to develop software than had earlier been done [2]. The key principles of Agile can be described as follows: to be able to respond to changes in software development projects instead of trying to prevent them, while realizing the value in working software and people as opposed to documentation and processes [3]. Developing products iteratively is also a core concept.
Lyytinen and Rose [4] claim that agility in software development projects is achieved in di↵erent ways depending on the nature and setting of the project. This means that strictly following one method, such as Scrum or XP, is not necessarily the best option. Following one method gives the benefit of increased structure, but may also cause unnecessary amounts of overhead. The latter is especially true in projects of short length with a small scope and team.
Abrahamsson, Conboy and Wang hold that while research on Agile development has come far, there are still shortcomings in the amount of research done and how agility is defined [5]. This is supported by their claim that the development of Agile has mostly been driven by practitioners in industry.
Sections 2.1.1 and 2.1.2 describe the two agile methods drawn from in the de- velopment phase of this project.
2.1.1 Scrum
Scrum teams work in iterations that are one to four weeks long [6]. There are three main roles involved in the process: the Product Owner, the Scrum Master and the Development Team. The Product Owner represents the stakeholders and is in charge of prioritizing the work. The Development Team is a cross- functional team of up to 9 members. The Scrum Master is responsible for ensuring that the Development Team follows the Scrum process and that the team is able to fully perform their work [7].
2.1.2 Extreme Programming (XP)
XP shares many of its basic goals and activities with Scrum. It di↵ers in that iterations are typically shorter, one to two weeks, and in that it has defined programming practices [8]. These practices include pair programming, contin- uous integration, test-driven development, and on-site customer. Having an on-site customer means that an actual end-user should always be available for questions.
5 2.2 User-centered design and methods
Gulliksen et al. [9] define user-centered design (UCD) (also called user-centered systems design) as:
”a process focusing on usability throughout the entire development process and further throughout the system life cycle”.
The authors also present twelve key principles, upon which the definition is based: user focus, active user involvement, evolutionary systems development, simple design representations, prototyping, evaluate use in context, explicit and conscious design activities, a professional attitude, usability champion, holistic design, processes customization, and a user-centered attitude should always be established. Especially interesting is processes customization; that there needs to be a defined UCD process, and that this process needs to be customized to the environment in which it is used. This is considered further in section 2.5.
The same authors bring up a few points about the applicability of agile methods when working with user-centered design. They contend that some of the core concepts of agile are well-suited for user-centered design projects, such as the focus on face-to-face communication and the general focus on people of processes and tools [9]. Conversely, the emphasis on producing working software can quickly diminish the focus on usability.
The work of Gulliksen et al. considers the Scandinavian tradition of actively involving end-users in the design process, which makes it a fitting starting point for this thesis.
2.3 Contextual Design
Contextual design (CD) is a user-centered design process method introduced in 1992 by Karen Holtzblatt and Hugh Beyer, founders of InContext [1]. CD breaks down the design of a new system or tool into a manageable sequence of procedures to facilitate formulating a concrete system concept. It di↵erentiates itself from other design processes by specifically analyzing the environment and context in which the end-user performs the tasks that the system will a↵ect, and covers the early stages of design—requirement elicitation, workplace studies and end-user interviews. The pre-implementational design phase is divided into a chain of discernible steps, which are individually described in sections 4.1.1 through 4.1.5.
CD is today often used in conjunction with user-centered agile methods, which cover the later stages of development and testing. As the process is intended for practical and real situations where time and resources oftentimes are limited, its modular nature makes it flexible and adaptable to a great variety of projects. In Rapid contextual design [1] the core process is provided in three configurations (all more lightweight than the original CD process) from which one can choose: Lightning Fast (one to four weeks), the most light-weight and compact form of
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 this project. FRCD is slower than any of the Lightning Fast versions, but includes every step of the CD process. Table 1 shows a summary of the configurations explained above.
Rapid CD Process LF LF+ FRCD (1-4 weeks) (4-8 weeks) (6-10 weeks) Contextual Interviews 4-12 users 6-12 users 8-12 users with Interpretation Sequence Model with Consolidation A nity Diagrams Wall Walk and Visioning Storyboarding Paper Mock-up Interviews 4-9 users 6-12 users with Interpretation
Table 1: Variants of Rapid CD. LF and LF+ here denotes the ”Lightning Fast” and ”Lightning Fast +” methods respectively, and FRCD is ”Focused Rapid Contextual Design”. Gray color indicates that the corresponding step is not included in that variant.
The CD team is described as consisting of at least two out of three core roles: the designer, someone experienced in interaction and visual design; the work practice professional, who has insight into the environmental context of the system design; and the developer, a technological professional [1]. While two of these should be working full time, it is advised to include the third as a part time helper.
2.4 Small teams
This thesis defines the term ”small teams” in the context of software develop- ment as a group of fewer than five developers, where the roles normally applied to project teams are harder to establish. Members of small teams usually have to assume responsibility for multiple parts of a project, such as requirements elicitation, design, development and testing. More importantly, small teams would typically have di culties in assimilating resources and conducting some steps of the design processes discussed in this thesis.
In smartphone application development, teams are in practice small by this definition, since teams ranging from one to three developers per platform are commonplace.1
1The sizes of smartphone application development teams are not well documented aca- demically, however contemporary industry practice revolves around small core teams (game development being an exception, where team size varies dramatically). Quantitative Software Management, Inc. have published a number of studies on the subject of small development
7 2.5 Related work
Researchers have found that using contextual design can both increase quality of developed products [10,11] and ease adoption of new products because of the insights gained into targeted users’ workflows [12]. The parts of CD dedicated to data gathering and analytics have been found especially useful in software development, while other parts are conversely in some contexts considered not as useful [13, 14]. Most if not all who apply CD modify or expand the method to better fit in their respective scenarios [10, 12, 13, 15].
The application of CD to smartphone app development has not seen much attention in terms of research. Much of the research available [14,16] was made before the introduction of the iPhone, which radically changed the environment for smartphones and the complexity of applications for them [17, 18].
Notess [13] used contextual design to guide the design of a digital music library. The author did not use all steps of the process; only Contextual inquiries (CIs), work modeling and consolidation. Notess does not reach any conclusive results in terms of the applicability of CD for their specific scenario, but is positive towards further exploration of the use of CD for similar projects. This work is related to ours in that the author did not use all aspects of CD as they are described in the literature. They rather saw the universal worth of gathering contextual information from the end-users’ actual work environment and then only utilized the remaining steps of CD partially. Otherwise Notess used pro- cesses already in place. The main di↵erence from the project case described in this thesis is that Notess’ aim was to create a product that supports an existing workflow, contrary to creating an application that is supporting some existing communication flows and introducing some functionality that is completely new.
Vilpola et al. [12] applied contextual design when implementing an enterprise resource planning system. The authors concluded that the introduction of CD into the development process improves the quality of the system’s usability, and helps ease the contextual change to the newly developed system compared to if it had been developed with less insight into the end-users’ work context. This relates to the project case described in this thesis in that it also introduces a new system for retrieving information regarding a company and its employees.
In the main Rapid CD literature, the two primary parameters considered when choosing between the three di↵erent forms of the process are time and scope [1]. This leaves opportunities for investigating potential other parameters that could be of importance when making this decision, as well as adapting the process to take these parameters into consideration.
One of the co-creators of CD, Hugh Beyer, has presented ways to combine the CD process with agile development methods [19]. This literature covers how to adapt Scrum and XP workflows to incorporate CD, but the author does not consider the value, if any, of also adapting the CD process to agile development methods. teams in general, stating that smaller teams show higher e ciency and lower costs. More information 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 smartphone design and development project, directed by a team of two members, from start to finish. A case study is the preferred strategy when the focus of the research questions are formulated as ”how” or ”why” [20, p. 9]. The choice to perform a case study was further motivated by the notion that this type of method is suitable ”when the focus is on a contemporary phenomenon within some real-life context” [20, p. 13].
The case, which is described in full in section 4, required the construction of a pilot app. It was also reasoned that an implementation would help the vision stay alive, and prompt the client to continue implementing it. While CD would be well suited for dealing with the design phase of the project, the team would need to carry out development in order to fully follow up on the case. The development phase of the case would be performed according to a combined version of agile development methods, which would build upon the CD results according to the transition procedures discussed by Holtzblatt et al. [1] and Beyer [19].
3.2 Data gathering through process application
During the case study each step of the CD process was evaluated, and notes were taken on which parts worked well and which parts did not. This was done in order to evaluate the applicability of CD to smartphone development projects in small teams, investigating both individual steps and the method as a whole. The project was divided into two major phases, each six weeks in length and together encompassing the entire design and development progression from idea to realized working concept app.
The study was designed to produce qualitative results, based on explorative data derived from the user-centered method adaptation. The goal was to study the CD method in light of current industry technology and procedures, more specifically that of agile smartphone app development, and see whether adjust- ments can be made to help small teams steer clear of potentially avoidable steps while still gaining insight for design.
3.3 Case study structure
The case study approach is detailed in sections 4 through 6. The results of the study are presented in section 7 and analyzed in section 8. In section 9 the conclusions on how CD can be adapted to better suit projects similar to the project case are discussed further.
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 undergone rapid 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 a variety of customers’ o ces, mainly in the Stockholm region. Since the number of new hires per year has increased consistently, the company’s management has been looking to develop tools that would make it easier to contact employees, and also make consultants’ skills more accessible to co-workers. This would make it easier to find assistance on a peer-to-peer basis and facilitate putting together teams for new projects.
4.2 Objective
The objective as presented by the Netlight management was the following: take internal communication to the next level using smartphone technology.
This has been a vague objective, and in order to reach a solution it was first necessary to identify and investigate how employees communicate, as well as what di culties were experienced in workplace routines. Using CD to conduct a design pre-study to elicit requirements was well motivated in this case, since the aim was vaguely specified and the client was seemingly unaware of the concrete company needs. Examining these factor were necessary in order to produce a concept of an improved future workplace.
The goal of this project was to deliver a working pilot product as a proof of concept of the design produced through the use of CD. The pilot product did not need to be fully implemented, but should convey the functionality of the app.
It is worth mentioning that while there exists commercial o↵-the-shelf services that would satisfy some of the requirements found during the case study the client had already opted for a custom solution, exploring the possibilities of an in-house mobile app.
4.3 Communication and organizational structure
Netlight has its employees organized in a network structure. This is a modern form of organizational structure that is based on social network theory, and regarded as more flat [21] than classical hierarchical structures, in that it is more decentralized and flexible, allowing direct peer-to-peer communication between employees from di↵erent parts of the company.
11 Netlight is divided into four departments: Operations (Accounting, IT, First Impression, HR), Management, Sales (Engagement Search (ES), Talent Search (TS)) and Consultants. Members of all departments communicate freely with each other.
There currently exist a number of options for peer-to-peer communication within the company. In addition to email and telephone contact information available on Rebel, the company information wiki, there is an extensive social chat sys- tem, Yammer 2. This system is reminiscent of a generic social network site, with most of the features related to such services. It also contains the CCells, where employees may create groups devoted to or interested in certain fields. Yammer is used for both formal and informal communication, focused on sub- jects ranging from spare time interests to knowledge enrichment activities for productive teams. Aside from Yammer, most internal communication is done through Skype3.
4.4 Competence cells and knowledge sharing
Developing talent and expertise among its employees is one of Netlight’s highest priorities. Thus, tools have been created to promote knowledge sharing. This agenda is manifested in the form of CCells and EDGE. The former are group initiatives driven by employees themselves who want to either learn about a specific subject, or teach others about it. Many of these CCells are focused on technology or business, but there are also CCells for casual hobbies and spare time interests. The organizers of CCells have resources supplied by the company at their disposal for holding seminars, talks or lectures.
EDGE is an initiative that summarizes the ways in which Netlight employ- ees maintain, develop and share current valuable knowledge and competences. There are EDGE seminars that educate interested employees and new recruits about new technologies and development techniques, as well as EDGE Academy which is held on evenings during one week of each year and may include specially invited guests.
Knowledge sharing and talent growth are deemed important to the continued success of the company, and so creating an information technology basis for them has been an underlying focus of this project.
4.5 Company growth and expansion
While currently having a physical presence in Stockholm, Oslo, Helsinki, London and Munich, expansion to multiple new countries is being planned as branch organizations throughout northern and western Europe. This means that any
2Yammer, Inc. is a freemium enterprise social networking service that was launched in 2008 and sold to Microsoft in 2012. 3Skype is a freemium voice-over-IP service and instant messaging client, currently devel- oped by the Microsoft Skype Division.
12 application being developed must ensure scalability and maintainability so that it can grow with the company. Because of this there are also challenges regarding internationalization.
4.6 Previous work
A year prior to the start of this project, an attempt was made to produce a solution to the problems described in section 4.1. The result of that project was an iOS app called Koala, where the user could search for and view infor- mation about employees and customers. Information about the location of an employee had to be provided by that employee themself, through a check-in feature which required that they were present at the location at the time of action. The app could also access information about which project a given con- sultant was attached to. The customer information consisted of company name and country. Koala had its own back-end, where information about employees and projects was retrieved from Netlight’s enterprise research planning (ERP) system and then cached. The back-end was taken down at some point in time after the departure of the developer, which caused the app to no longer function as intended. Koala is no longer maintained.
In 2013, the CCell for mobile platforms collectively developed an iOS app called One Netlight, where the user could browse Netlight employees by name and see their photo and telephone number. One Netlight got its data by scraping the employee directory wiki page. When some part of a page changed in layout however, bugs got introduced which made the app practically unusable. These bugs were never fixed.
Another tool created in 2013 was Net-CA, a responsive web interface created for both desktop and mobile browsers, that allows the sales department to quickly find available consultants. The employees can be filtered and sorted according to skills, experience and earliest available date. Contacting the consultants in question cannot be done through this interface. Net-CA is developed and maintained internally. The sales department enters information about each consultant into the application’s back-end database (which also gathers data from the ERP system), so the consultants themselves typically do not interact with the system directly.
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 between February 10 and March 21 2014, with the intent of mapping the requirements of a communications app that would assist the employees and management of the client both currently and for the foreseeable future. The application of CD to this project was mainly motivated by its compatibility with the characteristics described in the 2004 publication Interactive Technologies: Rapid Contextual Design: A How-to Guide to Key Techniques for User-Centered Design by Karen Holtzblatt, Jessamyn Burns Wendell and Shelly Wood [1]. Many fundamental prerequisites for conducting a CD study were deemed compliant with the nature of the project—such as having a core team of two people, preferably a designer and a developer (formally taken on by Ekman and Martinsson respectively). However, Holtzblatt et al. recommend that the third role (in this case the workplace practice professional) be included to some degree. The duties of the third role were shared by several available stakeholders—mainly the two project supervisors, both being experienced technical consultants.
The version of CD chosen for this case was the Focused Rapid CD (FRCD) approach, which is the most demanding and inclusive alternative provided by Holtzblatt et al. in their publications of the Rapid CD method [1]. In contrast to the other versions suggested (Lightning Fast and Lightning Fast +) it has not been stripped of any steps in the design process, but instead usually requires considerably longer execution time. It was reasoned that a thorough use of the method in its entirety would give the project results a strongly motivated foundation that would add the most value to all parties involved. In this chapter the abbreviation FRCD will be used when detailing the steps of the method. Note that some of the steps are present in other versions of CD as well.
Although FRCD was the most fitting approach for the project, the parameters were picked to allow for a lightweight execution in as short a timespan as possi- ble. This was due to the influence of two factors: the sparse number of helpers available at the client’s headquarters, which limits the number of possible inter- viewees and consequently the interpretation of that data; and the time required to attain a significant state of completion before deadline of the thesis project.
5.1.2 Contextual inquiries contextual inquiry (CI) is the part of FRCD where user data is collected, which serves as the basis for further discussion. The ideal scenario is to perform two- hour interviews with a set of end-users in their natural work environment. In this context, “interview” does not mean eliciting answers to a set of written questions during normal dialogue. The idea is instead to watch the end-user
15 carry out their daily work routine, and to make notes of how they solve problems or tasks. The interviewer will occasionally interpose questions to clarify certain actions or to ask the interviewee how they are reasoning. In some regards this is more similar to a set of job shadowing procedures than interviews.
Finding the right interviewees require analysis of the system context. The num- ber of interviewees that can be accommodated depends on the type of function the system will perform, and how many job roles are present in this context. Then choosing which sample roles are to represent the user base must be done carefully so that the results from the survey will fairly a↵ect the direction of design. Thus it is also important to remember to look for relevant di↵erences and likenesses between candidate interviewees when sampling the end-users.
If the interviewer notices that it is unlikely the interviewee will run into situ- ations that would provide data relevant to the FRCD process, the interviewer has the ability to collect retrospective accounts of previous activities. These ac- tivities should not be more than two weeks old. When collecting a retrospective account, the interviewer asks the interviewee to walk the interviewer through the event by repeating the actions as they were done the first time. If the inter- view has to take place outside of the actual work place, e.g., for confidentiality issues, the interviewer will have to rely on retrospective accounts.
It is preferable for the interviewer to take notes on paper, both to be able to follow the interviewee around should it be necessary and to not seem excluding by looking at the monitor when typing.
5.1.3 Contextual inquiry interpretation
To analyze and organize data from the CI sessions, the FRCD team meets for interpretation sessions. Interpretation of CI data should happen within 48 hours of completing the interview, to make sure that it is still fresh in memory. Present at this session are the FRCD team members and any possible helpers.
There are several roles in an interpretation session. The interviewer reads their notes from the CI interview and the note taker constructs notes based on the input from all team members. Additionally there can be any number of general team members present, one of which can also be responsible for creating work models (explained in section 5.1.4). If the team is bigger than the standard of two members, there can also arise a need for a moderator. This person is responsible for keeping the interpretation discussion on track.
The first step of the session is to create user and organization profiles. Each interviewee is represented by a code instead of their name, to keep their identity confidential. The profiles describe characteristics of the users and organizations; such as age, years of experience and size of the organization. The interviewer uses the profiles to introduce the organization and user to the interpretation team. After capturing the profiles, the interviewer presents either a photograph or a drawing of the physical workplace the interview was conducted at, to help the participants contextualize the interview information.
16 When walking the rest of the team through the interview, the interviewer goes through their unabridged notes and recollections. The session participants in- terrupt and ask questions to elicit deeper insights from the rest of the team. If any of the participants notice any information they think constitutes a key idea for the interview, they call for it to be captured. The note taker writes all of these key ideas down. In FRCD, these are known as 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 ideas or further questions for the interviewee these are also written down. They are however not discussed at this session, since the design comes at a later stage in the process and questions should be directed at the person who can answer them. If the interviewee has said anything during the interview that can be used later as a quote to highlight a certain issue, this is also captured. While the interviewer is going through their material, one of the participants captures the sequence model, which shows the steps the user takes to complete tasks.
The last part of the interpretation session is capturing insights, which are high- level observations made when summarizing and reflecting on the interview. In- sights are used to communicate key findings from the interpretation session to stakeholders and other interested parties.
5.1.4 Work modeling
Work models provide di↵erent views on the structure of how end-users conduct their work, and are drawn during the interpretation session. Two of the standard CD work models, the cultural and flow models, are not a part of the rapid variant of CD [1] and will not be described here. The three models used are as follows.
The sequence model is a detailed step-by-step description of either an observed event or a retrospective account from a Contextual Inquiry interview. Together with the actual steps themselves, triggers are captured to show what situation made the user decide to take a specific step or start working on a new task; and intents are captured to identify the reasons behind a step or task. If the user experiences an unexpected problem, this is marked as a breakdown.The sequence models are consolidated, as described in section 5.1.6, to show common patterns between di↵erent users.
The physical model is a depiction of the physical environment, including the objects in it, where the user does their work. It can show how the workspace is used and how it is potentially a↵ecting the user.
The artifact model is a copy or portrayal of any object that the user creates, uses or references to complete a task. The aim is to capture how the object is structured, how and when the it is used and with what intents.
When the work models are completed, some aspects of them can be used to write additional a nity notes. Breakdowns and intents are captured for all models, 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 that need to be addressed in the resulting design. The diagram is built from the a nity notes written during the interpretation sessions. Where each contextual interview highlights the key issues and work structure of an individual, the final a nity diagram is a tree structure that can be used to gain higher-level insights and show the hierarchical relation of these. In preparation for this step of the FRCD process, all a nity notes need to be put on pieces of paper that can be put on a board.
Constructing the diagram starts with getting all the a nity notes up on the board. Notes relating to a common observation are put in a column together. If a column gets too big, meaning it has more than around six notes, it generally shows that there are other distinctions in it that can be broken out into its own column. When all notes are either in a column or discarded for not fitting into one, the columns are combined into higher-level observations. The resulting groups are then divided into top-level ideas that complete the tree-like structure of the finished diagram. All note groups have a description written in the voice of the end-user, to make the FRCD team consider the observations from the users’ point of view.
Figure 1: Structure of an 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 between columns, 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 able to enlist helpers to assist in building the a nity diagram, the time needed to complete it can be shortened substantially; especially the first phase since it is closer to being linear in nature than later phases.
5.1.6 Consolidating models
FRCD involves capturing three work models, but only the sequence model is consolidated. The physical and artifact models are kept as auxiliary resources. The Lightning Fast and Lightning Fast + versions of CD do not include model consolidation.
18 Sequence consolidation includes looking at tasks from di↵erent people where all have di↵ering triggers, intents, steps and breakdowns. The idea is to show abstract underlying steps common between people doing di↵erent tasks with di↵erent intents and experiencing varying breakdowns, and can therefore be used to design functionality that is useful in more than one job role.
The result can then be used to redesign current ways of performing a task, or supporting the task in a new system. Sequence consolidation is preferably done in groups of two, but the first consolidation should be done with the whole group to establish a common understanding of how the process is going to work.
The first part in consolidating the sequences consists of choosing the three that are most central to the work, while also being detailed enough and having overlapping steps. Then the triggers for each sequence are identified. Sequences are comprised of a number of steps, and sets of steps that can combined into a higher-level action aiming to accomplish a certain intent are noted as activities. This is done for all of the three sequences. The activities have their own intents, which need to be identified. When looking through the steps of an activity, abstract versions of them are created if they are used by more than one person. A consolidated activity consists of an intent and abstract steps to achieve it. A consolidated sequence consists of consolidated activities.
5.1.7 Constructing personas
End-user personas represent the major job roles of the user base, and are con- structed from the body of a nity notes and interview material gathered previ- ously during the investigation. This part of the CD process is only included in FRCD. A persona does not describe a single person interviewed, but rather a combination of attributes from all users in common job roles and with common needs. Personas have a one-page description that summarizes who they are and what they do. The description includes goals, tasks and roles. Goals are high-level accomplishments that the persona tries to achieve, or tries to sustain over a period of time. Tasks are discrete pieces of work that can be attributed to the persona. Roles described in the text are the di↵erent responsibilities the persona has in their daily work.
Personas provide the core team and stakeholders with more context, which is useful when considering the design. With more tangible knowledge about the users the FRCD project is going to support, the more informed decisions members and stakeholders of the FRCD team can make.
5.1.8 Walking the 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, sometimes referred to as the wall walk. FRCD suggests that the team should have a dedicated room where they can have keep all relevant progress visible on the
19 walls for all who are interested in following it. Walking in this context means to go through all of the collected data to create a systemic understanding of it. This is important for keeping all stakeholders up to date on the project.
Walking the data can leave results in three di↵erent ways: design ideas, holes and questions. Participants may come up with not only features they see the project being able to provide; but also strategies, concepts and implementation possibilities. These are collectively referred to as design ideas. Instances where the 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 expose expectations 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 information that is present but may need to be investigated further.
5.1.9 Visioning
To start the creative process of coming up with solutions to the problems and challenges outlined by the previous steps, a visioning session should be held. These meetings are supposed to generate a conceptual vision of what the future workplace or context of use will be like when the project has been completed, not necessarily restricted by any of the technological constraints that may apply during actual implementation. The sessions are done in groups of no more than ten, but should include as many of the stakeholders as possible. If development is agile, then it will most likely benefit from a common vision shared by both developers and owners.
The visions themselves consist of large hand drawn pictures that depict the future, as altered by the project result, from the perspective of the intended end-user. The visions are high-level, without much implementation or user interface (UI) details. However they should not be vague, and ought to produce a set of usable user stories based on the tasks in the sequence models. Ideally the meeting will produce several visions which can then be compared, analyzed and consolidated into a single, finished vision that comply with most of the requirements construed from the investigation results.
5.1.10 Prototyping and final design
The last steps of the FRCD method is constructing and testing the final design through prototyping. First the storyboards and visions are walked in order to reiterate the functionality the design should support. Then brainstorming and hand drawing of UI elements start, producing a multitude of approaches and angles to addressing the features. These hand drawn prototype UIs are preferably made on paper in the interest of time, as each new design is likely to be reworked very soon. Fast and informal evaluations of the early prototypes are made, scrapping the unfavorable versions and keeping promising UI layouts and metaphors.
20 Construction of wireframe UI models begin once the paper prototypes resemble the finished product. These wireframes are often not hand drawn, but are still printed and cut out on paper and are intended for formal user testing with manually interactive elements. Paper prototype interviews are then held where representative usability testers are given tasks to accomplish in the new UI. These interviews may di↵er, depending on whether the project is a refinement of an existing system with experienced users or a completely novel invention. The point of the interview is to identify poor usability or ine↵ective design metaphors so that the UI can be iterated and improved before development.
Once the prototype wireframe UI has been iterated enough times to produce a reliable and promising interface that can support all the wanted features from the storyboards, a final requirements specification for implementation may be written 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 to ensure 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 as Scrum and XP—especially in user-centered software projects where the end-user should 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 Git 5 on the company’s private GitHub6 profile. Locally the versioning was controlled with SourceTree7 in conjunction with the built-in capabilities of Xcode.
In order to be able to access the client’s ERP systems any device running or simulating the application would have to be connected to the company virtual private network (VPN). For this the application Tunnelblick 8 was used.
4Xcode is an IDE created by Apple Inc. used for any and all native development for Apple’s operating systems: iOS and OS X. 5Git is distributed revision control tool and software distribution management system initially designed by Linus Torvalds of Linux fame. 6GitHub is a Git-oriented online service and portal for source code management and distribution, often used by—but not limited to—open source projects. It is available on http://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) were interviewed at the client’s Stockholm o ces. These ten interviewees would through their work habits and job roles provide insight into the company’s communication structure — what communication and knowledge sharing tools are used, and how they are used by the employees. Conducting two CI interviews simultaneously were done in the interest of time, since two FRCD team members were available.
The work groups to interview were: External Consultants, who are working o↵-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 divided as follows: Consultants, two external and two internal (two of them senior and two of them junior); Sales, both TS and ES as before; Operations 1, consisting of one employee from FI, and one from HR; and Operations 2, with one from Accounting and one from Internal IT. See table 2 for a summary.
Consultants Sales Operations 1 Operations 2 CI 1 External x2 ES HR Accounting CI 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 regular interviews with a sample of these, but after working hours.
Interviews with Operations 1 and 2 were carried out first. This was in part due to higher availability, but they were also chosen first to avoid making any beginner mistakes on the valuable consultant as an interviewer. This was followed by the interviews with sales, and then the consultants — which were harder to schedule meetings with. As the two intended interviews could only be performed on- site, two supplementary interviews with experience consultants were scheduled at a customer’s o ces in Stockholm. Another supplementary interview was conducted with a recently hired external consultant who had never been posted at Netlight headquarters, as they had been assigned an o↵-site project on the first day of employment. The purpose of these supplementary interviews was to acquire insight into the working conditions of employees that are geographically secluded from company headquarters, and in what ways their experiences di↵er from consultants on internal projects.
23 The interviews were held at the desks of the interviewees during normal work conditions. Generally they were conducted before lunch, starting around 10 AM and 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 about the use of tools and software, communication norms and personal preferences regarding communication and use of available applications. All the while the interviewees were encouraged to show their process instead of simply retelling it, as is promoted by the FRCD principles. When the interviews were nearing their ends the interviewer began the wrap-up process, which constitutes quickly going through the notes and summarizing the interview to ensure a correct and fair comprehension 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 a secluded room. These sessions were held without the use of helpers, because of practical reasons – there was simply not enough time to adapt the sessions to the schedules of other stakeholders, who also had limited insight into and understanding of the methods used. This case, where only two active project members were present, also meant that not all of the recommended roles to be present were necessary. Instead, the interviewer examined their notes from the interview, and systematically retold the observations that had been made. Thus, the interpretation sessions resulted in a list of a nity notes for each interview accompanied by artifact notes, insights, design ideas and observed or retold sequences (which are further labeled as triggers, intents and breakdowns).
Per FRCD protocol, certain sequences should be noted from each interview that detail 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 of the sequences observed were peripheral and probably had very little influence on the needs that could be satisfied by a smartphone app. For example, many sequences detailed regular job role duties, such as answering email from internal sta↵, co-workers or external parties. While some email correspondence with internal sta↵could be relevant to the context of designing the app, the usability of an email client is far beyond the scope of this project. This lead to a more general level of inspection during the interviews, as the interviewer was trying to discern the overall communication paths and tools that together make up the internal information infrastructure of the client, while still capturing low level details such as specific use cases of existing tools, frustrating work activities and personal 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 gathered from the interpretation sessions were checked for relevance to the scope of the project. Notes that covered problems, observations and insights strictly outside
24 of the project scope were discarded, and all other observations were written down on sticky notes according to recommendations from Holtzblatt et al.
The paper notes were then organized into smaller categories based on the type of requirement the observations related to most strongly. When categories grew too large and inclusive they were taken apart and divided further into more explicitly detailed ones. When the groups had reached su cient sizes between three 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 categorization was made which resulted in three main groups of observational data. These were: Networking and overview, Employee profiles and Knowledge sharing. All other category notes were written in the form of a statement made from the perspective of the end-user, both on first and second levels, such as “As a user I want to be able to do X”. One of the top-level groups is described below in figure 2.
Knowledge sharing
Ifeellike Knowledge-sharing is participating in central to problem solving CCells is important for and personal growth. cultivating my skills. I want to share I want to be I want better I want to stay my knowledge. able to find insight into what updated on the someone with a CCells do and discussions in certain skill set. how to join them. the CCells I follow.
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 and overview, Employee Profiles and Knowledge sharing. These three correspond to the chief areas of concern within the project’s universe of discourse [22]. The employee profiles branch dealt with the need for end-users to be able to look up contact information of co-workers in various scenarios, the knowledge sharing branch contained all notes related to CCells and other knowledge-sharing activ- ities, and the networking branch held all observations related to a big picture approach 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. Before moving on to visioning and storyboarding though, the a nity and interview data was draw upon to build personas. Three distinct personas were decided upon: a mid-level o↵-site consultant with two years of experience, and a strong presence on Yammer and in the competence cells; a slightly more junior sales agent with previous business experience and varying degrees of participation in di↵erent social and professional groups and cells; and an operations employee who prefers using team communication tools like Skype as opposed to Yammer which he felt was more directed toward the consultants. The personas consisted
25 of one page of composite descriptive material each, supplemented by a stock photograph conveying a fitting personality.
6.1.4 Visioning seminars and storyboarding
A visioning session was held together with stakeholders and end-users at the client’s o ces in order to build the vision based on the a nity diagram. The three main branches of the a nity diagram were one by one presented and discussed. Three visions were created on whiteboard, each somewhat interacting with the others, that detailed how future users would be able to interact in the context of the workplace. The session led to omission of some planned features (e.g., reminders of seminars), and inclusion of new ideas into the final consolidated vision.
Some improvisation with respect to the session structure had to be made that deviated from the formula suggested by Holtzblatt et al. The main problem was 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 that were interested in the project. A rather large group of people attended the seminar, 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 held with internal IT and consultants working on other internal projects, as well as product owners of the various back-end systems at the company. It turned out that most of the data that the vision called for would be available from one or more of the database systems or their middleware interfaces, but there was some concern regarding a number of the intended features.
The most troubling features from a back-end standpoint were those related to browsing, viewing and joining CCells. This was simply because there was at this time no centralized portal for CCells. Di↵erent services, such as Rebel and Yam- mer, were used to view CCells. The information available from these resources is however not always up to date. E.g., there are no common conventions for how CCell leaders inform the members of upcoming meetings. This information can be spread either through the email list, through Exchange calendar invites to all members or by posting on Yammer. This means that someone trying to view when the next upcoming meeting is will perhaps not be able to find this information without asking a member of the cell. Similar to the above not all competence cells keep their information on Rebel updated, resulting in a lack of insight 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 the exclusion of competence cell functionality from the prototype.
Other data that is hard to obtain is the work location of o↵-site consultants and a 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 not necessarily the same as the address of the place where the consultant is stationed. For the prototype, customer locations were randomized within Stockholm city limits. The addresses for Netlight o ces were available however, which meant some employees’ locations could be shown correctly.
Skills and expertise are only available from consultant r´esum´es, 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 r´esum´es are also not standardized enough to allow for reliable scraping. This data would be available by soliciting it from the users, and from LinkedIn should the user accept it.
6.1.6 Choosing online wireframing over paper prototyping
The standard way of designing user interfaces (UIs) in FRCD is by using paper prototypes first, and then continue on to more detailed wireframes and mock- ups. In this project, the first step was skipped and instead Flinto9, an online prototyping tool for smartphone apps was used. That way focus could be on more high-level design cues in favor of low fidelity structure and navigation lay- out (which was deemed suitable for standard industry design patterns). The literature discourages this and suggests that starting prototyping on paper is preferable [1]. The authors’ arguments for this are grounded in experiences with projects that are di↵erent to an extent that warrants revisiting the motivations behind 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 was started directly. With the requirements for the prototype in place, the UI design was started. To begin, the storyboards were walked to identify what UI com- ponents were needed in the resulting system. Ideas for these components were brainstormed using a whiteboard, on which all parts of the UI were connected. With the user experience (UX) flow of the system written down, wireframe blueprints of the UI could be created.
The wireframes were created as mockup images, with screen dimensions and UI elements corresponding to iOS heuristic standards [23]. In order to reinforce the fact that this prototype was not an actual finished design – let alone actual implementation of the system – it was given a blue color scheme that did not adhere 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 Nathan Manousos and Kazuho Okui, available at http://www.flinto.com
27 full coverage of the product vision. The thought here was that in the event of an unfinished implementation of the app, that would probably entail focusing on a single group of features in depth, there would be a complete and tangible model of what was left to build.
The wireframes were created in Adobe R Photoshop R 10 and assembled in Flinto one view at a time. Most UI elements could be made according to conventional design norms and rules, but a few of them had to be iterated and informally tested by users. The presence of the Flinto prototype on a real physical and interactive 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 was that 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 proved too 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 further discussed 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 or surface was of course easier to manage, while making a more serious and realistic impression on the user. Since the users were able to handle the prototype like a real app – with exception to some interaction techniques like swiping and pinch- ing – the experience was made more realistic, and natural interaction with the system could be observed from an end-user’s perspective. However, the speed of interaction was an unanticipated increased which made it harder to take notes of the users’ actions. Interrupting the interaction test was also inadvisable to some extent, as the users’ true actions and reactions were desired.
Another aspect of the interviews that changed was time consumption, which was often reduced to less than ten minutes for a complete walkthrough of the app and its functions. This stood in stark contrast to the two hours of testing recommended in FRCD, which for all intents and purposes seemed unnecessary in this instance. However, the allotted time was enough to elicit exhaustive interactions and comments in all interviews.
10Adobe R Photoshop R is a graphics editing desktop application developed and distributed by 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 phase can be found in section 6.3.1. However, as a means of motivating the strategic decisions made in this section, the main feature groups that were designed from the three branches of the a nity model (Employee profiles, Knowledge sharing and Networking and overview) will be briefly outlined. These feature groups are 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 task being executed, in accordance to the recommendations by Beyer [19, p. 41]. They were all written from the perspective of the end-user, beginning with the phrase ”as a user. . . ”. They were written on such a detail level that they each conveyed the need for a distinct and delimited application feature. The stories were collected and organized in Trello11. In total 40 user stories were derived from the vision. The collection of user stories was handled as a backlog of features in preparation for the agile implementation phase.
Once the FRCD design phase had been concluded, its collective material was reviewed to ensure consistency and then compiled together with descriptions and instructions into a final concept specification document. This document was then handed over to several departments and CCells at the client during preparations for the development phase. The motivation here was twofold: first it was meant as an opportunity for feedback and discussion with the client, to check if the vision and design had succeeded in correctly addressing the client’s needs; 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 possible use of the classical roles traditionally employed in agile development methods. Another limiting factor was time remaining, which meant that only short sprints or 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 Search 1.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 Favorites 2.1 View and Control Lists mentor, team members and favorites. 2.2 Model The data structure representation of a bookmarked employee. 3.0 Events 3.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 Overview 4.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 CCells 5.1 Browsing CCells Lists the all the CCells 5.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 Settings 6.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 items designed for the main menu.
30 As such decision the decision was made to not strictly adhere to one formal method, such as Scrum or XP. Instead central themes from both methods were borrowed while other themes that were not considered as appropriate were omit- ted. Development would be done in Scrum-like sprints where work would be based on a backlog of user stories. Neither the Scrum Master role from Scrum or the Product Owner role from Scrum or XP would be formally used, instead the 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 touched upon by keeping the supervisors informed of prioritizations and demonstrating new app functionality as soon as possible. Input from the supervisors helped with prioritizing user stories, as they could help give a better understanding of the amount of work needed to complete certain user stories from a back-end perspective.
Since the time frame of the project was relatively short, there was no opportunity to incorporate the use of XP’s velocity or Scrum’s burndown rate to predict the work capacity for each iteration.
In the last iteration, the XP idea of a programmer’s holiday was utilized to ensure product stability and that the project would be prepared to hand over to 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 implemented during 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’s ERP 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 the prospect of focusing attention to that feature was judged too risky, in the interest of time. Secondly, while implementing the event feature seemed promising, it was noted that it required some level of critical mass in terms of end-user adoption in order to function as intended. This was simply not possible since the app would only be implemented for iOS.
Focusing on this particular group of features was too much of a gamble, since the 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, as illustrated in table 4.
31 In addition to this the geographical Overview feature was a liability, due to location data not being available for customers or projects. This feature also depended heavily on projects and employee profiles already being implemented in the app (see table 4).
Feature Feature Data Comment dependencies availability 1.0 Search 1.1 Employee profiles – Partially Skills missing 1.2 Project profiles 1.1 Partially Address missing 1.3 Contact info 1.1 Available 1.4 Add to favorites 1.1, 2.2 Local 2.0 Favorites 2.1 View and Control 1.1, 1.2, 1.4 Available Mentors, teams 2.2 Model – Not available 3.0 Events 3.1 Browsing events 1.1, 3.2, 3.3 From scratch 3.2 Creating events 1.1, 1.4, 2.2, 3.1, 3.3 From scratch 3.3 Manage responses 3.1, 3.2, 3.1, 3.2 From scratch Critical mass 4.0 Overview 4.1 Current location – Available 4.2 Display o ces – Available 4.3 Display customers 1.2 Not available Address missing 4.4 Display projects 1.2, 4.2, 4.3 Partially Address missing 4.5 Display employees 1.0, 4.2, 4.3, 4.4 Partially Data is derived 5.0 CCells 5.1 Browsing CCells – Not available Deprecated 5.2 Detailed info 1.1 Not available Deprecated 5.3 Joining CCells 5.1, 5.2 Not available Deprecated 6.0 Settings 6.1 Download data – Available 6.2 Universal contact 1.3 Available 6.3 Lunch roulette 1.3 From scratch 6.4 LinkedIn sync. 1.1 Partially If feasible 6.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 risk and value definitions from XP. Table 5 below displays risks and table 6 on the following page shows priorities.
Search Favorites Events Overview CCells Settings Di culty Medium Low High High High Medium Value High Low Medium Medium Medium Low Risk Low Low High High High Low Priority High Medium None Low None Medium
Table 5: Feature implementation priority from fuzzy logic assessment.
32 Search Favorites Events Overview CCells Settings Completeness 00 21 21 Volatility 00 21 20 Complexity 10 22 10 Risk 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 app navigation layout. No time would be spent on UI design, although as much as possible of the basic UX structure. The user stories chosen to primarily work on 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.In this iteration work would also begin to refine UI elements and graphical de- sign. At this point during development real data should be used, instead of placeholders.
The third iteration would entail wrap-up work on the prioritized Employee profile features. Given that there is enough time, some e↵ort to finish the Overview and networking features would be aimed for, although above expecta- tion. No time would be spent on the Knowledge sharing features, due to missing data in the back-end databases. Polishing UI and preparing for distribution is included 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 presents the user with a list12 view of all of the client’s employees and projects. The user can switch between viewing employees and projects by tapping a button. For projects, the list elements contain customer and project names. For employees, the elements show a photo of the employee, their name, current job role and project, and a list of their main skills. For projects, the elements contain the name of the project, the name of the customer, the main areas of expertise involved in the project and how many Netlight employees are assigned to the project.
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 shown at the moment.
Employee profile shows a list of information for a selected employee. This list contains name, C-level13, photo, job role, current and past projects, workplace address, availability (e.g. on vacation or parental leave), mentor, mentees, skills and expertise, personal description and what Netlight o ce they belong to. The profile also contains an embedded view of a map showing the workplace address of the employee. Tapping the map takes the user to the Overview feature. Tapping any other employee, being either the mentor or any mentee, takes the user to that employee’s profile. Tapping any of the current or past projects takes the user to the profile of that project.
The view has a button that when tapped shows a drop down style list containing the employee’s contact information. In addition to showing the information, tapping the list items initiates either a phone call, sending a text message or sending an email depending on which item is selected.
If a user navigates to their own profile, an edit button takes the place of the contact information button. Tapping this button lets the user edit their de- scription as well as skills and expertise. They also have the option to reorder the skills in the order they want them shown to other users.
Additionally, the employee profile contains a button for adding the employee to the user’s phone address book and a button for adding them to their Favorites list in the app.
Project profile details a certain project. The information in this view consists of the customer name, project name, workplace address, a description of the project, the current team members, past team members, the main employee skills 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 mentor and team members are always present, but the user also has the ability to add any 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 to create new events. Events can be any kind of activity involving more than one person. An event list item has a location, a time, a title, photographs of invited employees and the option to leave comments. Unanswered event invitations have two buttons beneath them, one for accepting and one for declining. A number representing 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 the Events 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 with ES, TS and consultant job roles have C-levels.
35 title, location and time for the event. By tapping an invite button, the user can use a modified version of the Search & Browse function to find employees to invite. Tapping a list item adds an employee to a multiple selection. Instead of the employee/project filter, the user can filter employees based on they belong to the user’s team or if their workplace is nearby.
Overview presents the user with a map containing annotations representing employees. These annotations are clustered together depending on their relative proximity on the map. E.g., with the map fully zoomed out, each Netlight o ce would be represented by one annotation. Conversely, each annotation in a fully zoomed in map would represent all employees at one address. Annotations contain the number of customers and the total number of employees at that location. Tapping an annotation shows a list of the employees working at that location, each leading to their respective employee’s profile.
CCells shows a list of all CCells, with name and a descriptive image. Tapping a list item takes the user to the profile for that CCell.
CCell profile contains information about a CCell. This information includes the 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 the CCell, 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 takes the user to that employee’s profile.
Settings contains a list of options other features. The user can disable showing their 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 another employee. The paired users are notified via a push message, and can then proceed 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 in several ways. The information presented in employee and project profiles are all relevant to the end-users in di↵erent ways. Subsets of the information are available in other internal systems, but these are only used by employees in some 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 the Favorites feature both address this issue. Since Search & Browse is the initial view of the app, the user can directly search for a name. The Favorites view takes 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 a set 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 are listed, their current project (for consultants) or job role is always visible. This information 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 those employees currently on the project.
6.3.3 Knowledge sharing
”I feel like participating in CCells is important for cultivating my skills” – 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 to find the CCell’s email address and send a request. The app also makes it easier to get an overview of the activity in CCells, by collecting them in one place and listing their meeting times together with summaries of what was discussed during past meetings and what topics are going to be discussed during future meetings.
”Knowledge sharing is central to problem solving and personal growth” – Knowledge sharing is the basis for many of the features in the app. Users have easy access to both the knowledge of colleagues and the collected knowledge of CCells. Colleagues can be found both based on what project they are on and what skills they have. The integration of CCells gives the user the ability to easily find multiple colleagues with knowledge in one area, and also gives them the opportunity to get involved in the activities of the CCell. Users can also utilize the Events feature to create knowledge sharing sessions based on their skills and expertise.
6.3.4 Networking and overview
”I want the existing systems to be used to their full potential” –The app is making existing information more visible and easier for employees to consume. What was previously only available for some employees gets collected in one place.
”I want to feel like I’m a part of Netlight as a whole” - Through most of the above mentioned features, the app helps employees expand their picture of Netlight. With the Overview feature, employees get a more spatially com- prehensive understanding of the presence of the company. Using the employee profiles together with the list in Search & Browse, users can more easily get a sense of who all employees are. Seeing the names of employees together with their picture also makes them easier to remember.
”Meeting people in person is important to me” -Bysimplifyingthe process of getting in touch with colleagues, providing an easy way to sched- ule meetings and enabling users to identify nearby colleagues, the barriers for choosing 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 were not implemented at all. See table 7 below.
Feature Implemented Partially Implemented Not implemented Search & Browse x Employee Profile x Project Profile x Favorites x Events x Overview x CCells x CCell profile x Settings x Lunch 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. The user interacts with these models through view controllers representing features or parts of features.
The back-end is written in Java, and is based on the structure of other internal Netlight systems. It handles the collection and exposure of data. Some details about employees, such as their photo and contact information, are retrieved from the 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 intention to have it replaced with an actual user authentication process as soon as the client approves the use of the live AD with the app. Also, synchronization of employee and customer data is initiated manually. Users are reminded once per week 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, industry standard application protocol for accessing and maintaining distributed directory information services 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 vital parts of feature group 1 implemented (see table 3) – being able to search among employees based on names, search among projects based on clients, viewing em- ployee profiles with placeholder information as well as project profiles containing dummy data. The data structures needed for this feature group were to be fully implemented 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 FRCD phase, with the team member previously designated as designer focusing on front-end, and the developer on back-end. These roles were informal and only lived on as a practicality since those areas were where each team member felt most comfortable and had the most prior experience.
Setting up the development environment was finished quickly, in part due to the low overhead of the team only consisting of two developers. Some parts of the system architecture was established with the use of CocoaPods17, in order to quickly set up basic functionality such as network connectivity. Using Co- coaPods meant that more time could be spend implementing application specific features over platform formalities.
During the early stages of the first iteration no real data from the client’s ERP systems were used. Instead dummy data and placeholder images were used to construct the first version of rudimentary UI layout. Halfway through the iteration access to the ERP systems was granted and the app could be populated with actual data, managed locally through the use of Core Data18, and on server- side by custom software written by the project supervisors. The connection between the two was based on a REST API 19 written in collaboration with the supervisors.
Toward the end of the iteration user portrait photos were integrated, along with the finished feature for employee and project searching, and functionality for directly contacting employees by calling, texting or sending emails from the app.
In summary the iteration was executed according to plan, even being slightly ahead of schedule. This was due to the help provided by the supervisors with back-end development, which would otherwise be outside the scope of this project.
17CocoaPods is a directory for open source Objective-C libraries and external dependencies to 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 Mac OS X and iOS operating systems. 19Representational state transfer (REST) is a software architectural style, most commonly using 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 progressed faster than anticipated. Since feature groups 1 and 2 were well underway and using 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 features can be found in section 6.3.1).
During this part of implementation the UI was styled according to the client’s branding guidelines, and an e↵ort was made to improve on visual aesthetics and presentation. To this end animations were used to convey navigation cues, and a 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 for feature group navigation. Also, mentorship connections were fully implemented and project data connections to the correct employees was troubleshot. Many features proved di cult to implement during this iteration since much back-end data, although accessible, turned out to be in worse condition than estimated during the design study. This prompted changes to data management and presentation.
This iteration was more challenging than the previous, and while work was still ahead of schedule that advantage had been reduced somewhat. In terms of backlog progress, velocity was reduced during the iteration, mainly due to increases in development complexity.
6.4.3 Iteration 3
When the final iteration began it was decided that no more features would be implemented. Instead during these last two weeks work would be oriented toward 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 being published on Rebel, the company wiki. The app was presented and tested on- site at client headquarters by end-users. Preparations for publishing the app on a private enterprise server were made together with members of the mobile development CCell.
All in all the development phase resulted in a product above expectation, but still 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 Rapid CD were included. It was found that most parts of the process are applicable for smartphone app design and development, a few are not as suitable, and that some would benefit from modifications.
Contextual Inquiry and interpretation - the contextual inquiry portion of Rapid CD was the one that proved most valuable, as could be expected. The quality of the data gathered in this step was very high, especially compared to the hypothetical case of a standard question-based interview. Through in- terpretation many valuable, and sometimes unexpected, insights were gained regarding the needs of the company employees.
One of the common needs identified for o↵-site consultants were a fast and easy way to spontaneously plan lunches and lunch meetings for nearby colleagues. This lead to the inception of the event feature in the system vision. Perhaps most importantly the interviews provided a thorough insight into the inner workings, systems and structures of the company, which helped motivate later design choices.
Data consolidation - Work models and artifact models did not prove very useful 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 with the fact that most of the end-users often switch desks, lead work models being disregarded. The sequences captured did not lead to any sequence models that were 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 this particular 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 written on sticky notes. The diagram had to be manually assembled and disassembled on a large, movable whiteboard for each a nity diagram construction session.
Some digital representation of the a nity diagram would perhaps have been preferable in the interest of time, but the act of physically moving, grouping and rearranging the paper notes while discussing them was experienced by the team as both helpful and pedagogical. The constant interaction with the physical notes made it possible to digest, understand and remember the observations from the CI interviews better. Additionally, the clearly visible and accessible whiteboard 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 involved and were able to get their voices recognized. Not only was this step important from the viewpoint of user-centered design by creating the foundation for UX, but it also provided an excellent opportunity for technical feedback and pointers since many of the attendees were working on internal projects and systems. Being able to discuss feature ideas with technical personnel otherwise uninvolved was a great opportunity for constructive criticism and design.
The event was advertised toward a wide group of employees, and snacks were served during the meeting in order to both attract attendees and keep the energy level up during the later hours of the workday. The authors would advise other groups applying this process step to do the same, in order to promote a positive, creative and casual atmosphere where attendees could freely voice their thoughts.
The resulting consolidated vision (drawn on whiteboard) also functioned as an inclusive and complete high-level interaction map from which all storyboards were consequently created. The exercise of consolidating the partial visions was perceived as a very rewarding and important aspect of UX design. As with the a nity model, the whiteboard on which the consolidated vision was drawn was available for anyone at the o ce to look at.
Storyboarding - While the storyboarding sessions were a good opportunity for UX design and were an e↵ective way of processing the consolidated vision in terms of concrete system interactions, the app being designed was perhaps a bit too small in scope to really benefit from the storyboard design in the long term. In retrospect only the backlog items constructed from the storyboards were actively used during the development phase.
The vision consolidation session was perhaps more productive for a project of this 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 storyboards are easier to explain to stakeholders or a larger group of developers.
However, for the small team and relatively small product in this project the storyboarding could reasonably have been diminished to direct backlog entry writing based directly on the consolidated vision. The team of (front-end) de- velopers did not change during implementation, so no new people had to be introduced to the UX storyboards. In the case of a longer development cy- cle and a changing set of team members, having storyboards on hand would probably have been a good investment.
Product and system requirements - The process of gathering technical specifications and evaluating back-end resources was a much longer process than what could be scheduled for a day or two of the design process. This was because of practical circumstances, such as technical personnel and authoritative persons being scarcely available during working hours. Therefore these meetings had to be 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 team alone – 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 part of walking the a nity model and consolidated sequences, they did not prove especially useful during this project. This was mostly because the majority of involved personnel were employed by the client—and thus already well versed in the variance of job roles there. They did however help consolidating the big picture of the system’s end-users, and did bring light to some questions about job roles, which brought further insight into the client company.
Paper prototyping - As described in section 6.1.6, paper prototyping was skipped in favor of digital prototyping. Though testing and demonstrating more high-level design concepts of the app was easier by using digital prototyping tools, a lot more e↵ort had to be placed in producing images early on. This was 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 and iterated a few times on whiteboard.
Prototype interviews - Overall, the prototype interviews did not turn out as planned. Instead of carefully laid out paper models being thoroughly walked through over long interview sessions they were mostly quick demonstrations of the app concept shown on a smartphone. The user would typically go through most features without needed intervention, only pausing to give design feedback or pose questions about a specific feature and how it would work. While this deviates from the Rapid CD guidelines it was in retrospect much more appro- priate to the nature of the product. Performing usability tests using generic UI elements outside the context of an actual platform seemed detrimental to the progress of the prototype.
7.2 Rapid CD for small teams
Rapid CD is constructed with a core team of two people as the model. The expectation is that the team has access to other individuals, referred to as helpers, 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 mostly consultants busy working on projects of their own. For the visioning seminar however, there was an opportunity to assemble a number of helpers.
Had it been possible to enlist the help of more client employees, more valuable input 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 was consistently slightly ahead of schedule. This is likely due to the smaller scope of 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 prototyping tools. 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 good fit 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 what was planned without having to make use of lower-level language features that would potentially increase the di culty of development. This, together with the fact that the development environment takes care of a lot of the overhead that could be present when developing for other platforms contributed to the ease with which the app could be incrementally developed.
The agile method used was a combination of general agile principles, as well as principles and practices from Scrum and XP. The end results worked very well for the situation in this project. A summary of what was incorporated from existing methods is shown below.
General
iterations - the development phase was divided into three iterations, each • two 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 the • stories being worked on during a particular iteration were stored on a sprint backlog.
roles - the role of ScrumMaster was not used, but together with the • project supervisors the development team did take on the role of product owner. More preferable would have been if there had been a stakeholder available 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 code and to help get through that particular piece of work faster.
refactoring - code was refactored to increase readability and performance • whenever possible, and especially in the last iteration when preparing to hand over the app to the client. customer always available - in this case the thesis project supervisors • could be considered the customer. They were always available for feedback and 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 decision made early on. It was mainly motivated by the time requirements stated by Holtzblatt 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 only a pilot app or proof of concept (POC) would be delivered to the client.
One mistake was not allocating quite enough time for post-implementation follow-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 more helpers to contribute. This would still not be guaranteed, since the consultants at 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 later stages of the design phase the time allotted for certain steps intruded on each other, but no deeper issues than that were experienced.
One thing that could have been added would be smaller UI evaluations at the end of each sprint, to see if there were any tweaks that could have been made to the design. This would have required some planning and thought into in how to 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 cial events. First at the visionary seminar during the design phase, then twice for the Mobile 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 feedback and discuss the features of the app. This lead to the end-users feeling at least somewhat 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-user group largely underrepresented since they embody the majority of employees.
Certain stakeholders, such as supervisors, mobile developers and internal project managers, were much more involved in the process during both design and development. These interactions mostly took place in the form of meetings and interviews. This was important since it was always desired to stay on the right track, and not overlap with other internal projects and use the most relevant data and tools accessible.
The cooperation between developers and end-users through Rapid CD proved fruitful – the project resulted in a design that seemed to address the issues currently experienced by the client well. The study also pointed out some discrepancies and concerns both in terms of the quality of internal databases and social mechanisms in the company, nothing critical but areas of possible improvement. Most of these issues were in some way addressed by the app concept, while others (such as missing or flawed back-end data) restricted the progress of the implemented app and thus prompted further inspection of these details.
At the end of the project the collected work was handed over to the client, and steps were taken to ensure that the project would live on through continued development for iOS as well as Android. Enthusiasts and developers commented on the usefulness of the app, even in its current state of implementation, and emphasized 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 evaluation of the developed UI, in order to estimate the end-users’ ability to understand and use it. The conceptual design had already been evaluated with the end- users during the prototype interviews, in the form of demos and open-ended interviews, which were a source of subjective data. However, the prototypes were only drawn as wireframes with limited UI elements and graphical design. The final implementation could therefore had been evaluated more thoroughly with methods like cognitive walkthroughs20 or formative evaluation21.Whether or not a formal study would yield outcomes of practical or academic value was uncertain, since the app was only a partial implementation of the concept.
20Cognitive walkthrough is a usability inspection method where interfaces are evaluated based on their usability by letting representative users ”think aloud” while using the interface to complete specific tasks. 21Formative evaluation is a usability inspection method used during evolving stages of system design in order to assess usability or performance by rating representative users’ actions based 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 were some discussion regarding the use of a side menu instead of a tab bar for basic navigation, but the decision to use a side menu was strongly motivated by the fact that five items is a recommended maximum for an iOS 7 tab bar while the app design called for six. Another case was the semi-novel features in the custom map implementation, where clustering was used, as well as callout views in the form of table views. While unconventional, they were not found to violate any 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 A to employee B, and then from employee B to employee C,pushingnewviews on the same navigation stack. However, there is nothing stopping employee C from being equal to employee A, which may lead to something of a loop. The same goes for employee profiles and project profiles. While this is considered an intended feature when navigating to new employee profiles, the navigation stack will grow if the user tries to navigate backwards without using the designated button, which may lead to an unintuitive UX pattern when popping the views from the navigation stack for backwards navigation. Whether or not this fea- ture can be avoided without introducing additional unexpected and unintuitive behavior remains unclear. It should be noted that the same problem existed in a previous attempt at an internal communications app (see the Koala app in section 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 to five core team members23, and development cycles are seldom longer than a few months between releases. Even simpler apps may be developed and released within a couple of weeks, but whether or not these short projects require a design pre-study is arguable.
The FRCD team in this case study consisted of two core members—perhaps the method would have been altered di↵erently if this had been a larger smartphone development team. In any case the FRCD method calls for two or three des- ignated roles. In a larger development team those unassigned these roles may act as helpers during many of the method steps. In the case of a single-person design team the applicability of Rapid CD may be compromised, since many of the activities are based on gathering and digesting end-user data in pairs.
22Heuristic evaluation is a usability inspection method where interfaces are evaluated based on their compliance with a set of recognized usability principles, or heuristics,foraparticular platform or interface type. 23It should be noted that some apps require a great deal more workers, e.g., games and graphics-heavy applications. However, not all of these artists and engineers are included in the 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 app project 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 usually best done one sprint or iteration ahead of development. In small projects this normally 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 fact remains – 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 the usability of the app can be somewhat ensured. Novel UIs however may require explanation or tutorials.
8.4.2 Applicability of Rapid CD
The application of Rapid CD to this project was in the end successful, but some parts 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 given additional time, depending on the team’s conditions.
There are many factors weighing in on the team’s decisions when planning and choosing 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 internal constraints 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 detail in 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 key purpose of Rapid CD is gathering end-user data. The process as a whole can be used by any project that requires a more fleshed out usage context for the desired product, even if no technical development is involved. It is also preferred for projects with a small scope and well-defined job roles.
The defining characteristics for the project case were first of all that while the base of end-users was well known, very little was known regarding requirements, end-user needs, usage context, pre-existing systems, or project goal. This alone means that the project would certainly gain from some adaptation of Rapid CD. In addition to this the development team was small, its time frame was relatively short (about three months), there was little risk of core team members quitting or being replaced, only a few stakeholders would be actively involved, there would be no designated development room or workspace, the team had reasonable 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 a span of six months, Rapid CD was chosen. There are many more design methods
52 with considerably longer time requirements, but Rapid CD was designed in 2005 to cater to the needs of projects with smaller scopes. The six week long focused rapid contextual design (FRCD) version was chosen in order to allow for 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 design planning, the decision between them is mostly based on the team’s relationship to 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 will refer to a project with both relatively short time duration (not more than six months) and limited scope (developing only for one or two platforms, and with a workload that matches the duration). A more detailed set of metrics will now be defined, from which a project’s compatibility with certain aspects of Rapid CD can be measured for small projects. These four heuristic qualification parameters 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 large scopes. Large teams are more prone to replacements, but the consequences of a missing team member are less dire.
A typically strong team in terms of cohesion is a team composed of around two to four core members with prior cooperation experience and good chemistry, preferably in a small project with short duration and limited feature scope. A team with poor cohesion would consist of either too many or too few members in relation to time and scope, and where there is risk of members not being able to work full time during the length of the project. Team cohesion may a↵ect the applicability of almost all Rapid CD steps, but in particular contextual inquiry 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 with stakeholders and end-users, preferably by having an on-site room or workspace suitable for wall walking. Presence is a two-way channel of communication be- tween the core team and stakeholders. Poor team presence may just as well be caused by stakeholder unavailability as by the core team. Presence is also implicitly based on openness and team member communication skills. Team presence 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 and skills. It depicts how experienced the team is, and how many areas of expertise the core team covers. A strong team aptitude means that the team’s capability for good design and development is adequate, and that the core team members can 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 given time. The interplay between a team’s cohesion and aptitude a↵ects the team’s chance of success. If the individual members of the core team are skilled in all necessary areas but lack cohesion, the amount of scope implementation possible during 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 and skills. It depicts how accessible necessary expertise and aide is to the team, and how much the team depends on it. It also includes how accessible and defined end-users are. Having strong team resources means that the team is able to acquire anything it needs from the stakeholders, end-users, or external parties upon request. Good team resources can compensate for poor aptitude, meaning that having graphical resources available on-site may o↵set lacking a designated designer.
Team resources relies on team presence, and can only be utilized fully if presence is strong. If the team has access to plenty of assistance but lack presence, the amount 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 strong throughout the project. Both core team members were able to work full time, and cooperation worked well – according to expectations. While time was fixed by 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 was deemed appropriate for the project, and overall the impression of this parameter has been solid.
In contrast, the team presence during the project was lacking. The distance between the team members’ living areas and site location demanded a rather long daily commute (2.5 hours round trip). This lead to the site only being visited on average four days per week during the design phase, and only one to two days per week during development. Also there was no dedicated room available 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 able to 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 alleviated the situation. The areas perhaps not as strongly covered were those related to the client’s particular back-end systems. However, due to scope delimitations and 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 technical advice needed was within reach. The body of end-users was well defined and easily approachable, meaning that the contextual inquiry portion (the founda- tion for every CD study) was made easier to perform. The two thesis project supervisors were very helpful and proved a good aid in back-end development where access was restricted. The positive attitude of involved stakeholders had a 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↵ected the ability to perhaps fully access the resources. In summary the profile of the case project is illustrated in table 8.
Parameter Poor Lacking Adequate Fair Strong Team cohesion x Team presence x Team aptitude x Team 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 example projects, and illustrate how they may guide method considerations. All projects here are defined as ”small” in nature, with timespans less than six months and teams with five or fewer members. In table 9 a fictitious project group that lacks experience in UX and UI design is depicted. However, they have abundant resources, a designated project space, and are able to be highly present during the design study. Thus the project team would do well in focusing attention and allocating time for meticulous prototyping, preferably with paper models initially, and designing in multiple iterations. Emphasizing personas, wall walking, storyboarding, prototype interviews, and UI iteration would likely be considered advantageous.
Parameter Poor Lacking Adequate Fair Strong Team cohesion x Team presence x Team aptitude x Team resources x
Table 9: Qualification parameters for example project 1, a project team with lacking design aptitude.
55 Another, more complex example is given in table 10. Here the team composition is volatile. Due to the time and scope of the project, not all members will be able to fully attend the planned design phase. Also, the team must be located remotely from the usage context of the product app. Luckily, the team’s external resources are strong, and the body of end-users is well known with significant pre-existing user data. The external resources available compensate for the poor team cohesion and as such the overall aptitude is fairly una↵ected.
In such a scenario the team ought to review their primary parameters: time and 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 ensure high usability. Another red flag is that the team may be eluding themselves as to how much assistance they may be able to gain from their resources, due to their poor presence. If their end-user data is solid, they may be able to omit stages like persona creation. But personas are part of the wall walk, which may be important in the case of team member replacement.
Parameter Poor Lacking Adequate Fair Strong Team cohesion x Team presence x Team aptitude x Team resources x
Table 10: Qualification parameters for example project 2, a project team with poor 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 be used 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 entire experience is broken down to core components, crudely represented by pieces of paper. This has a number of advantages for redesign. For starters, the tester will not be distracted by visual design factors but focused on structure and functionality. [1, p. 248]. Furthermore the tester will not be able to rely on tacit preconceived notions, misconceptions, or user experience (UX) flaws that may have been present in the previous system.
Paper prototyping has other appealing properties as well. Very little time is needed 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 separate pieces of paper, meaning that UI elements may go missing, break or get confused with other elements by accidents during interviews.
56 There is also an overhead that grows with the size of the system, slowing down or causing intermittent interruptions during interviews. Holtzblatt et al. recom- mends acting out these problems with excuses of technical di culties, such as a temporarily slow server. [1, p. 264] But they also emphasize careful prepara- tions, so if handled properly physical prototypes should have low overhead and pose low risks for the project team, and is imperative when trying out novel design 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 would start prototyping with digital wireframes directly they run the risk of wasting time on inappropriate features, miscalculated or untested UI or UX sketches, or otherwise unwanted parts of the design. However, it should be noted that digital 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 between sketch and product.
8.5.2 Prototyping in this particular project
There are several factors that lead to the use Flinto over paper prototypes in this project, despite the advice given by Holtzblatt et al. [1, p. 248] The main consideration was that there was only enough time allotted in the project plan for one round of prototyping, due to the conflict between using as many steps as possible of the highly inclusive FRCD process and only being able to do this in a six week time span.
Other factors weighed in on the choice to omit physical prototypes. Firstly the smartphone platforms have a relatively small set of design elements, which in their basic forms are standardized and well-known for users on the particular platform (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 much larger 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 move parts of the UI before going on to create a wireframe of the whole system. In the case of using Flinto, this simply becomes a case of switching an image for another and redrawing a few connections. It would also not be unreasonable to assume that online wireframing tools available at the point in time when the literature was written, ten years before the writing of this thesis, were not as well suited for quick changes in architecture as Flinto and its contemporaries.
Thirdly, using Flinto to conduct the prototype interviews it is possible to see the user interact with the system in a way that closely resembles how they would with the actual app. This becomes possible because of the fact that Flinto wireframes can be interacted with in most ways possible on a smartphone and can be launched and viewed on the user’s own device. Prototype interviews will also 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 latest version available. Giving a user access to the wireframe is just a matter of giving them 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 this case 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 standard UI for iOS apps. This was also a driving motivation for skipping the paper prototype phase, as what stood to gain from testing low fidelity sketches on technological professionals seemed insignificant when there was already a good understanding of how to design such a UI according to industry practice.
Thus the limited time available, together with the predefined and delimited body of UI building blocks provided for developers, and previous experience led to the conclusion that paper prototyping in this case could be left out in favor of more in-depth use of modern digital tools. However, despite these advantages of digital prototyping some problems – both unforeseen and anticipated – arose during prototype interviews and testing.
As described in section 6.1.7, during the interviews some testers were oblivious to 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 questions of whether or not prototypes can be too realistic, and what adverse e↵ects may be 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 paper streamlined and facilitated some aspects of the process, while slowing down others. For example, creating full wireframe mockups of every view in the envisioned app and then updating them based on feedback was more demanding than sketching them on paper. Other consequences of digital prototyping as opposed to paper models was that moving UI parts could not be done on the fly during 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 method encompassing prototyping the authors recommend that they are well acquainted with producing graphical wireframes and mockups, as well as designing UX processes for the platform in question, before they should abandon the paper step. They should neither attempt this if the system is large (as in containing many features, views or use cases), or is used by a highly inhomogeneous base of end-users.
Distribution and thus demonstration was drastically sped up with the use of Flinto, facilitating the process of showing stakeholders and end-users visions and ideas in a real context. But while Flinto provided functionality for receiving instant user feedback this feature was never used, since it was argued that it diverged from the user-centered core values of the project. The feedback that
58 was processed was instead that which was gathered directly from the prototype interviews, where users could be seen interacting with the app and their opinions could 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, many of the modern digital tools (such as Flinto) are significantly easier to manip- ulate, organize, layout, test and distribute than wireframe images alone. This places modern digital prototyping as a complement to the traditional paper- wireframe-mockup design process. There are trade-o↵aspects to every project however, 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 Rapid Contextual 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 designing • and developing new smartphone applications? how can a core team of two people best adapt the CD process to suit their • limited resources? are modern, digital prototyping tools viable replacements or complements • to the conventional paper prototyping process?
To find the answers to these questions, a case study was performed at Netlight Consulting AB where Rapid Contextual Design and agile development methods were employed to design and develop an iPhone app for communication and knowledge sharing.
The results of this case study show that Rapid CD certainly has the potential to work well with smartphone app development. It is especially a good fit when objectives are vague, and when usability is in focus. However, results may vary depending on how the method is adapted to the project. In order to properly choose, plan and a adapt a Rapid CD version to smartphone projects, a set of qualification parameters expanding on those available in contemporary literature may be used. It was found that there are oportunities for updating the prototyping component of Rapid CD, but that some further investigation is needed to determine how this is done best.
In this section, answers to the research questions are presented, work done so far is summarized, and what future initiatives could be taken to develop the process further are described.
9.1 General conclusions
The aim of this thesis has been to explore ways to adapt the rapid contextual design process to agile smartphone application development projects. Section 1 explains 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 satisfying the needs of the client. The pilot app that was developed was well received, and was deemed very attractive as a project to continue development on within the company. The client was also impressed with the level of understanding of the company and its issues that the Rapid CD process helped gather, resulting in app features that were all relevant to the end-users.
61 In section 8.4.2, an additional set of metrics called qualification parameters was introduced. These are meant to be used when deciding what parts of the Rapid contextual design (CD) process to include and what parts to skip. They can also be used when deciding what version of Rapid CD to pick when planning a project.
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. It is suggested that any team surveying their project’s qualifications for Rapid CD observe these metrics during planning. Analyzing the own team’s qualification parameters may help when choosing or building a suitable variation of Rapid CD, 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 parameters based on core team conditions, team cohesion, team presence, team aptitude, and team 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, testing new ideas without having to design an entire interface. For smartphone app development there are standardized tools, metaphors and UI elements that may make paper prototyping unnecessarily time consuming in small projects. Espe- cially when digital mockup and wireframing tools that make it easy to test an idea with a large user base are available. The pros and cons of replacing physical prototyping 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 addressed before a fully adapted version of Contextual Design for smartphone application development can be published. Here in this final section a few pointers are be given for future work on the subject.
The main work that needs to be done is to test and validate the usefulness of the additional qualification parameters introduced in section 8.4.3. If proven to be accurate and valuable to project planning, they could potentially be used as a base in expanding the planning and process step composition of Rapid CD and derivative processes.
62 Since the paper prototyping step of Rapid CD was not tested, it is recommend that it be further investigated in conjection with digital prototyping tools. It has been suggested that digital prototyping could be a viable replacement for paper prototyping, but during which circumstances this would be the case remain par- tially ambiguous. The technique would probably be suitable as a complementary step to paper prototyping in most project where time is available.
If a team of more than two people was available, more aspects of both Rapid CD and agile development methods could be explored. Committing to following a single agile method and making use of helpers in the Rapid CD process would be interesting paths to pursue.
As noted in the discussion, digital prototyping interviews cannot be performed using the same interview techniques as those for paper prototypes. This calls for 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 design projects conducted by small teams (preferably of varying sizes) where a formal method for user-centered design has been applied. It is our thesis that even small projects with limited resources can increase their product value significantly by applying a formal method for design, if adapted properly.
63 64 References
[1] Karen Holtzblatt, Jessamyn Burns Wendell, and Shelley Wood. Rapid Contextual Design: A How-to Guide to Key Techniques for User-Centered Design (Interactive Technologies). Morgan Kaufmann, 2004. [2] Kent Beck, Mike Beedle, Arie Van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Je↵ries, et al. Manifesto for agile software development. 2001. [3] Jim Highsmith and Alistair Cockburn. Agile software development: The business of innovation. Computer, 34(9):120–127, 2001. [4] Kalle Lyytinen and Gregory M Rose. Information system development agility as organizational learning. European Journal of Information Sys- tems, 15(2):183–199, 2006. [5] Peter Abrahamsson, Kieran Conboy, and Xiaofeng Wang. “lots done, more to do”: the current state of agile systems development research. 2009. [6] Ken Schwaber. Scrum development process. In Business Object Design and Implementation, 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 G¨oransson, Inger Boivie, Stefan Blomkvist, Jenny Persson, 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ß, and Mark Rouncefield. The benefits of a long engagement: from contextual design to the co-realisation of work a↵ording artefacts. In Proceedings of the second Nordic conference on Human-computer interaction, pages 283– 286. ACM, 2002. [11] Marta Krist´ın L´arusd´ottir. 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/EU CONVIVIO HCI Educators’ Workshop, 23-24 March 2006, Limerick, Ire- land, pages 35–39. Citeseer, 2006. [12] Inka Vilpola, Kaisa V¨a¨an¨anen-Vainio-Mattila, and Taru Salmimaa. Apply- ing contextual design to erp system implementation. In CHI’06 Extended Abstracts 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 Studying digital 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 mobile application 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 Nordic conference on Human-computer interaction: changing roles, pages 437–440. ACM, 2006. [16] Arianit Kurti, Marcelo Milrad, and Fredrik Alserin. Contextual design of mobile services to support knowledge workers in library settings. In Advanced Learning Technologies, 2006. Sixth International Conference on, pages 375–377. IEEE, 2006. [17] Timothy Hoye and Joseph Kozak. Touch screens: A pressing technology. In Tenth Annual Freshman Engineering Sustainability in the New Millennium Conference 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 Social Research 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 ”Lightning Fast” and ”Lightning Fast +” methods respectively, and FRCD is ”Focused Rapid Contextual Design”. Gray color indicates that the corresponding step is not included in that variant...... 7
2 CIinterviewcoverageandstructure...... 23
3 Suggested application features, grouped by the six navigation itemsdesignedforthemainmenu...... 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 team withlackingdesignaptitude...... 55
10 Qualification parameters for example project 2, a project team with 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 Mainmenuview...... 34
4 Search&browseview...... 34
5 Employeeprofileview...... 34
6 Geographicoverviewview...... 34
7 Mainmenuview...... 39
8 Search&browseview...... 39
9 Employeeprofileview...... 39
10 Geographic overview view...... 39
68