Bridging UX and Web Development (eBook)

Better Results through Team Integration

Jack Moffett (Autor)

eBook Download: PDF | EPUB

2014 | 1. Auflage
224 Seiten
Elsevier Science (Verlag)
978-0-12-800787-7 (ISBN)

Infos

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

With a BFA in Graphic Design from West Virginia University and a Masters in Interaction Design from Carnegie Mellon, Jack has been designing web, desktop, and mobile applications for over a decade. He has worked in both research and industry environments and has been teaching design part-time for more than eight years at WVU. As Senior Interaction Designer at Inmedius, a Boeing Company, Jack's responsibilities cover the gamut from initial user research and product conceptualization through to implementation and testing. As such, his skill set includes visual design, information design, and front-end implementation. He has designed software tools for Lockheed Martin, Shell, DaimlerChrysler, Eaton, and many organizations within the U.S. military, including Joint Service Explosive Ordnance Disposal, Naval Reactors, and NCIS. Jack has spoken at conferences and led workshops to teach designers how to integrate with their development teams and participate in implementation. He co-founded IxDA Pittsburgh and writes about design on designaday.tumblr.com.

Textauszug

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 illustrator and photographer if they were listed, but I don’t use those skills very often in my job. Figure 1.9 details what activities respondents regularly participate in.

Figure 1.9 Activity participation

Wireframe creation and UI sketching are the top two activities. This is exactly what I was expecting. Design documentation, requirements analysis, user research, and usability testing all come in the lower seventieth percentile. Physical prototyping, at 65%, surprised me by beating out digital prototyping and screen rendering, both of which were below 50%. Perhaps that speaks to the recent popularity of paper prototyping for mobile devices. Now we get down to the activities I’m most interested in. Only half of the respondents are reporting bugs. That’s a missed opportunity I’ll discuss later. Very much related to bug reporting is participation in functional testing—that is, testing the product to make sure everything works as intended. Only 20% are participating in implementation, but to be honest, that’s a little higher than I was afraid it might be. At 19%, it appears that most of the designers who are implementing their UIs are also fixing their bugs, so that’s good.

All-in-all, the survey results confirmed my suspicions. Most designers don’t implement the UIs they design, but they do work with the developers on a regular basis, hopefully ensuring that the integrity of their design is translated into the functioning product. On the other hand, there’s a sizable number of designers who are participating in implementation. Here’s where things get really interesting.

Figure 1.10 is a simple parallel set that tells us two things. First, half of the designers who consider themselves competent in the skills necessary to implement a UI don’t regularly participate in implementation as part of their jobs. We can postulate reasons. They may work in a team that has specialized front-end developers capable of understanding the nuances of visual design (typography, color, etc.) who are technically more capable than the designers in question. Given the rarity of us unicorns, however, I’d be surprised if that’s a significant reason. More likely, their developers don’t have any expectation that the designers would contribute production code, and the designers haven’t made an effort to do so. They may feel uncomfortable trying to insert themselves into the...

Produkt-Details

• Erscheint lt. Verlag: 6.6.2014
• Sprache: englisch
• Themenwelt: Informatik ► Software Entwicklung ► User Interfaces (HCI)
• Themenwelt: Mathematik / Informatik ► Informatik ► Theorie / Studium
• Themenwelt: Informatik ► Web / Internet ► Web Design / Usability
• ISBN-10: 0-12-800787-7 / 0128007877
• ISBN-13: 978-0-12-800787-7 / 9780128007877