HAL Id: hal-01614250https://hal.inria.fr/hal-01614250

Submitted on 10 Oct 2017

HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, estdestinée au dépôt et à la diffusion de documentsscientifiques de niveau recherche, publiés ou non,émanant des établissements d’enseignement et derecherche français ou étrangers, des laboratoirespublics ou privés.

Design Breakdowns: Designer-Developer Gaps inRepresenting and Interpreting Interactive Systems

Nolwenn Maudet, Germán Leiva, Michel Beaudouin-Lafon, Wendy E. Mackay

To cite this version:Nolwenn Maudet, Germán Leiva, Michel Beaudouin-Lafon, Wendy E. Mackay. Design Breakdowns:Designer-Developer Gaps in Representing and Interpreting Interactive Systems. CSCW 2017 - ACMConference on Computer Supported Cooperative Work and Social Computing, Feb 2017, Portland,Oregon, United States. pp.630 - 641, �10.1145/2998181.2998190�. �hal-01614250�

Design Breakdowns: Designer-Developer Gaps inRepresenting and Interpreting Interactive Systems

Nolwenn Maudet1,2 Germán Leiva1,2 Michel Beaudouin-Lafon1,2 Wendy E. Mackay2,1

1LRI, Université Paris-Sud, CNRSUniversité Paris-SaclayF-91405 Orsay, France

2InriaUniversité Paris-SaclayF-91405 Orsay, France

{maudet, leiva, mbl, mackay}@lri.fr

ABSTRACTProfessional interaction designers and software developershave different trainings and skills, yet they need to closelycollaborate to create interactive systems. We conducted threestudies to understand the mismatches between their processes,tools and representations. Based on 16 interviews, we foundthat current practices induce unnecessary rework and cause dis-crepancies between the original design and the implementation.We identified three key design breakdowns where designersomitted critical details, ignored the presence of edge cases ordisregarded technical limitations. We next observed two face-to-face meetings between designers and developers. We foundthat early involvement of the developer helped to mitigate po-tential design breakdowns but new ones emerged as the projectunfolded. Finally, we ran a participatory design session withtwo designer/developer pairs. Both pairs had difficulty repre-senting and communicating pre-existing interactions. Creatingcomplete interaction descriptions required iterating from indi-vidual examples to rule-based representations. We concludewith implications for designing collaborative tools that facili-tate the designer’s ability to express and the developer’s abilityto implement complex interactive systems.

Author KeywordsDesigner-Developer Collaboration; Design Breakdowns;Shared Artifacts; Collaborative Prototyping Tools.

ACM Classification KeywordsH.5.3. Information Interfaces and Presentation (e.g. HCI):Computer-supported cooperative work

INTRODUCTIONInteractive software development in the 1970s and 1980s in-volved traditional software engineering processes, with limitedinterdisciplinary collaboration. By the 1990s, the advent offull color, high-resolution displays enabled high-quality inter-active graphics, with a corresponding need for professional

Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full citationon the first page. Copyrights for components of this work owned by others than theauthor(s) must be honored. Abstracting with credit is permitted. To copy otherwise, orrepublish, to post on servers or to redistribute to lists, requires prior specific permissionand/or a fee. Request permissions from Permissions@acm.org.CSCW’17, February 25-March 1, 2017, Portland, OR, USA.Copyright is held by the owner/author(s). Publication rights licensed to ACM.ACM 978-1-4503-4335-0/17/03...$15.00DOI: http://dx.doi.org/10.1145/2998181.2998190

designers. However, integrating designers’ and developers’work practices has proven difficult, often leading to frictionbetween them [10].

Designers and developers of interactive systems have differentbackgrounds and skills, and focus on different aspects of thedesign process [18]. Designers are trained to communicatevisually: They use graphical editors, e.g. Adobe Illustratorand Photoshop, to create “static design documents” [24] suchas wireframes and mockups. They prioritize visual appearanceand interaction behavior [6] over the rules and data structuresthat govern the software. By contrast, developers are trainedto work with abstractions: They use text editors and IntegratedDevelopment Environments (IDEs) to create functional sys-tems. They prioritize the translation of design documents intoimplementable formats over the details of visual design anduser interaction.

Designers and developers often work independently, requir-ing a hand-off phase for turning static design documents intoworking code. Although a number of collaborative proto-typing tools have emerged that attempt to bridge this gap1,the transition between design and implementation is poorlyunderstood.

Our work seeks to uncover the problems faced by designersand developers as they collaborate, with a particular emphasison the representation, communication and interpretation ofinteractive systems. Our overall goal is to better inform thedesign of collaborative prototyping tools and facilitate thetransition from design to implementation.

After reviewing related research, we describe the results ofthree studies that examine the collaboration problems of pro-fessional designers and developers. In the first study, wegathered 25 stories from 16 designers and developers. Weanalyze the collected data and generate a classification of therecurring issues. In the second study, we observed how a groupof designers and developers worked around these breakdownsduring face-to-face meetings. In the last study, we conducted aparticipatory design session with two designer-developer pairsto explore how they represent and communicate interaction.We conclude with implications for the design of collaborativetools that facilitate how designers and developers represent,interpret and communicate interactive system designs.

1See, e.g., http://www.prototypingtools.co

Session: Design - Supporting Collaboration CSCW 2017, February 25–March 1, 2017, Portland, OR, USA

630

RELATED WORK

Studying the designer-developer collaboration processAlthough user-centered design methods for interactive systemsemerged in the 1980s [25], it took a long time for them to beintegrated into software engineering processes. By the mid-1990s, Poltrock and Grudin [28] found that large corporations’“development practices blocked the successful application ofaccepted principles of interface design”.

Agile methodologies2 were created to address a number ofsoftware engineering issues, with the emphasis on deliveringworking software as quickly as possible. However, Ferreiraet al. [10] showed how this approach is often at odds with theuser-centered design tradition of iterating the design from theuser’s perspective, before development begins. Silva [8] iden-tified three roles undertaken by designers during a project, andfound that these role changes may complicate the designer’scollaboration with developers. In their literature review, Salahet al. [29] survey the challenges of integrating agile methodolo-gies into user-centered design practices. They show the needfor a “shared understanding of the design vision”: developersmust understand what they are expected to implement as soonas possible.

In this context, Brown et al. [4] analyze two major aspectsof the collaboration process: collaboration events and arti-facts. Their study of collaboration events shows that designersand developers constantly perform “interactional alignmentwork” [31] and that the collaboration process is “patternedaround the use of artifacts” [5].

Understanding the role of artifactsStar and Griesemer [30] introduced the concept of boundaryobjects, which coordinate collaborative work within commu-nities of practice. Lee [16] distinguishes between boundaryobjects designed to “satisfy the information needs of the collab-orating parties” and boundary negotiating artifacts designedto push the boundaries in complex, non-routine projects thatlack standardized objects for collaboration.

In the context of designing and developing interactive systems,the most common boundary objects are design artifacts. Forexample, Newman [24] analyzed the specificities of interme-diate artifacts such as sitemaps, storyboards, mockups andprototypes. On the other hand, few studies focus on collabora-tion with respect to design artifacts as boundary negotiatingartifacts between designers and developers. Brown et al. [4] es-tablished twelve categories of artifacts used for collaboration,including “design ideas”, “stories” and “interface proxies”.We are particularly interested in “interface proxies” becausethey serve as “a focal point for people to discuss”.

Myers et al. [23] surveyed more than 200 designers to under-stand how they address interaction in their design practices.They found that design documents focus primarily on the vi-sual design: designers find it much easier to communicatevisual appearance than interaction behavior to designers. Oz-cen et al. [26] concur, noting that designers “struggle to have a

2http://www.agilemanifesto.org

conversation with the material” when creating refined interac-tive systems. Park et al. [27] conducted a laboratory study thatshows the differences between how designers and developersuse text to represent interaction. They found that programmers“use more verbose descriptions” while “designer’s experiencewith tools like Photoshop and PowerPoint influences theirnatural expression of behaviors”.

Overall, the literature suggests that designers have difficultycommunicating the design of interaction behavior to develop-ers. However, the causes for these problems remain unclear.We need to better understand how designers currently rep-resent interaction behavior to developers, as well as whichaspects of this representation hinders collaboration.

Tools to bridge the gap between design and developmentSeveral authors propose extending engineering representationsto encompass interaction design. For example, UML3 dia-grams can be extended to describe interactive behaviors [7]and serve as a communication tool between designers anddevelopers. Inspired by the popularity of software design pat-terns [13], Borchers [3] proposed the creation of catalogs ofinteraction design patterns, and Wiemann [34] proposed usingthem as the Lingua Franca [9] between designers and develop-ers. Today, developers often use the design patterns definedby software vendors, such as Apple’s iOS Human-InterfaceGuidelines 4 and Google’s Material Design 5. Although theseoffer a useful starting point for understanding the conventionsof a given platform, they cannot solve all representation issues,especially when creating new interactions.

Another approach is to bridge the design activity of prototyp-ing with the development activity of coding. As early as 1995,Myers [22] advocated prototyping tools that support a widerange of interactions. Landay et al. [15] proposed an electronicsketching approach and envisioned “a future in which the userinterface code will be generated by user interface designersusing tools”. To support evolutionary prototypes [2] that grad-ually evolve into the final system, DENIM [17] lets designerscreate sketches in the early design phase and later augmentthem with drawings that express interactivity. Similarly, DE-MAIS [1] uses storyboard annotations to produce workingexamples early in the design process.

Outside the research community, practitioners acknowledgethe gap between design artifacts and their subsequent imple-mentation. Within the past few years, over 40 commercialprototyping tools have appeared6, and a 2015 survey of 4,000designers found that 53% use a prototyping tool [33]. However,these tools do not result in final implementations: designersstill lack tools that link their representations to developer’simplementations. Our goal is to inspire the next generationof prototyping tools by identifying and analyzing the prob-lems caused by the limitations and misinterpretation of designartifacts and proposing strategies to overcome them.

3http://www.uml.org4http://developer.apple.com/go/?id=app-review-ios-hig5http://www.google.com/design/spec/material-design6http://www.cooper.com/prototyping-tools

Session: Design - Supporting Collaboration CSCW 2017, February 25–March 1, 2017, Portland, OR, USA

631

STUDY ONE: DESIGNERS & DEVELOPERS INTERVIEWSThe goal of the first study was to examine the existing practicesof professional designers and developers from a wide varietyof settings. We were particularly interested in how:

● designers represent and communicate a design;● developers interpret the design; and● designers and developers identify and overcome break-

downs that appear during the process.

METHODWe conducted critical incident interviews [19] about recentdesign projects, in order to obtain specific, detailed stories oftheir successes and failures. We were particularly interestedin their problems representing and communicating interactionwith each other. We also looked for recurring patterns acrosswork settings, cultures and types of projects.

ParticipantsWe recruited 16 professional designers and developers (7women, ages 24-46) from France (8), Sweden (3), Argentina(2), the USA, Canada and China, who create web sites, mobileapplications or interactive installations. Their work environ-ments include: digital agency (6), design studio (4), start-up(2), freelance (2), and software factory (1).

Participants P1ds-P8ds are designers (ds), self-described as UXDesigner, Visual Designer, Interaction Designer, or GraphicDesigner. Participants P9dv–P16dv are developers (dv), self-described as Mobile Developer, Web Developer, Front-EndDeveloper, or Creative Coder. Their experience in collabo-rating across disciplines, i.e. from designer to developer orfrom developer to designer, ranges from 1.5 to 20 years (mean8). Half of them typically collaborate remotely, none haveworked with each other. All participants reported that theyfollow agile methodology.

ProcedureWe interviewed participants in their studio or office for ap-proximately 90 minutes. We asked designers to choose recentprojects in which they collaborated with a developer, and askeddevelopers to choose recent projects in which they collabo-rated with a designer. For each project, we asked them to showus their tools and the specific artifacts they created, and todescribe, step-by-step, the details of how they communicatedthe design or implementation. We probed for both successfuland unsuccessful collaboration examples.

Data CollectionWe collected 25 stories (one or two per participant) from dif-ferent projects. During the interviews, we recorded audio andvideo of the participants manipulating the artifacts they cre-ated. We also photographed the final products they producedand took notes.

AnalysisWe analyzed the 25 stories using a Grounded Theory [32]approach. We studied the projects with a particular focuson breakdowns related to creating or interpreting the designdocuments. We first selected examples that formed natural

Figure 1. Each StoryPortrait includes a photograph of a key artifact,as well as a timeline to show the successive steps of the collaboration,including participant’s quotes and drawings. Here P5ds explains howshe created a grid system to collaborate more easily with the developer.

categories, looking for higher-level concepts that emergedfrom the details of each projects. We iterated and mapped eachstory to one or more categories. We illustrated each projectwith a modified version of a StoryPortrait [14] to facilitate theanalysis (see Figure 1). A StoryPortrait includes a photographof the interactive system or a key artifact created during theproject, as well as a timeline to show the successive stepsof the collaboration, including the participant’s quotes anddrawings.

RESULTS AND DISCUSSION

Reworking and RedundancyDesigners produce multiple design documentsAll designers create multiple documents to communicate dif-ferent aspects of their designs. Designers create extra designdocuments when the original design documents lack specificityor lead to confusion. Unfortunately, much of the informationin these additional documents is redundant. We found thatdesigners spent time recreating the same information acrossseparate documents. For example, P2ds created five documentsto communicate the design of a small application: UxPin “forsharing mockups”; Pixate “for detailed animations that cannotbe expressed with words”; InVision “for interactive mockupswith basic interactions and annotations for non-obvious fea-tures”; Photoshop because “these developers are used to workwith .psd files”; and Illustrator, “the software we actually useto produce the screens.” She also used email to communi-cate additional design details to the development team. Evenwith all these documents, this designer was unable to clearlycommunicate the design.

Designers use several media to represent interactionsAlthough all designers use images of “screens” to representthe visual design of the interface, these are insufficient toaccurately describe user interaction. Designers resort to other

Session: Design - Supporting Collaboration CSCW 2017, February 25–March 1, 2017, Portland, OR, USA

632

formats, each with different trade-offs, to communicate theirideas. Most common is text, used extensively by all designers.For example, P6ds briefly described in an email how the usermoves between screens: “from the login screen, you slide tothe next screen”. Text comments and annotations are easy toproduce, but rarely sufficiently explicit or complete, leavingdetails open to interpretation. Less common is video (24%of the projects) which makes it possible to visualize customanimations, but is expensive, time-consuming and does notfully communicate the user experience. Finally, designersoccasionally create interactive mockups (12% of the projects)using the built-in set of interactions in the tool of choice. Thesecommunicate how the interaction should feel, but only whenthe tool has the right set of pre-defined interaction types.

All but one designer created custom “guidelines” or “specifi-cations”. For example, P7ds created a video to communicatethe design of an “in progress icon” animation. When the de-veloper was unable to recreate the design from the video, P7dscreated an additional file that “extracts the useful information[from the video] and represents it on a timeline”.

Developers recreate design documentsThe most common activities mentioned by the developer in-clude interpreting the design documents and recreating themwith developer tools. For example, P9dv received an informaltext description of a custom animation, but had to ask for avisual representation in order to fully understand the design.

We were surprised by the amount of time that developersspent recreating design documents. Some developers cameup with interesting strategies to increase their productivity.For example, when developing a mobile radio application,P14dv inserted the provided image as the background of hercorresponding view in the IDE’s Interface Builder. She thenpositioned her components on top, to recreate the designer’scomposition. She could then “figure out the [layout] con-straints” of the screen to make it responsive, such as determin-ing that some elements were center aligned. P11dv createda similar setup with two monitors. To implement the visualdesign, he places the mockups on the smaller screen to assessthem: “I measure by eye rather than being pixel perfect.”

Developers misinterpret designsMany design decisions are lost, as developers struggle to in-terpret and implement the designer’s original intent. In fact,none of the initial implementations were exactly as the orig-inal design. P1ds felt that the developer “used our design asan inspiration, then he made many design decisions that hedid not have to take”. Similarly, P3ds provided a video thatshowed the developer how to vary a text-box color accordingto the background picture. He later realized that the developerhad only partially implemented his idea by sampling a singlepixel, instead of generating an average color based on severalpixels.

During the implementation phase, designers create correctiondocuments to show the location of the mismatches and whatshould be modified. For example, to correct a vertical mis-alignment, P3ds created a video. He first traced a segmentedline to highlight the misalignment and then animated the cor-

rect repositioning of the elements. In the context of a real statewebsite project, P6ds discovered several visual mismatchesincluding wrong margins, colors and fonts. He decided tomodify the CSS and correct the mistakes by himself, usingthe web-browser developer tools. Because these changes werelocal to P6ds’s browser, he screencaptured the new website’slook and added some annotations linking the modified CSScode to the visual result. The developer then recreated all ofthese steps with his own tools.

Strategies to avoid rework and redundancyWe found cases of rework and redundancy in all the interviews,but only two developers and one designer explicitly mentionedstrategies to avoid them. P14dv had a simple solution: “De-signers should just create their interfaces directly in Xcode”,referencing the Interface Builder within the IDE.

P5ds designed a complex casino website with many similar UIcomponents. To avoid recreating them each time, she “wasinspired by the developers’ way of working”: she createda modular styleguide that served as a shared visual library.She could then copy modules from the styleguide to createeach new screen, gradually adding new modules or missinginformation such as the color of the hyperlinks, as requestedby the developers.

P12dv began with mockups and specifications for a web-basedinteractive advertisement builder. He used Flash to createthe architecture of the interface, writing the code “so that thedesigner could easily touch it”. The developer encouragedthe designer to directly manipulate the code to fine-tune lookand feel details, such as modifying the images or changingthe duration, delay and type of each animation. This strategyallowed P12dv to avoid misunderstandings and unnecessaryback and forths.

Design BreakdownsWe use the term design breakdown to describe an impedimentthat must be fixed before the design can be implemented. Weidentified three recurrent types of design breakdowns relatedexclusively to the collaboration between designers and devel-opers (Figure 2). These categories emerged from the mostcommon issues encountered in the 25 analyzed projects.

Figure 2. Key design breakdowns between designers and developers:Missing information: Designers do not communicate necessary details.Edge Cases: Designers do not consider certain problematic situations.Technical constraints: Designers are not aware of technical limitations.

Session: Design - Supporting Collaboration CSCW 2017, February 25–March 1, 2017, Portland, OR, USA

633

Missing InformationThe first type of breakdown occurs when the designer makesa decision without communicating it to the developer. Twodesigners and four developers reported cases of missing infor-mation. For example, P9dv received an interactive mockup of awebpage. He could not determine whether the page’s calendarwidget was interactive or simply the output of another inter-action. P9dv also lacked the design rationale: “What did theycreate that calendar for?” Similarly, P13dv received only staticmockups for a sports application, and could not determine howto move from one screen to another. P14dv created a “designspecification file” for the designer with missing informationfrom the original design files.

Designers found it difficult to represent and communicate dy-namic behavior to the developers. For example, P8ds wantedto create an animation of a blossoming flower but did not knowhow to represent her idea in After Effects. She ended up draw-ing a few sketches and then sat next to the developer as theyworked out how to implement her idea directly in code. In twocases, the designers avoided mentioning interaction at all, rely-ing on the developer to create off-the-shelf interactions. Thissupports Myers et al.’s [23] argument that designers find inter-actions hard to represent. For example, P6ds provided staticdesign documents without representing some transitions, evenif they were simple: “I let the developer pick the interactionbetween the screens, since they are very basic.”

Edge CasesThe second type of design breakdown is missing edge cases,when designers focus on typical scenarios and do not considerextreme or problematic situations. Developers are trained tothink about edge cases; designers are not. All developersreported that designers omit important edge cases from theirdesign documents, and that they had to decide how to handlethese situations themselves.

P13dv received only mockups to develop a sport application.Because the designer had only specified the “sunshine cases”,P13dv had to make design decisions for each of the differentedge cases. For example, the client required him to includeadvertisements, so he modified the original design to accom-modate the ads. Similarly, P16dv prepared a responsive gridfor a cruise company website. The original mockup only fea-tured the desktop version of the website. P16dv did not knowhow to handle large elements that did not fit within the widthof the screen of the mobile version: “Should the rectangle betransformed into a square or should it take a full row?” ForP16dv, designers usually “don’t take into account the dynamicnature of the data”.

Responsive websites make it particularly difficult for designersto consider all possible layout cases. For example, P11dvexplained how designers of a responsive website had specifiedthe element widths based on a percentage of the screen, butdid not consider what the maximum width should be, forcingP11dv to make the decision using his “designer’s eye”.

Some designers overcome these issues with design guidelines.For example, P4ds created a 16-page specification with an-notated wireframes to explain the sign-up functionally of a

website. She reported that “specifications make me think of allthe states and exceptions”. She also used the guideline to cap-ture and communicate the rationale for her design decisions.Similarly, P3ds created a spreadsheet to help him think and“explain the rules of the game and the limits” for each websiteelement.

Technical ConstraintsThe third type of design breakdown is the designer’s lack ofawareness of technical limitations, either in general or withrespect to the developer’s skills. Five designers and four de-velopers reported breakdowns due to such misunderstandings,which created additional work for the developer. For example,P13dv received a design for an iPad application that called forhorizontal scrolling when in portrait orientation. But P13dv“could not recycle his code from the landscape version to cre-ate it”. He had to reimplement it from scratch, since it hadalready been approved by the client.

This type of misunderstanding leads developers to modify thedesign themselves. For example, P11dv created a responsivewebsite for a start-up. The designers created a desktop and amobile version of their design but “did not realize that they hadmodified the behavior between the two versions and I wouldhave had to develop two different source codes”. Instead, hedecided to redesign the layout to make it feasible as a “simpleresponsive website”.

Not being aware of technical constraints is also a problemfor designers. For example, when working on a complexwebsite, the developer first told P6ds that “everything waspossible”. P6ds soon discovered that the developer was unableto implement many elements with his tools, even though theyhad already been validated with the client. P6ds said: “Heshould have said it earlier, we would have adapted our design.”Instead, they were forced to redesign the project several timesto accommodate the developer’s limitations.

Collaboration is usually smoother when the designer is awareof the developer’s constraints and possibilities. For example,P5ds worked on a project with two different developers. Thefirst asked her to specify all the dimensions, such as the dis-tances among all the elements on the screen, “so we lost a lotof time”. The second developer asked for a grid specification,which she created with 12 columns, a gutter size and a maxi-mum size of 1200px. “Now we have the same, each one in ourown tool.” The grid allowed the developer to express dimen-sions in percentages, sparing P5ds the need to make additionalannotations and saving a great deal of time (Figure 1).

Late developer involvementEven though all participants claimed to use agile methodology,only five of the 25 projects (two remote and three co-located)included face-to-face sessions between designers and develop-ers dedicated to co-design the initial interaction. For example,P4ds had an idea for a custom navigation rule and invited allthe designers and developers to help design it. The devel-oper was able to implement the resulting navigation behaviorwithout additional instructions or documents: “Nothing waswritten down, we only had the screens.”

Session: Design - Supporting Collaboration CSCW 2017, February 25–March 1, 2017, Portland, OR, USA

634

Figure 3. Relationship between interaction complexity and developer in-volvement. Lack of developer involvement in the early phase of custominteraction design is correlated with problematic or impossible imple-mentation.

Other similar examples suggest that involving developers dur-ing the design phase makes it easier to create complex interac-tions (Figure 3). In such cases, developers gain an understand-ing of the desired interaction during the meeting and designersneed not fully represent it in their design documents.

Developers were most likely to be called in for the designphase when the project included custom interactions. In mostof these cases (6/8), developers successfully implemented thedesired custom interaction, as in the aforementioned exam-ple of P3ds’s flower animation. However, when the projectrequired a custom interaction and the developer was not in-volved at the design stage, most developers were not able tosubsequently implement the proposed interaction (5/7). Forexample, P7ds reported that the developer “just did not im-plement” the custom transition he had proposed. One of theremaining cases was still problematic: P13dv was frustratedwith the proposed interaction: “I could not recycle my code,but as the design had already been validated by the client Istill had to implement it. I lost a lot of time.”

In summary, we identify three main types of issues whendesigners and developers collaborate on the creation of in-teractive systems: reworking and redundancy, design break-downs and late developer involvement. We found reworkingand redundancies in both designers and developer practices.Designers struggle to represent interaction with their currenttools and use multiple design documents to communicate dif-ferent aspects of their design. Developers spend an excessiveamount of time recreating the designer’s documents and cor-recting their misinterpretations. During the implementationphase, developers face three types of design breakdowns —missing information, edge cases and technical constraints —that undermine the collaboration process. Our data also sug-gests that projects requiring custom interaction should involvedevelopers early during the design phase.

STUDY TWO: CASE STUDY

MotivationStudy one identified three types of breakdowns that occurbetween designers and developers in a wide range of contexts.To further understand these breakdowns and how they are

addressed, we conducted a longitudinal study of a team ofdesigners and one developer. We observed P1ds from StudyOne and his team during the entire duration of a one-monthproject, a responsive website for a crowd-sourced directory ofcompanies. We were interested in whether design breakdownsstill appear when a developer is involved early in the project,and, if so, which strategies are used to avoid or mitigate thesebreakdowns.

ParticipantsWe studied three designers and one developer (ages 24-25, onewoman). This was the first time that this group of designershad collaborated with this particular developer.

ProcedureWe observed the two face-to-face design meetings that in-volved all the designers and the developer. The first two-hourmeeting (Figure 4) focused on the design of the website. Thesecond meeting lasted an hour and focused on implementa-tion. We also interviewed the designers separately, prior to thesecond meeting, to learn more about their design tools.

Data CollectionWe video recorded both meetings and took notes. We tookpictures of collaborative actions, i.e. exchanges between thedesigners and the developer, and their manipulation of artifactssuch as drawings, notes and software. We also received copiesof the emails exchanged during the project.

AnalysisWe used Chronoviz [11] to annotate relevant, interesting eventsduring the meetings. Two coders marked and analyzed thetimes when a participant asked a question, or when a designersought confirmation from a developer or vice versa. We corre-lated these marks to the design breakdowns classification fromStudy One.

Results and DiscussionThe email exchanges focused primarily on discussions withthe client about requirements and validating design decisions.Since these activities are beyond the scope of this paper, wefocus our analysis solely on the two face-to-face meetings.

First Meeting - Accounting for design breakdownsThe main benefit of the early face-to-face meeting was to letparticipants seek validation from each other and to avoid po-tential problems. We identified examples of avoiding missinginformation, considering edge cases, and clarifying technicalconstraints.

In order to avoid missing information (12 occurrences), thedeveloper often encouraged the designers to specify concretedetails about their design ideas. For example, when the design-ers proposed a button related to the advanced search feature ofthe website, the developer demanded greater precision: “Is itgoing to have radio buttons or checkboxes?” Similarly, when adesigner suggested that “there should be two sharing buttons”,the developer immediately sought concrete details: “Ok, butwhat exactly do you want me to share... the URL of theirwebsite, the URL of our website or a Facebook link?” The

Session: Design - Supporting Collaboration CSCW 2017, February 25–March 1, 2017, Portland, OR, USA

635

Figure 4. First meeting. The developer shows an example of an existinginteraction to the designers while one designer represents it on paper.

developer required these details in order to translate the designidea into specific elements that he could implement.

The mere presence of the developer pushed the designers to bemore explicit about certain design issues. For example, whendesigning the “company card” that would be displayed on thesearch page, one of the designers realized that he needed tospecify the title’s maximum number of characters to maintainthe visual consistency.

The developer also pushed the designers to think about edgecases (5 occurrences). For example, when designing the cate-gory system for filtering companies, he asked the designers:“Can a project exist without a category?” This insight led onedesigner to come up with a different strategy: He proposed an“other” category that groups together previously uncategorizedcompanies. Similarly, when the designers proposed adding agesture for deselecting a category on the mobile version, thedeveloper asked them to consider how this design decisionwould affect the desktop version of the website. Given thedeveloper’s warning, the designers decided to skip the feature:“Based on what you just said, I think we should not let the userselect different filters.”

Designers often sought validation, confirmation or informationabout technical constraints (17 occurrences). This echoes the“considering implementability” category observed by Brown etal. [5]. First, they were able to confirm with the developer thefeasibility of their design. For example, one designer asked thedeveloper: “Is it possible to have a swipe gesture on a mobilewebsite?” In order to make informed decisions, they askedthe developer about the complexity of implementing certaindesigns. When the designers proposed a search feature forcompanies, the developer asked them to specify exactly whatshould be searchable. The designers idea was to search withinall company-related information, including their descriptions.The developer replied: “Everything is possible... but if youreally want to make a search inside the description, it will bea bit more complex.” He suggested only looking up namesand tags, but with an autocompletion feature. The designersagreed.

Second Meeting - Fixing design breakdownsEven though they were able to handle many design break-downs during the first meeting, new ones appeared duringthe implementation process. The developer found new edgecases (4 occurrences). For example, he noticed that a company

card with multiple subcategories would occlude the company’sname: “There is a risk that it overlaps with the title, I think itshould be redesigned.” The designer responded: “Maybe wecan put three dots and display the extra ones only on [mouse]hover.”

The developer also requested missing information that he couldnot infer (8 occurrences). For example, he could not under-stand why the subcategory was not displayed on the companycard. The designer had thought about this, but did not commu-nicate it to him: “I did not explain it in my screens but here weare actually within the housing category. In fact, the housingicon should be highlighted in the upper menu.” In this case,the developer had interpreted the highlight as a hover state,and not as a selected state. The developer also asked: “Whatexactly is clickable on the item [company] card? Is it only thetitle and image or the whole card?” Another problem was thatthe developer could not understand the purpose of a cross inthe corner of the company card: “This little cross here, whatshould happen when I press it? Is it a back button?”

In a few cases, designers asked for more details about deci-sions made by the developer. For example, when reviewingthe search feature, the designer asked for a clarification: “Inwhich order are the items shown when they are displayed asresults?” Designers also questioned some of the developer’sdecisions: “Why do we need pagination? Is it because of theheavy loading [time of the HTTP] request?” The developernodded as the designer proposed an alternative: “We shouldput the maximum number of items on the page without loadingproblems.”

Vocabulary mismatch between designers and developersIn both meetings, differences in the vocabulary used by de-signers and developers led to miscommunication. Sometimes,designers and developers used different terms for the sameconcept. For example, during the second meeting the devel-oper talked about a “fixed” element using CSS terminology.The designer, who tried to take the user’s perspective, referredto the same object as a “moving” element, an element thatfollows the scroll. It took some time for them to discover thatthey were talking about the same behavior.

We observed several strategies for overcoming these issues(5 occurrences). Developers and designers tried to bridge thevocabulary gap by adopting each other’s terminology. Forexample, when discussing whether an item should appear inseveral categories, one designer started using mathematicalconcepts when communicating with the developer: “Is it theunion or the intersection of these two categories?” The devel-oper also reformulated the original design idea in terms of UIwidgets: “It is either a radio button or a checkbox.”

On several occasions, designers and developers looked up spe-cific interaction techniques on a particular website or foundexamples from a mobile application on a smartphone to showthe others. This “communication-by-example” helped themverify that they were talking about the same interaction tech-nique.

In summary, we found that both designers and developersactively try to mitigate design breakdowns when meeting face-

Session: Design - Supporting Collaboration CSCW 2017, February 25–March 1, 2017, Portland, OR, USA

636

to-face. Involving the developer at the beginning of the designprocess helped the team reduce the amount of missing infor-mation in the design documents, discover and handle edgecases and set clear technical constraints for the scope of thedesign. Even so, new design breakdowns occurred during theimplementation phase and had to be solved collaboratively bythe team. Vocabulary mismatches also created several collabo-ration issues, especially when discussing interactive behavior.

PARTICIPATORY DESIGN WORKSHOP

MotivationStudy Two suggests that early involvement by the developercan reduce some, but not all breakdowns. The third studyattempts to tease apart problems that arise from generating de-sign ideas and those that arise from an inability to successfullyrepresent the interaction itself. We conducted a participatorydesign workshop that combines multiple methods [20], to com-plement the interviews from Study One and the longitudinalstudy from Study Two.

First, we are interested in whether design breakdowns are sim-ply a natural result of the creation process, or if they are alsoby-products of the limitations in the representations used todescribe interactive systems. Second, since these representa-tions are traditionally the product of designers, we wanted toelicit new kinds of representations by asking designers anddevelopers to create them together.

ParticipantsWe recruited two designers and two developers (all men, ages24-33). Two of them (one designer and one developer) partic-ipated in Study One and were invited due to their interest inthis research. The other two professionals were recommendedby participants from the previous studies. The developers hadnot previously worked with the designers. They had 1.5 to 10years of experience collaborating across disciplines. Besidesthe four active participants, the authors attended the workshop:two as observers and two as participant-observers.

ProcedureThe workshop lasted three hours and featured two activities de-signed to examine how designers represent and communicateexisting interaction behaviors. To make the interactions morechallenging to describe, we avoided standard widgets such asbuttons, or standard interactions such as mouse clicks. Instead,we chose novel, unfamiliar interaction techniques from twomobile applications that rely heavily on continuous gestures.Participants were given the opportunity to explore these tech-niques for themselves on a mobile device we provided. Thetechniques included:

● Interaction 1: The Clear to-do list mobile app 7 uses aspread gesture to progressively indicate the creation of anew item between two existing items. Lifting the fingerscreates the item.● Interaction 2: The Paper note-taking mobile application 8

uses a lasso technique to select an area of the canvas to be7http://www.realmacsoftware.com/clear/8http://www.fiftythree.com/paper

cut, which can then be moved with a pan gesture. Whilemoving, a tap with another finger outside the selectioncopies it at that particular location.

● Interaction 3: The Paper app uses a lasso selection to spec-ify an area to fill with a color selected by tapping on acolor swatch. When the lasso crosses itself, the area is col-ored with the so-called even-odd winding rule, leading tounexpected results.

Activity 1 - Warm-up interaction game (1h)Designers and developers were divided into two pairs, groupedby roles. Designers received Interaction 1 and developersreceived Interaction 2. We made sure that none of the par-ticipants knew these interactions. We asked the designers todescribe the interaction as they would ideally communicateit and asked the developers how they would receive it. Weinstructed them to give as complete a description as possible,and gave them access to all the tools and means they use intheir daily work practices. When participants were satisfiedwith their representation, they gave the resulting artifacts tothe other pair. Each pair then tried to describe what they un-derstood from the representation. We also asked them to tryto find the interaction in the real application. Afterwards, par-ticipants discussed the issues encountered as they created andinterpreted the representations.

Activity 2 - Communicating an interaction (2h)The two designer-developer pairs received Interaction 3. Weasked each pair to come up with strategies or new represen-tations that fully communicate the original interaction. Weasked them to create representations that satisfy both membersof the pair.

Data CollectionWe collected all artifacts created by the participants: sketches,diagrams, text descriptions, paper prototypes and stop-motionvideos. We took photographs and videos as they manipulatedthese artifacts, and took notes during the discussions.

Results and DiscussionCurrent representations do not encourage completenessParticipants took approximately 15 minutes each to create andbe satisfied with their representations in Activity 1. Even so, itwas clear that, even though they were given a fully functioninginteraction, the four proposed representations were incomplete.This suggests that some design breakdowns are a by-productof inadequate representations.

The designers relied primarily on visual representations basedon drawings and annotations. Developers felt that these wereeffective in communicating the overall idea, but left too manyunanswered questions for correct implementation. For ex-ample, the designers did not communicate certain types offeedback, such as the gesture spread threshold or the animatedtransition that placed new items at the top of the list. Duringthe discussion, one of the developers explained that a picturerequires more translation steps than a text description for im-plementation: “If I receive a picture, I first need to translate itinto text and then I need to translate it into code.”

Session: Design - Supporting Collaboration CSCW 2017, February 25–March 1, 2017, Portland, OR, USA

637

Developers relied mainly on text, including programming vo-cabulary, e.g., conditionals and loops, complemented by a fewvisual elements. Text descriptions provided specific informa-tion for the implementation but did not clearly convey the lookand feel of the interaction to the designers. For example, whentrying to represent Interaction 2, developers did not communi-cate the increased opacity outside the selection and the flasheffect when pasting the copied area.

Strategies for creating complete representationsDuring Activity 2, the two pairs explored seven different strate-gies for fully representing and communicating the interaction.We describe two of the most promising: Pair 1 decomposedinteraction 3 using examples from other applications: the lassotool from Photoshop combined with the paint bucket from Il-lustrator. The designer from Pair 1 proposed recording videosto demonstrate the use of these tools and combine them. Heargued that this strategy would avoid misunderstandings aswell as provide a complete description of the interaction. Thedeveloper from Pair 1 proposed a shared “lexicon” describingthe objects of the program, their characteristics and the toolsthat can interact with them. Pair 1 thought that a common vo-cabulary would facilitate the discussion about how to extractcommon components.

In order to reach a shared and complete representation, bothpairs refined their representations through multiple iterations.They started with a visual example, and then added rulesand annotations to produce a more complete description. Forexample, the designer from Pair 1 drew a snapshot of theinteraction at four points in time: “(1) I touch, (2) I move (3)I release (4) The tool creates the closed shape.” (Figure 5a).Next, the developers and designers collaborated to graduallygeneralize the description of the interaction. The developer,inspired by the designer’s representation and his knowledge of“flow programming”, drew a diagram representing the differentcomponents of the interaction (Figure 5b): finger, shape, lineand closed shape. Based on the developer’s representation, thedesigner built a new representation that combined the strengthsof both proposals (Figure 5c). He color-coded a visual exampleand mapped each graphical element to a detailed programming-oriented description: “a straight line between the point of

Figure 5. (a) Designer drew a snapshot of the interaction at four pointsin time. (b) Developer created a diagram connecting primitive graphicalelements and functions with user inputs. (c) Designer merged the tworepresentations with an example.

origin and the current finger position [...] a curve that recordsthe complete path of the finger from the origin to the currentfinger position [...]”.

In summary, we observed that even when provided with anexisting and complete interaction, both designers’ and de-velopers’ representations suffered from missing informationand edge cases. This suggests that current representationsare limited and may result in design breakdowns. To createcomplete representations, designers and developers graduallyadded rules on top of concrete examples.

DISCUSSION AND IMPLICATIONS FOR DESIGNWe identified three types of design breakdowns that occur,regardless of the distribution of the team, their experienceor the project domain. Designers sometimes create represen-tations with missing information; they often fail to considerproblematic edge cases; and they may be unaware of technicalconstraints. Our studies show that breakdowns can result in se-vere mismatches between the system originally envisioned bythe designers and its final implementation. To avoid such con-sequences, we should help designers and developers identifythese breakdowns and solve them as early as possible.

What causes these breakdowns? Clearly, some designers anddevelopers lack adequate skills. However, the ubiquity ofbreakdowns across a wide variety of professionals, on diverseprojects in different settings, makes it unlikely that this isthe only factor. What about differences in training and back-ground knowledge? For example, several technical constraintbreakdowns occurred when designers did not understand thelimitations of the current software platform. Moffett [21] sug-gests including programming concepts as an integral part ofdesigner’s training. Conversely, offering developers basic de-sign training would help them fill in missing information byapplying relevant design principles.

Miscommunication is another key factor. Like Ozcen etal. [26] and Park et al. [27], we identified numerous occa-sions where designers struggle to communicate interaction.Study Two shows that this can be mitigated somewhat by in-volving developers early in the design process, as advocatedby Salah et al. [29].

Study Three indicates that a key source of design breakdownsand subsequent rework is the lack of true boundary objects forrepresenting interaction that can be shared by designers anddevelopers. Designer tools generate isolated representationsthat must be updated manually if the actual system changes.Designers are also responsible for manually keeping the de-sign consistent across multiple design documents, often withdiffering formats. By contrast, developer tools require preciseand exhaustive representations that can be compiled and exe-cuted, and manipulate representations directly connected withthe actual system, ensuring that they are always up-to-date.

We believe that tools for the design and implementation ofinteractive systems must accommodate the skills, values andpractices of both designers and developers, with better integra-tion between them. Based on our findings, we suggest four keyimplications for the design of tools to support collaborationbetween designers and developers.

Session: Design - Supporting Collaboration CSCW 2017, February 25–March 1, 2017, Portland, OR, USA

638

Multiple synchronized viewsToday’s design and development tools operate in isolation:changes in a designer’s tool such as Sketch are not reflectedin the developer’s tool, such as XCode. Worse, changes inone design document are not automatically reflected in theothers. Some designers and developers address this by linkingtheir documents via cloud-based file syncing or by referencingexternal resources from the code. Also, several IDEs supportmultiple views: UI code can be opened with a text editoror an interface builder and manipulating either tool modifiesthe underlying code file. Unfortunately, these solutions aretool-specific and ad-hoc, and do not reduce the amount ofreworking across design documents and development tools.

We argue that interaction design tools should support syncingcapabilities and automatic transformations among representa-tions. This raises a key challenge, which is how to represent aninteraction from one tool, if there is no corresponding represen-tation in the other tool. For example, the source code may notprovide a dynamic representation of a particular interaction inthe design tool. Further work should focus on finding waysto connect designer-friendly views, e.g., timelines, videos,diagrams, to the corresponding source code.

Refactoring the user interfaceSome graphical tools include “symbols” or “smart objects”that are referenced across documents instead of being copied.Designers can modify these smart objects and see the changesreflected wherever they are used. While this encourages modu-larity it also requires planning: “smart objects” must be createdbefore being used. However, the fluid nature of design canmake pre-planning difficult: new ideas or constraints mayappear and clients often change their minds.

We argue that interaction design tools should support refac-toring: “The process of changing a software system in sucha way that it does not alter the external behavior of the codeyet improves its internal structure” [12]. Allowing design-ers to extract similar visual elements and interaction patternsto create reusable modules or components would reduce theamount of reworking and enhance consistency in the user in-terface. These new modules could be added to existing designpattern libraries, thus increasing support for novel forms ofinteraction.

Achieving complete interaction descriptionsDesigners and developers in the participatory design workshopstarted with specific, concrete examples, and then, throughmultiple iterations, generalized it step by step to create a moreabstract representation. This suggests that designers and devel-opers would benefit from formalisms that both provide com-plete descriptions of interactions, but can also be representedwith specific examples.

We argue that interaction design tools should provide simple,high-level interaction abstractions, e.g. swipe or drag&drop,but also allow the designer to manipulate lower-level descrip-tions when necessary, e.g. mouse up and down. Being able totransition from specific examples to higher-level abstractionswould help designers create more complete descriptions ofeach interaction and help avoid missing information.

Exploring design possibilitiesOur results suggest that designers are less likely than develop-ers to specify edge cases, even though their early identificationcan avoid significant problems later. We argue that designer’stools should help designers discover edge cases.

First, the tools should show how the design reacts to different-sized data sets, e.g., small, medium and large, within theconstraints of the domain (similar to the concept of load testingin software development). Second, the tools should supportthe simulation of typical situations in different contexts, e.g.,mobile vs. stationary, connected vs. disconnected, or brightvs. low light conditions. Consistency checks run under eachcondition could then highlight potential design problems.

CONCLUSION AND FUTURE WORKThis paper studied how designers communicate and developersinterpret interactive system designs. First, we conducted 16interviews with professional designers and developers. Weshowed that the current workflow induces unnecessary rework.Designers create a multitude of redundant design documentsand developers must recreate them with their own tools. Thisprocess often introduces mismatches with the original design.

We identified three key design breakdowns: missing informa-tion, when designers do not communicate a specific detail;edge cases, when designers do not think about a particu-lar case; and technical constraints, when designers are notaware of developer’s technical limitations. The interviews alsoshowed that when developers are not involved in the initialdesign of custom interactions, the implementation tends to beproblematic or even impossible.

To further understand how designers and developers addressthese breakdowns, we conducted a longitudinal case study.We found that even if the early involvement of the developermitigated the occurrences of design breakdowns, new onesappeared in subsequent meetings.

We then ran a participatory design workshop to study the roleplayed by the representations of interactions in breakdowns.We observed that the limitations of the representations usedto communicate interaction result in missing information andedge cases. These results suggest that communicating andrepresenting interactions require an iterative process, fromindividual concrete examples to rule-based representations.

Finally, we presented four strategies for creating better col-laboration tools that take design breakdowns into account andreduce reworking: synchronized views, user interface refactor-ing, complete interaction descriptions and support for designexploration. We plan to explore these approaches by design-ing new tools that help bridge the gap between designers anddevelopers.

ACKNOWLEDGMENTSThis research was supported by European Research Councilgrant n° 321135 CREATIV: Creating Co-Adaptive Human-Computer Partnerships. Our thanks to all the participantsfor their rich insights and the fruitful discussions. We alsothank the ex)situ team and especially Carla Griggio for herthoughtful comments and suggestions.

Session: Design - Supporting Collaboration CSCW 2017, February 25–March 1, 2017, Portland, OR, USA

639

REFERENCES1. Brian P Bailey, Joseph A Konstan, John, and John V

Carlis. 2001. Supporting Multimedia Designers: TowardsMore Effective Design Tools. In Proc. MultimediaModeling: Modeling Mutlimedia Information andSystems (MMM2001). 267–286.

2. Michel Beaudouin-Lafon and Wendy E Mackay. 2003.Prototyping tools and techniques. In Thehuman-computer interaction handbook: fundamentals,evolving technologies and emerging applications.1017–1039.

3. Jan Borchers. 2001. A Pattern Approach to InteractionDesign. John Wiley & Sons, Inc.

4. Judith M. Brown, Gitte Lindgaard, and Robert Biddle.2011. Collaborative Events and Shared Artefacts: AgileInteraction Designers and Developers Working TowardCommon Aims. In 2011 AGILE Conference. IEEE,87–96.

5. Judith M. Brown, Gitte Lindgaard, and Robert Biddle.2012. Joint implicit alignment work of interactiondesigners and software developers. In Proceedings of the7th Nordic Conference on Human-Computer InteractionMaking Sense Through Design - NordiCHI ’12. ACMPress, New York, New York, USA, 693.

6. Alan Cooper, Robert Reimann, and David Cronin. 2007.About Face 3: The Essentials of Interaction Design.Wiley. 610 pages.

7. Paulo Pinheiro da Silva and Norman W. Paton. 2000.UMLi: the unified modeling language for interactiveapplications. Ph.D. Dissertation. University ofManchester.

8. Tiago da Silva, Milene Selbach Silveira, and FrankMaurer. 2013. Ten Lessons Learned from IntegratingInteraction Design and Agile Development. In 2013 AgileConference. IEEE, 42–49.

9. Thomas Erickson. 2000. Lingua Francas for design. InProceedings of the conference on Designing interactivesystems processes, practices, methods, and techniques -DIS ’00. ACM Press, New York, New York, USA,357–368.

10. Jennifer Ferreira, Helen Sharp, and Hugh Robinson. 2011.User Experience Design and Agile Development:Managing Cooperation Through Articulation Work.Softw. Pract. Exper. 41, 9 (Aug. 2011), 963–974.

11. Adam Fouse, Nadir Weibel, Edwin Hutchins, andJames D. Hollan. 2011. ChronoViz: a system forsupporting navigation of time-coded data. In Proceedingsof the 2011 annual conference extended abstracts onHuman factors in computing systems - CHI EA ’11. ACMPress, New York, New York, USA, 299.

12. Martin Fowler and Kent Beck. 1999. Refactoring:Improving the Design of Existing Code. 431 pages.

13. Erich Gamma, Richard Helm, Ralph Johnson, and JohnVlissides. 1994. Design Patterns: Elements of ReusableObject-Oriented Software. Pearson Education.

14. Ghita Jalal, Nolwenn Maudet, and Wendy E Mackay.2015. Color Portraits: From Color Picking to Interactingwith Color. In Proceedings of the ACM CHI’15Conference on Human Factors in Computing Systems,Vol. 1. 4207–4216.

15. James A. Landay and Brad A. Myers. 1995. Interactivesketching for the early stages of user interface design. InProceedings of the SIGCHI conference on Human factorsin computing systems - CHI ’95. ACM Press, New York,New York, USA, 43–50.

16. Charlotte P. Lee. 2007. Boundary Negotiating Artifacts:Unbinding the Routine of Boundary Objects andEmbracing Chaos in Collaborative Work. ComputerSupported Cooperative Work (CSCW) 16, 3 (apr 2007),307–339.

17. James Lin, Mark W. Newman, Jason I. Hong, andJames A. Landay. 2000. DENIM: Finding a Tighter FitBetween Tools and Practice for Web Site Design. InProceedings of the SIGCHI conference on Human factorsin computing systems - CHI ’00. ACM Press, New York,New York, USA, 510–517.

18. Jonas Löwgren. 1995. Applying Design Methodology toSoftware Development. In Proceedings of the 1stConference on Designing Interactive Systems: Processes,Practices, Methods, & Techniques (DIS ’95). ACM, NewYork, NY, USA, 87–95.

19. Wendy Mackay. 2002. Using video to support interactiondesign, In Proceedings of the SIGCHI Conference onHuman Factors in Computing Systems. DVD Tutorial,Inria and ACM/SIGCHI (2002).

20. Wendy E. Mackay and Anne-Laure Fayard. 1997. HCI,natural science and design: a framework for triangulationacross disciplines. In Proceedings of the conference onDesigning interactive systems processes, practices,methods, and techniques - DIS ’97. ACM Press, NewYork, New York, USA, 223–234.

21. Jack Moffett. 2014. Bridging UX and Web Development:Better Results through Team Integration. Elsevier Science.224 pages.

22. Brad Myers. 1995. User interface software tools. ACMTransactions on Computer-Human Interaction 2, 1 (mar1995), 64–103.

23. Brad Myers, Sun Young Park, Yoko Nakano, GregMueller, and Andrew Ko. 2008. How designers designand program interactive behaviors. Proceedings - 2008IEEE Symposium on Visual Languages andHuman-Centric Computing, VL/HCC 2008 (2008),177–184.

24. Mark W. Newman and James A. Landay. 2000. Sitemaps,Storyboards, and Specifications: A Sketch of Web SiteDesign Practice. In Proceedings of the conference onDesigning interactive systems processes, practices,methods, and techniques - DIS ’00. ACM Press, NewYork, New York, USA, 263–274.

Session: Design - Supporting Collaboration CSCW 2017, February 25–March 1, 2017, Portland, OR, USA

640

25. Donald A. Norman and Stephen W. Draper. 1986. UserCentered System Design; New Perspectives onHuman-Computer Interaction. L. Erlbaum AssociatesInc., Hillsdale, NJ, USA.

26. Fatih Kursat Ozenc, Miso Kim, John Zimmerman,Stephen Oney, and Brad Myers. 2010. How to supportdesigners in getting hold of the immaterial material ofsoftware. In Proceedings of the 28th internationalconference on Human factors in computing systems - CHI

’10. ACM Press, New York, New York, USA, 2513.

27. Sun Young Park, Brad Myers, and Andrew J. Ko. 2008.Designers’ natural descriptions of interactive behaviors.In 2008 IEEE Symposium on Visual Languages andHuman-Centric Computing. IEEE, 185–188.

28. Steven E. Poltrock and Jonathan Grudin. 1994.Organizational Obstacles to Interface Design andDevelopment: Two Participant-observer Studies. ACMTrans. Comput.-Hum. Interact. 1, 1 (March 1994), 52–80.

29. Dina Salah, Richard F. Paige, and Paul Cairns. 2014. Asystematic literature review for agile developmentprocesses and user centred design integration. InProceedings of the 18th International Conference on

Evaluation and Assessment in Software Engineering -EASE ’14. ACM Press, New York, New York, USA,1–10.

30. Susan Leigh Star and James R. Griesemer. 1989.Institutional Ecology, ’Translations’ and BoundaryObjects: Amateurs and Professionals in Berkeley’sMuseum of Vertebrate Zoology, 1907-39. Social Studiesof Science 19, 3 (1989), 387–420.

31. Anselm Strauss. 1988. The Articulation of Project Work:An Organizational Process. The Sociological Quarterly29, 2 (1988), 163–178.

32. Anselm Strauss and Juliet M. Corbin. 1998. Basics ofQualitative Research: Techniques and Procedures forDeveloping Grounded Theory. SAGE Publications. 312pages.

33. Khoi Vinh. 2015. Design Tools Survey | The ToolsDesigners Are Using Today. (2015).http://tools.subtraction.com/index.html

34. Meike Wiemann. 2016. Patterns as a tool forcollaboration: A case study of collaboration betweendesigners and developers through user interface patternlibraries. Ph.D. Dissertation. Universitet Umeå.

Session: Design - Supporting Collaboration CSCW 2017, February 25–March 1, 2017, Portland, OR, USA

641