Schweitzer Fachinformationen
Wenn es um professionelles Wissen geht, ist Schweitzer Fachinformationen wegweisend. Kunden aus Recht und Beratung sowie Unternehmen, öffentliche Verwaltungen und Bibliotheken erhalten komplette Lösungen zum Beschaffen, Verwalten und Nutzen von digitalen und gedruckten Medien.
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.
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.
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.
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.
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.
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.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.
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.
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.
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...
Dateiformat: ePUBKopierschutz: Adobe-DRM (Digital Rights Management)
Systemvoraussetzungen:
Das Dateiformat ePUB ist sehr gut für Romane und Sachbücher geeignet – also für „fließenden” Text ohne komplexes Layout. Bei E-Readern oder Smartphones passt sich der Zeilen- und Seitenumbruch automatisch den kleinen Displays an. Mit Adobe-DRM wird hier ein „harter” Kopierschutz verwendet. Wenn die notwendigen Voraussetzungen nicht vorliegen, können Sie das E-Book leider nicht öffnen. Daher müssen Sie bereits vor dem Download Ihre Lese-Hardware vorbereiten.Bitte beachten Sie: Wir empfehlen Ihnen unbedingt nach Installation der Lese-Software diese mit Ihrer persönlichen Adobe-ID zu autorisieren!
Weitere Informationen finden Sie in unserer E-Book Hilfe.
Dateiformat: PDFKopierschutz: Adobe-DRM (Digital Rights Management)
Das Dateiformat PDF zeigt auf jeder Hardware eine Buchseite stets identisch an. Daher ist eine PDF auch für ein komplexes Layout geeignet, wie es bei Lehr- und Fachbüchern verwendet wird (Bilder, Tabellen, Spalten, Fußnoten). Bei kleinen Displays von E-Readern oder Smartphones sind PDF leider eher nervig, weil zu viel Scrollen notwendig ist. Mit Adobe-DRM wird hier ein „harter” Kopierschutz verwendet. Wenn die notwendigen Voraussetzungen nicht vorliegen, können Sie das E-Book leider nicht öffnen. Daher müssen Sie bereits vor dem Download Ihre Lese-Hardware vorbereiten.
Bitte beachten Sie: Wir empfehlen Ihnen unbedingt nach Installation der Lese-Software diese mit Ihrer persönlichen Adobe-ID zu autorisieren!
Dateiformat: ePUBKopierschutz: Wasserzeichen-DRM (Digital Rights Management)
Das Dateiformat ePUB ist sehr gut für Romane und Sachbücher geeignet - also für „fließenden” Text ohne komplexes Layout. Bei E-Readern oder Smartphones passt sich der Zeilen- und Seitenumbruch automatisch den kleinen Displays an. Mit Wasserzeichen-DRM wird hier ein „weicher” Kopierschutz verwendet. Daher ist technisch zwar alles möglich – sogar eine unzulässige Weitergabe. Aber an sichtbaren und unsichtbaren Stellen wird der Käufer des E-Books als Wasserzeichen hinterlegt, sodass im Falle eines Missbrauchs die Spur zurückverfolgt werden kann.