Bridging UX & Web Development: Better Results Through Team Integration

Task Prioritization

Okay, we can estimate our own tasks, and we can provide developers with information to improve their estimates, but estimates are only one ingredient of project schedules. There’s another way designers can contribute to the team’s success: task prioritization. In most cases, there will be fewer designers on a team than there will be developers. There’s certainly work that developers can do prior to receiving a finished UI design specification, but at some point, they have a dependency on the designer’s deliverables. For peak efficiency, you need to be aware of your developers’ swim lanes. What feature is each developer working on first? Who is going to need her screen specified first? Are there any tasks you can complete sooner than others? Which features have the most risk, and who is on the critical path to implementing those? You should work closely with your project manager to prioritize your own tasks in such a way that you never have a developer twiddling her thumbs, waiting for you to get around to designing the thing she is supposed to implement next.

Communication

Eventually, it all comes back to communication. A designer must be in constant communication with the rest of the team, sharing design decisions as they happen, rather than waiting to spring a finished masterpiece on them. Effective communication is supported through the use of shared tools.

I put a lot of stock in the tools I use, and I have fought many times to continue using a Mac in an organization that primarily runs Windows. I have a long history with Adobe and the products it has created or acquired. Just as I wouldn’t call a plumber and, when he arrived at my house, hand him my wrench and tell him to use it instead of the tools he brought with him, I expect my employer to trust me to select the tools I use. So, I’m the last person that will tell you to stop using the tools that you find most effective for your work, nor would I argue that you have to switch platforms. What I’m preaching is the adoption of additional tools that are used by the developers for the sake of better integration and communication. I’ve already mentioned task-tracking software. JIRA is web based and therefore cross-platform, so it was easy to pick up. If your team is using something that doesn’t have a client on your platform, I suggest requesting for a virtual machine (VM) to be set up that you can access the software on.

Your task management tool is a very important method of communicating with your team. My design tasks will be set up in parallel with development tasks. Let’s say there’s a system status display feature that we’re going to be adding to our product. There are going to be several tasks entered for that one feature:

1. System status display: design
2. System status display: implementation
3. System status display: UI design
4. System status display: UI implementation

There could be others, but this is the minimum, assuming the feature has a UI. The first two tasks are for the developers. Yes, the developers have design tasks too—more on that later. Tasks 3 and 4 are mine. The developer who gets assigned tasks 1 and 2 will “watch” my tasks—that’s JIRA’s term for subscribing to notifications. Every time I update my task—be it adding a comment, attaching a sketch, or changing its status—the developer will receive an email detailing the update. I’ll use the UI design task right from the get-go, recording questions that I need to answer, leaving notes about options I’m considering, and attaching concept sketches. In this way, the developer is constantly in the loop and can add his two cents whenever necessary. I’m not saying this replaces face-to-face communication—it enhances it with full transparency. It also results in a contextual, searchable “paper trail” of any decisions that were made. This is a huge help to the developer as he formulates an estimate.

Another tool that figures prominently in the requirements phase at my company is our development wiki. We use Confluence, another Atlassian product. It began as a place for the developers to document their architectural designs, but quickly grew to contain all of the information we need to share. Each project gets its own space. When we receive an FRD from a client, it’s entered into the wiki. From that point on, as the requirements are clarified and modified, the wiki keeps track of the changes. We record questions that we want to pose to the customer, and then we log the answers. All of the information I gather from my research is filed there as well, making it available to the entire team. Of course, we all subscribe to the project, so we all receive email notification when a page is added or updated. Yes, it can create a lot of email noise, but the peripheral awareness is well worth it. I set up rules in my email application that dump notifications from JIRA and Confluence into specific folders. That way, they don’t clog up my inbox, and I can quickly peruse them, checking for relevant items, when I’m ready for a status update.

Maybe your developers are using a wiki too, or maybe they aren’t. Your company may employ a specialized requirements-tracking tool for this purpose. We have begun evaluating such tools to support distributed teams. My purpose here isn’t to dictate a set of tools that you should be using. Rather, I’m urging you to find out what tools your developers are using and figure out how you can hook into them. Communication is happening through these tools, and you need to be in the loop. When you’re all sharing the same tools, you’ll be sharing your thoughts and ideas; you’ll be sharing your questions and answers; you’ll be sharing your problems and solutions. There will be a shared understanding of the requirements, goals, and strategies that shape the project—both technical and experiential. That’s a big win for the team, and if you’ll pardon a little bit of sneaky selfishness, it’s a huge win for designers. These tools allow us to extend our influence, spreading awareness of UX concerns among all team members in a subtle, yet irresistible, fashion.

It may be the case that your team isn’t using these types of tools. Of the survey respondents, 15% claimed that nobody at their company was using issue-tracking software. If you find yourself in such a situation, I suggest approaching it as an opportunity to make a positive impact on your team’s effectiveness. Talk to the senior developers and project managers about the process inefficiencies they’re currently dealing with and suggest trying a tool that will help address their issues. It may not even take a financial investment to start incorporating project management tools. Inexpensive hosting solutions, like Codebase and Trello, can get your team up and running quickly.

Trello is a general-use, online organization and collaboration tool from Fog Creek Software. With it, you can create and assign tasks with deadlines and notifications. It provides basic capabilities, such as commenting, file attachments, and checklists, and it has apps on the major mobile platforms. It’s free, so it is a great way to get your feet wet.

Codebase, as the name implies, is specifically targeted at software development. The service hosts code repositories (which I’ll go over in Chapter 5) and provides a suite of tools for project management, including issue tracking, time tracking, project notebooks (like a wiki), and discussions. Codebase also offers a free, if limited, account. It’s enough for you to try out on your next project. Not only can you potentially improve your team’s process, but I imagine you’ll earn some serious bonus points doing it.

Design

The design phase is the part of the project in which the details of the UI are determined and specified. If you’re an interaction designer, this is likely the phase with which you most identify. You may be sketching, creating wireframes, generating pixel-perfect mockups, and prototyping by various methods. These activities are well understood, and I’m going to make the assumption that I don’t have to explain the common activities of designers during the design phase any further. Instead, I’d like to focus on two things: the activities of our developer friends and design documentation.

Code Design

You’ll recall the “system status display: design” task that I stated was a developer task. The developers have a design phase also, and it can happen in parallel with the designer’s activities. During design, developers will be planning the architecture of the application. How is the functionality organized into objects, calls, variables, and other technical mumbo-jumbo such that the application can function efficiently and without errors? What patterns will be employed? What parts of the code are going to be componentized for reuse? What services should be made available? This is where some of that preliminary UI design work is going to be helpful to them, and you should keep the communication channels open.

Assuming you have a good working relationship with your developers, you should expect frequent interruptions as they gather the details to make decisions about their designs. Welcome these interruptions. If you become annoyed and give the impression that the developers are bothering you—that you’re too busy to care about their problems—they may just stop asking, and that’s the path to the dark side. Regardless of how much work you have to do to meet your deadline, it’ll all be for naught if the developers make uninformed decisions that preclude the interactivity you’re envisioning. A fair amount of negotiation may have to happen as they fully realize the implications of your initial concepts. You may end up making significant changes or reversing direction on certain issues, and that’s okay. Remain flexible, make smart concessions, and pick your battles. Remember my advice from Chapter 2, and you’ll come out smelling… well, not so much like roses—maybe more like pizza and Mountain Dew.

If your team is doing contract work for a customer, you’re likely going to have a design review before implementation begins. You’ll be presenting your UI designs for approval, and the developers will be presenting their design as well. I often offer my graphic design skills to the developers for key architectural diagrams that we feel are especially important for the customer to understand. I’ve created state change diagrams and data flow diagrams for them that more effectively communicate the issues we’re dealing with, such as race conditions, than UML diagrams do and help them understand the options we present and our recommended solutions. If you or other members of your team are visual designers, I recommend planning some time for such work. After all, it’s a team effort, and improving the developers’ part of the presentation is going to benefit everyone.

Documentation

If you’re a devotee of Lean UX or Agile, you may not have much use for documentation. We may just have to agree to disagree, but please hear me out. Even if you consider a design specification document to be the ultimate evil, there might be something here you’ll find beneficial. Given the work I do and the customers I do it for, documentation is a necessity. I have to document the UI design so that it can be communicated to and understood by our customers. I have to document UI behaviors so that they’ll be correctly implemented by our developers and validated by our testers. I have to document my own decisions so that, six months from now, when a question is raised about a particular function, and I’m neck-deep in a different project, I can explain what issues were raised, what options were considered, and what outcome was reached. I don’t know about you, but after working through multiple iterations, I sometimes have trouble remembering what we ended up with, let alone how we got there. I’m aware, however, that a lot of organizations generate too much documentation that’s never referenced; hence the backlash against it. I caution you not to throw the baby out with the bathwater. My slogan is “documentation in moderation.”

The key is to design your documentation for its intended audience. If you have to communicate your design to the customer, you don’t need to create a document that details the UI at a granularity needed to implement it. You’re likely going to want something that presents the design from a task-based perspective. There may be a fair amount of narrative.

On the other hand, in a specification document intended for a developer, you need something that’s more concise and easily referenced. While the developers will benefit from understanding the task flows, they shouldn’t have to search through a narrative explaining how the user works through a sequence of steps to find out what state the UI should be in when a particular radio button is clicked. Here are a few basic guidelines for creating documentation that developers will not only use, but will come to depend on:

• Design documentation to be a reference tool. Don’t write your documentation with the expectation that it’ll be read start-to-finish. Treat it as a reference that the developer will consult as needed. Any given developer is only going to need certain parts of it. Number your pages. Use clear section headings. Create a table of contents. Organize it in a way that makes sense for the project team, rather than for the customer or the users. This may mean that functions are documented based on location, rather than in task order.
• Always reference the requirements. If your team is correctly using tools like JIRA to track requirements, feature requests, bugs, and the like, there are going to be reference numbers. Use them in your documentation. Traceability between project documents, both the team’s and the customer’s, helps ensure that nothing is missed or lost.
• Be concise and explicit in your explanations. A design specification shouldn’t be an exercise in creative writing; it’s a set of instructions that are to be followed. Furthermore, it shouldn’t leave room for interpretation. Consider the following description: “When the user clicks delete, a confirmation dialog opens and asks them if they are sure they want to delete the item. If they press ‘Yes,’ close the dialog and remove the item from the list. If they press ‘No,’ close the dialog without deleting the item.” This explanation may be understandable, but it contains a lot of superfluous verbiage while leaving out important details. We can assume that it’s “the user” who is clicking the button. We can also assume that the developer understands what a delete confirmation dialog is and shouldn’t have to explain how one works every time it’s invoked. The description doesn’t state how the software knows which item is to be deleted, and it doesn’t specify that it’s referring to a delete button, rather than a link or other control. Here’s a better way to specify the interaction: “When Delete button is pressed, display confirmation, then remove selected item.” The sentence wouldn’t score you an A in your high school English class, but that’s not its purpose. It succinctly and accurately describes the interaction in a minimal number of words. It’ll take some practice to train yourself to write this way, but eventually, you’ll do it naturally, and it’ll save time both in the writing and reading.
• Label screens effectively. It goes without saying that your documentation should include sketches, mockups, or screenshots (depending on what you’re documenting), but to capitalize on the utility of the document, you should label your screens effectively. First, number your figures for easy reference during phone conversations. Second, label elements within the screens that are being specified. Many designers drop letters or numbers onto their screens with corresponding references in the text. This turns your UI into a puzzle that must be deciphered. I prefer to draw arrows to the elements that are being specified, labeling them directly and providing the essential information about each one. This is extremely useful as a reference, because the developers don’t have to peruse a paragraph trying to find the one piece of information they need. Try to avoid diagonal lines. Keeping your lines vertical and horizontal will result in a more orderly display. If you must use diagonal lines, try to maintain a consistent angle. Also, avoid crossing lines. Use a contrasting color that isn’t prevalent in your screens (e.g., bright red) so that they stand out. Using a grid to align information around an image will keep your page organized and easily scannable. Following all of these suggestions will make it quick and easy for developers to get what they need out of your screens.
• Be thorough. Make sure you include all of the necessary details. Forms for entering information are common in most software, and while they may not be the hardest part to design, they’re often the most tedious to document. Every field, menu, and checkbox has a slew of potential attributes. What is its initial state? Is it prefilled? Does it validate its content? Is it required? Does it have any behavior on focus? On change? On blur? Good design documentation doesn’t leave a developer guessing.
• Be consistent. Every specification document you deliver to your developers should follow the same conventions. This isn’t to say you can’t make improvements, but you won’t improve productivity if the developers have to relearn how to use your documents every time you deliver one. Your organization should develop templates for each type of document you use, and every designer should use them. Consider each document type to be a tool that must be learned, utilized, and maintained. Design documentation should be reviewed for quality, completeness, and adherence to standards just as you critique UI designs.

The labels are descriptive, rather than specifications, pointing out features mentioned in the heavy narrative to the right of the screen mockup.

Interesting Moments Grid

An excellent example of documentation that has been designed specifically for use by developers is the Interesting Moments Grid (IMG). Invented by Bill Scott at Yahoo!, the grid breaks down complex interactions into their individual actors and steps, clearly representing each change in state that occurs. The columns of the grid represent the events that occur during an interaction in order from left to right. Every actor in the interaction is given a row in the grid. For example, Figure 3.12 shows a multiselect widget documented in an IMG.

As you can see, the grid makes every attribute of the interaction immediately apparent. It’s easy to create (you could even do it in Excel—I wouldn’t, but you could), and it enforces a level of rigor, in that an empty cell indicates that something may be missing. After introducing the grid to my developers, they encouraged me to indicate state in every cell, even if it hasn’t changed, as that way, it’s apparent that nothing has been left out. I decided to use text color to indicate when changes in state happen. For more on the IMG, see Bill Scott’s slide deck, Designing for Interesting Moments, and Jared Spool’s article, Capturing the Interesting Moments.

Minimum Required Documentation

While I obviously disagree with Lean UX proponents who have declared design specification documents to be worthless, I’ll agree that we should reduce documentation to what is essential. This is right in line with the primary goal of this book: to get designers to implement their designs. You see, if you’re the one who will be turning your screen mockups into HTML and CSS, then there’s a lot less specification for you to do. You know what color an element is going to be. You know how much spacing to put between elements and what font size to use. You know what is supposed to happen when the cursor hovers over a button. Since you already know all of those things, there’s no need for you to include them in your specification document. I only document that which a developer will have to implement or the customer has to approve. Button hover states are a detail that the customer typically isn’t going to think about (unless they notice that they are missing) and that I’ll be creating with CSS—no developer needed. I never document hover states unless they’re communicating something more than that a button is clickable.

Nothing on the page would be necessary if the UI were implemented in HTML and CSS.

Implementation

I get most frustrated when, after providing a pixel-perfect mockup, I see the finished implementation during the testing phase, and it’s drastically different than what I spec’d (fonts, colors, sizes, spacing, alignment, positioning, etc.).

This comment, shared by one of the survey participants, illustrates exactly why every designer working on software should be breaking down the door to participate during the implementation phase of a project. As I explained in Chapter 2, we can’t expect the developers, who haven’t had the visual or experiential training that we have, nor possess our sensibilities, to pick up on every nuance of a mockup or prototype. Excuse my bluntness, but if you’re handing off your design to a developer and not seeing anything until the testing phase, you’re doing it wrong.

It’s vital for designers to remain involved throughout the entire development process, including implementation. Delivering a design specification to the developers is a major milestone, certainly, but it isn’t the end of your work. As the developers are implementing the UI, there will be issues that arise requiring additional decisions and further tradeoffs. Designers should keep tabs on the process the developers are making, patiently pointing out any discrepancies and explaining how to correct them. If you’re using a task-tracking tool, you can watch the developers’ implementation tasks to receive notifications about their progress. Developers will typically record comments about challenges they’re facing and options they’re considering. You can stay abreast of potential changes and contribute to the dialog when you have relevant input.

Communication is very important, but it’s only going to get you so far. If you truly want to remain in control of the user experience, and I’m adamant that you should, then you should be implementing the UI. And that brings us to the million-dollar question, described by Jared Spool in his article “Why the Valley Wants Designers That Can Code”:

If you’re in a room filled with designers, bring up the topic of whether it’s valuable for a designer to also code. Immediately, the room will divide faster than Moses split the Red Sea. One side will tell you coding is an essential skill, while the other will vehemently argue how it dilutes the designer’s value.

Jared Spool is proven correct by the IxDA LinkedIn group discussion that raged for over a year with 480 comments, as well as more recent debates like this one, which occurred as a disparate series of blog posts:

• “Unicorn, Shmunicorn—Be a Pegasus,” by Wayne Greenwood.
• “‘Designers Shouldn’t Code’ Is the Wrong Answer to the Right Question,” by Joshua Seiden.
• “Thoughts on Code, Programming, Design, Production, Development, Technology, and Oh! Design,” by Dave Malouf.
• “Design, Production, and Craft—What Do Designers Make?” by Matt Nish-Lapidus.

Do designers need to code? There are plenty of opinions and convincing arguments both for and against. I certainly know many very talented designers who don’t know how to code who are extremely successful, so apparently designers don’t need to code. My own conviction is that this is the wrong question altogether. Rather than asking whether we need to code, we should be asking, “Will learning to code make me a better designer?” The answer to that question is going to vary from person to person, depending greatly on context: the type of work you do, the type of firm you work for, the makeup of your team, and what you want to do in the future.

I surveyed the LinkedIn discussion, and all of the arguments against designers learning to code can be summarized in the following three perceived drawbacks.

Drawback 1: If you know how to code, you’ll be tasked with coding instead of designing.

Jennifer Tidwell, author of Designing Interfaces: Patterns for Effective Interaction, wrote in a post on her blog, “I found that when I tried to be both a designer and engineer/coder, I ended up doing a lot more engineering and a lot less design than I wanted to do. I think part of the problem is that engineering skills are, in the end, valued more than design skills.” There’s a real danger here, depending on the company you work for. If your company doesn’t value design, and they know that they can use you as another developer, then you may find yourself in the picture Jennifer paints. Of course, that will likely be one of many challenges you face. In that situation, you have three choices: live with it, try to change it, or leave for greener pastures. If your company truly values design, then your project schedules will be built with time for design. Tools like Microsoft Project plot out tasks in a Gantt chart, visualizing who each task is assigned to and dependencies on tasks assigned to others. If the designer is tasked with both design tasks and implementation tasks, the schedule will reflect it by pushing the implementation tasks out past the end of the design tasks. This is one reason accurate estimates are so important.

Now, some designers see coding as a chore. They don’t want to code because they don’t enjoy it, and that’s okay. As I already said, there are plenty of places for designers to work without having to do a lick of code. But don’t cite implementation tasking as a drawback just because you don’t want to do it. I enjoy implementing my designs. I get great satisfaction from implementing an interaction to look and behave exactly the way I intend it to, knowing that it’ll improve the user experience. As you’ll see in the latter half of this book, I also take great satisfaction from writing efficient, maintainable code. That takes nothing away from my enjoyment of design—rather, it enhances it. If I had to choose between performing only design activities and implementation, I would choose design in a heartbeat, but I don’t have to choose. I can do both, and everybody benefits.

Drawback 2: If you know how to code, you’ll limit your creativity due to the known difficulty of implementation.

This is a surprisingly common argument, albeit a weak one. The good news is that this one is completely in your control. Are you lazy? Are you a sub-par designer who isn’t passionate about delivering the best experience possible to your users? No, I didn’t think so. That type of person probably wouldn’t care enough to pick up a copy of this book, let alone read this much of it. I expect you have enough self-discipline to explore possibilities that you may not know how to implement, but can learn, while tempering your designs to avoid what you know to be technically infeasible. Don’t forget Will Jameson from Chapter 2. He’ll be happy to help you with any feasibility questions you have. I really don’t worry too much about implementation while I’m designing. Sure, I may realize that I don’t know offhand how to implement what I’m sketching, but rather than fixate on that, I shrug it off as a bridge to cross later. I have confidence that I and my team can figure something out. If we can’t, I’ll revise the design.

Drawback 3: You’ll marginalize your design skills to add coding skills.

This perceived drawback also goes by the label “Jack of all trades—master of none.” The basic idea here is that there’s only so much time to learn everything you need to know to be a designer. If you use some of that time to learn to program, you’ll have missed out on some of the design skills. You may be a good designer and a lousy developer, but you’ll never be a great designer, and you can’t be good at both. In that case, so the argument goes, you’re better off being a great designer and leaving code to others. People who make this claim are awfully short-sighted. There are too many variables to pin down exactly how long an average career is, but let’s say you spend 4 years as an undergraduate, take 2 years to get a master’s degree at some point, and retire at 65 years old. That’s going to give you about 40 years working in the field, which is a long time, and I hope you aren’t planning to rest on your laurels for half of it. While writing this very chapter, I completed my fifteenth year as a professional interaction designer. I’ve collected advanced skills in visual design, interaction design, and front-end web development. You can bet I’m not going to stop learning now. I’m hoping that my best work is yet to be done.

Of course, you have to start somewhere. You can’t learn everything all at once and expect to excel at everything. I started with visual design, earning a bachelor’s degree in graphic design. Then I went to graduate school for a master’s degree in interaction design. I have, of course, continued to develop both sets of skills during my employment, but over the course of those 15 years, I’ve also learned how to write HTML and CSS well enough to contribute to the production code base. I’ve specifically focused on that area in the past few years. There have been articles written in the past about the T-shaped designer. The vertical stem of the T represents deep expertise in one specialty (like interaction design or information architecture). The cross bar, then, represents shallower knowledge in adjacent areas (e.g., visual design or coding) that complement one’s specialty, rounding out his or her skill set.

It’s a good model for a junior designer, but why stop at T? Once you’re T-shaped, deepen one of those adjacent areas to become n-shaped. Then, deepen a third to become m-shaped. The order isn’t necessarily important, but I’d like to give you some advice here as well. From my own experience, and granted, my own bias, I recommend improving your visual design skills before moving on to code. Visual design and communication skills will be more beneficial to you as a UX professional than coding skills, and you should be able to visualize a UI design (not just wireframe it) before implementing it. I should also point out that there are certainly more potential ingredients for designer soup than the ones I have. Writing, industrial design, cognitive psychology, anthropology, library science, and business are all areas that you could potentially benefit from. Ultimately, you’ll have to decide where your interests lie and what skills you think will make you the best designer for your situation.

Ah, yes, I had mentioned context. Your context is extremely important. I have been working in a small software development firm. During most of my time there, I have been the only interaction designer. We don’t have a front-end developer, one who would specialize in HTML, CSS, JavaScript, and so forth without doing back-end server work. As such, I have always been responsible for both the visual and interaction design of our products, and it didn’t take me long to surpass our developers in my knowledge of HTML and CSS. I still leave the JavaScript to them. I know enough to edit it if I want small changes made, but I can’t write it from scratch. That’s where we have found a natural equilibrium of knowledge, interest, and time on task. Perhaps I’ll learn more JavaScript in the future, or it may make sense to leave that division as it is and pursue other skills instead.

That’s my context, but, as the survey results in Chapter 1 illustrated, there are many other contexts. There are a lot of firms that employ graphic designers and interaction designers as completely separate roles. Interaction designers create wireframes and collaborate with graphic designers who are responsible for the visual design. Likewise, there are many firms that employ front-end developers. If I were working in such a firm, perhaps I’d never have learned the implementation skill set I now have. You’ll have to decide for yourself whether coding is something you’ll find useful in your practice as a designer. Jared Spool, in his article “Why the Valley Wants Designers That Can Code,” has some wisdom to share on this matter (emphasis added):

Coding and designing are collections of skills. What we’ve learned is teams with a better distribution of skills, not segmented by roles, produce better results.

Don’t just think about your current position and current company when deciding whether or not learning to code is for you. Consider where you’d like to go in your career. Coding is a skill set that’s going to make you more capable of practicing design in a wider variety of contexts. It’ll make you more valuable and more attractive in most situations. The benefits far outweigh the perceived drawbacks I just refuted.

Also drawn from the LinkedIn discussion from which I culled the perceived drawbacks, here are the perceived 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.

To Code or Not to Code?

I’ve clearly laid out the pros and cons; now it’s up to you. Does it make sense for you to spend some time honing your coding skills? Actually, this isn’t an all-or-nothing question. Learning to code doesn’t have to mean becoming competent enough to deliver production-ready code. There are many directions it can take, and it’s going to depend greatly on your context. The following questions can help you decide.

• What’s your company’s technology stack? Spending a lot of time learning CSS is less likely to help you if your company primarily builds enterprise desktop applications in C++. You need to figure out what code you should learn. If you do a lot of web- and browser-based work, you should definitely start by getting a good grasp of HTML and CSS. Part II of this book can help you with that. It’d also be beneficial, once you’re comfortable, to add some knowledge of JavaScript, especially through the use of a framework like jQuery (see Chapter 9). A library such as Bootstrap will also be helpful. On the other hand, your firm may have invested heavily in Ruby on Rails or .NET, in which case, knowledge of those platforms may serve you better. If you’re developing native, mobile applications, there are other libraries, tools, frameworks, etc. that would be of greater use.
• What is your team makeup? Are you working with a bunch of back-end Java developers who only have a basic understanding of CSS? In that situation, you’re going to reap great rewards for doubling-down and growing your implementation skills. Do you have full-on front-end developers on your team? If so, your organization may not want you spending time on production code at all. If that’s the case, you’re probably looking for just enough know-how to prototype your ideas and play around with new technologies. That’s a lot less daunting of a hill to climb. Knowing enough to be able to copy snippets of code off the web and paste them into your pages will enable you to experience interactions that you wouldn’t otherwise and demonstrate them to your developers.
• What is your destiny? The fact that you’re in your current position with your current company working on its current products doesn’t necessarily mean that’s where you want to be or what you want to be working on five years from now. Educating yourself on coding is certainly something that can deliver immediate benefits, but you should be planning for the future. What do you want to be able to put on your résumé? What position do you wish to be able to apply to? What platforms do you hope to design for?

Whatever your decision may be, I hope this book helps you develop effective relationships and work practices with your development team. We have one more phase to address in the collaboration life cycle, after which, the remaining chapters will focus on production-ready HTML and CSS.

Testing and Evaluation

At the end of the implementation phase, a product must be tested against the design to ensure it works as intended. Hopefully you’ll be pursuing some form of usability evaluation to see if the working version is as easy to use as you thought it’d be. At the same time, the developers will be carrying out their functional testing.

Not to be confused with usability testing, functional testing is the phase in which the development team tests their implementation to make sure it works correctly. The team writes test cases, explaining the steps one should go through to thoroughly test a particular function and what should happen if it functions properly. Whenever there’s a discrepancy, a bug gets logged. Your design specification is a great reference when writing those test cases, so that’s one way you can assist the team, but there’s an even better way. As it turns out, designers make outstanding testers. We’re detail-oriented, so we notice everything. In addition, we use the system more like a user would, so we may run into issues that test cases don’t bring to light. Many such issues may not even be functional bugs, per se, but usability bugs. If we can catch some of these, log them as bugs, and get them fixed before formal user testing, so much the better. And then there’s the fact that we should know better than anyone how the thing is supposed to work. We’re the ones who designed it.

Just as designers can participate in functional testing, consider engaging some of your developers in user testing, especially field trials. The experience will give them a better appreciation of the users’ concerns. I’ve seen developers I work with develop true empathy for the people who are required to use our software. It’s one thing for you to tell the developers that the users had problems with this or needed that, but it’ll be even more impactful if one of their own is as adamant about usability concerns as you are.

And that brings us full circle. The collaboration life cycle is complete. The designer and developer fist-bump as the customer lauds them for another on-schedule, under-budget release of intuitive, bug-free software goodness. Alright, I can’t promise all that, but the fist-bump… that’s genuine. 

Discount for UXmatters Readers—Buy Bridging UX & Web Development and other Morgan Kaufmann titles on the Morgan Kaufmann site, using the discount code PBTY14, and save 25% off the retail price.