A review of:
Bridging UX & Web Development
By Jack Moffett
Morgan Kaufmann Publishers
“If you look at natural history, you’ll find many plausible origins for the legend of the unicorn. You’ll also find a number of creatures that, while not matching our perfect envisioning of a unicorn, are nonetheless creatures with four legs and a single horn. I posit that there are actually quite a few designers in the workforce who meet the base-level description of a unicorn; they just don’t have the opportunity or direction necessary to meet their full potential.” – From the preface of Bridging UX and Web Development
We’ve all heard of the elusive UX unicorn that produces stunning graphic designs, creates solid user-centered architectures, and also knows how to code. For those who are considering the pros and cons of becoming a UX unicorn, or at least trying their hand at coding, Jack Moffett’s Bridging UX and Web Development is a good book to have on your journey.
The primary goal of the book is to help web designers work more effectively with developers to create great user experiences. Moffett argues that “if you want total control of your design” you must play an active role throughout development. Over the course of nine chapters and 189 pages, he provides advice on everything from designer-developer relationship management to the tools and technical details of getting started with HTML and CSS.
Much of the book is grounded in a survey he conducted in 2011 that uncovered the following about the state of designer-developer relations:
- Designers and developers are typically co-located and work together more than other roles
- More designers who currently produce code rate themselves unqualified to do so than those who rate themselves qualified
Moffett is hoping to bridge this gap by providing readers with perspective, tools, and code examples that will help them get up-to-speed and participate in development.
On designer-developer relationships he advises, “Don’t force your process on developers” and “Don’t expect developers to make last-minute changes just because you haven’t been involved until late in the process.” This is solid advice and helpful to keep in mind whether you decide to learn to code or not. Other tips are included in the book, as well as personas of various types of developers you might interact with in your work.
Moffett provides a nice outline of how designers and developers can collaborate throughout the web development life cycle. He makes strong arguments for how designers can get involved in tasks that they might typically shy away from, such as decisions around the technology stack used in web development. Understanding the constraints of the technology being considered will help designers develop their own perspective and advocate for the option that best suits the design.
To aid in understanding the technology, Moffett provides guided coding exercises. If you want to do the exercises yourself, you can follow along in the book. You can also download the completed exercises (and the survey data he references) from the book’s Git Hub repository.
I tried my hand at a few exercises and found the combination of the steps in the book, along with the reference files, to be a sufficient guide for understanding the concepts.
Moffett also stresses the importance of having a good toolbox when developing. He reviews code editors, common browsers, browser-based development tools, and tools for merging files and managing version control. This provides a good base for getting started with learning to code. If you want to delve deeper there is also a list of books, links, and tools at the end of the book.
Regardless of how involved you want to be throughout development, this book will open your mind to being a more technically proficient designer. If you’re still feeling torn about whether it’s worth it to learn how to code, consider the following seven benefits of learning how to code taken from the book:
[bluebox]
Book Excerpt: Benefits of Learning to Code
Benefit 1: Calling BS on coders
Have you ever been in a situation where a developer was telling you that your design couldn’t be implemented, and you thought they were lying (or at least wrong), but didn’t have enough knowledge to call their bluff? It’s unfortunate, but it does happen. A lot of designers claim this particular benefit, but I’m not so sure. This is a very combative stance to take, and if you read Chapter 2, you know how I feel about designer-developer relationships. If you’re in a work environment filled with mistrust, learning to code for this benefit is wasted effort. There are bigger problems that you should be seeking solutions to, rather than perpetuating a divisive atmosphere by throwing accusations, provable or not.
Benefit 2: Respect and credibility
Also cited by many designers, apparently developers will respect you more if you can code. I can see why this might be true, but I believe this, too, a false benefit. In a properly functioning team, people will respect other people for their skill, talent, professionalism, leadership, dedication, and positive attitude, regardless of their particular skill set. I want the developers I work with to respect me as an outstanding designer first and foremost. That comes from working together on projects and sharing the failures, the late nights, the triumphs, and the successful rollouts. It comes from a learned appreciation for my contributions over time. My coding ability may factor into it, but it’s only a small part. I gained the respect of my coworkers long before I was able to check my code into Subversion.
Benefit 3: Speaking their language
This may well be the most cited benefit of learning to code. Certainly, it’s easier to communicate with developers when we can understand their terminology. It helps even more to understand their concerns and challenges. That said, I don’t believe it’s necessary to learn to code to develop that understanding. You can learn this simply by talking with developers, asking them questions, and listening to them. You learn how to speak their language by caring enough to pay attention. What you learn from coding is much more detailed, and while it’ll undoubtedly give you a better appreciation of what they do, this alone isn’t a good reason to learn how to code.
Benefit 4: Knowledge of capabilities and difficulty of implementation
This is the flip side of drawback 2. By knowing how to code, you’ll have a better understanding of what can and can’t be done, what is hard or easy to do, and what takes more or less time. This may or may not be true. Just because I understand front-end web development doesn’t mean I have any sense of the impacts my design will have on the back-end database. Much like benefit 3, you don’t necessarily have to know how to code to understand technical feasibility.
Benefit 5: Prototyping
There are many different ways to create prototypes. There are prototyping tools, such as Axure and Balsamiq, that allow you to build interactive prototypes without knowing how to code. You can use presentation software, such as Apple’s Keynote or Microsoft PowerPoint. Tools like these can get you a long way down the road, and in many cases, they’re sufficient to get the answers you need. However, the ability to prototype using the same technology that will be used in implementation does have additional benefits. It’s often easier to create behaviors with the native technology than to reproduce them with a different technology. For example, once you understand how to create a scrolling pane with the rubber-band effect in an iPhone app, I’m sure it’s much easier to do it that way than to mimic the rubber-band effect in Adobe After Effects, and then you can actually experience using it on the target device rather than watching it. Furthermore, when you prototype with the actual technology, you know that what you see is what you get. It’s not possible to prototype something that’s impossible to build. And, of course, there’s the potential to turn your prototype into the actual software, although that’s usually not the goal of a prototype. Depending on your circumstances, there may be reason enough to learn to code for purposes of prototyping.
Benefit 6: Reduced documentation
I’ve already discussed this in the context of the design phase, so I’ll only mention it here briefly. There are definite time savings when you can implement the specifics of a UI rather than documenting them for somebody else.
Benefit 7: Control
Of all the potential benefits to learning to code, control is the one that seals the deal. When you’re able to implement your designs, you’re in almost complete control of the outcome. Rather than fretting over the discrepancies that occur when well-meaning developers mishandle your design, you can get things right the first time. If you see a mistake made by you or by someone else, you can fix it without having to bother a developer about it. When the product goes out the door, you know that it’s what you made it. I can take care of every little detail that fits into my estimated schedule, and that’s going to make a big difference in the final product. That should be enough to get most designers interested. It was enough for Matt Nish-Lapidus at Normative, who stated,
‘…we’re instituting a new professional development program here at Normative. For the next few months, we’re all taking an hour a day to dig into front-end web and mobile code. We’re going to learn to bring our ideas to life and start designing all the details that are often missed when we just make pictures.’
[/bluebox]
