Bridging UX and Web Development

Better Results through Team Integration

Jack Moffett

• Publisher: Morgan Kaufmann
• Year: 2014
• Print ISBN:
  9780124202450
• eBook ISBN:
  9780128007877
• Topic: Computer Science
• Subtopic: Computer Science General
• Index: Computer Science

The divide between UX and Web development can be stifling. Bridging UX and Web Development prepares you to break down those walls by teaching you how to integrate with your team's developers. You examine the process from their perspective, discovering tools and coding principles that will help you bridge the gap between design and implementation. With these tried and true approaches, you'll be able to capitalize on a more productive work environment. Whether you're a novice UX professional finding your place in the software industry and looking to nail down your technical skills, or a seasoned UI designer looking for practical information on how to integrate your team with development, this is the must-have resource for your UX library. - Establish a collaboration lifecycle, mapping design activities to counterparts in the software development process - Learn about software tools that will improve productivity and collaboration - Work through step-by-step exercises that teach font-end coding principles to improve your prototyping and implementation activities - Discover practical, usable HTML and CSS examples - Uncover tips for working with various developer personas

Part I

Working with Developers for Fun and Profit

Outline

Part I. Working with Developers for Fun and Profit

Chapter 1 State of the Industry

Chapter 2 Looking for Group

Chapter 3 Collaboration Life Cycle

Part I. Working with Developers for Fun and Profit

“The way we work at Apple is that the complexity of these products really makes it critical to work collaboratively, with different areas of expertise. I think that’s one of the things about my job I enjoy the most. I work with silicon designers, electronic and mechanical engineers, and I think you would struggle to determine who does what when we get together. We’re located together, we share the same goal, have exactly the same preoccupation with making great products.”

Sir Jonathan Ive

Jony is speaking of his collaborations as an industrial designer, but the same sentiment should apply to the way we, as interaction designers, work with developers. The tighter we can integrate with our development teams, the more effective we can be in our efforts to deliver good experiences to our users. It stands to reason that the closer we work with developers, the better our products will be. Better products hopefully result in better sales. As a result, we profit from improved collaboration. That’s one way to look at it, but money is only part of the equation. A paycheck isn’t enough to keep us satisfied in our employment. If you are anything like me, the relationships you have with your coworkers contribute significantly to any decisions about how long you stay at a company. Developing better relationships with developers, then, is going to increase our enjoyment of our day-to-day activities. Have your cake and eat it too; work with developers for fun and profit.

Chapter 1

State of the Industry

In January of 2012, a survey of UX professionals was conducted to determine the extent to which designers collaborate with developers. Questions covered the type of employer, workplace arrangements, skills, roles, participation, and relationships. Analysis of the results reveals an interesting paradox and provides a clear motivation for the book.

Keywords

survey; career; experience; software development; design; industry; workplace; skills; tools; title; position; competency; participation; implementation; production; work

In the latter half of 2011, I was putting together a conference presentation on the topic of working with developers. I was hypothesizing that the majority of designers weren’t integrated well with their developers, but I was working purely off of anecdotal evidence. I figured I should get a more accurate picture of the state of the industry, so I published an online survey through Survs and advertised it to the Interaction Design Association (IxDA), the AIGA Experience mailing list, through my own blog, and a few other channels. While over 300 people viewed the survey, only 82 respondents completed it. I realize that’s not a big data set, and I don’t claim to be a statistician, but I do believe that the results I’m presenting here are representative of the design community. For the most part, the results confirmed my suspicions, but I also found some really interesting outcomes I wasn’t expecting. At the very least, they convinced me that there’s a need for the information that I’m disseminating at conferences and now in book form. The full data set is available on GitHub at https://github.com/jackmoffett/Bridging-UX-and-Web-Development/. If you do anything further with the results or have additional thoughts on the conclusions I’m sharing here, I encourage you to drop me a line and share your thoughts.

Figure 1.1 Years of experience

The survey respondents were evenly distributed in their years of experience in the field, almost equally split between those with 10 or less years and those with more than 10 years. I had expected a lower percentage in the over 10 group, but I was pleased to see that my results evenly spanned the experience continuum. Further checking showed that there weren’t any significant trends based on experience, so there’s no need to show you any of the results broken down in that fashion. You can assume that for the rest of the survey questions, the answers were evenly distributed, experience-wise.

Figure 1.2 Company size

Figure 1.3 Design team size

To provide context, participants were asked about their current work situations. Exactly half of the respondents worked in a company larger than 100 employees, while only 7% were freelancers. At the same time, about half of the respondents were part of a small design team. In retrospect, I probably should have specified ranges for team size the way I did company size, but we’ll have to work with the resultant ambiguity.

Figure 1.4 Company size versus team size

When viewed as a parallel set, you can see from the figures that the most common case is to be working as part of a small design team, either within a large company or small company. And while it’s more common to be the only designer than to work in a large design group, that’s only because half of the freelancers are included in the count. There are a similar number of respondents (within three percentage points) working in a large design group within a large company as there are working as the only designer within a company, large or small. This is relevant information, as it shows that the majority of the respondents are in a work environment that my survey was specifically designed to address—that is, an organization in which designers have the opportunity to collaborate with developers on a daily basis. Consultants who only work with any given project team for a short time will find it harder to integrate at the level I’m promoting. Similarly, design firms that don’t staff their own developers are less likely to integrate at all. That doesn’t mean that it isn’t worth attempting, only that it’ll require more attention and flexibility.

Figure 1.5 How would you classify your company?

I found it particularly interesting that 39% of respondents worked for companies that weren’t software development or design firms. The prevalence of designers embedded within product and service companies is a good indicator of the acceptance of design as a necessary contributor. For the purposes of this survey, it gives us an interesting point of comparison for some of the following questions.

As you can clearly see in the parallel set in Figure 1.6, the majority of respondents who work for a design firm aren’t collocated with developers (the thickest teal band). Of course, the vast majority of those working at a software development firm are collocated and are evenly divided between being in the same room or elsewhere within the same building. When it comes to designers embedded in a product/service company, most share a room with the developers. Two respondents actually share a desk with a developer. That seems a bit extreme—you both have my sympathy.

Figure 1.6 Company type versus collocation with developers

Figure 1.7 shows what other job roles respondents work with on a regular basis: 82% work with front-end developers, and 72% work with back-end developers. Those are the two most prevalent collaborations, with visual designers coming in third.

Figure 1.7 Who do you work with on a regular basis?

To summarize what we’ve learned so far, we can generalize that most interaction designers and user experience (UX) professionals are working for companies in which they’re collocated with developers and collaborate with them more than anyone else. That says to me that we should be spending a lot more time in design education and professional development teaching designers how to work with developers. When you look at typical design schools, however, you’ll find very little cross-discipline collaboration. And looking at most design conference programs, there isn’t much in the way of designer–developer relations, although it’s more often a topic for discussion in the Agile community.

With that understanding, let’s examine what exactly these designers are doing, as shown in Figure 1.8.

Figure 1.8 Skill competency

Most of the respondents (86%) claimed to be competent interaction designers. That’s not at all surprising, given that the survey was advertised to them. UI prototyping comes in at 55%, but the number drops to 18% for actual implementation. Now, just because we’re proficient at something doesn’t mean we’re using that skill in our current position. I’d claim to be a competent illus...

Table of contents

• Cover image
• Title page
• Table of Contents
• Copyright
• Dedication
• Acknowledgments
• Preface
• Part I: Working with Developers for Fun and Profit
• Part II: Sitting in the Driver’s Seat
• Not the End
• References and Resources
• Glossary
• Index