This is a sample chapter from Jack Moffett’s new book, Bridging UX & Web Development: Better Results Through Team Integration. 2014 Morgan Kaufmann.
Chapter 3: Collaboration Life Cycle
Process. Regardless of what type of designer you are—graphic, information, interaction, service, industrial, game—you follow a common process. It typically begins with research and observation as you learn about the people who will use the product of your efforts and the context of its use. Then there’s synthesizing of the information you’ve collected, coupled with ideation and iterative prototyping, as you plan what is to be built, physically, digitally, or figuratively. Ideally, this also involves some form of testing with users to verify your rationale. As I illustrated in Chapter 1, this is where many of us stop, passing our specifications on to the developers who will implement the work. There are also varying degrees of participation in following phases of testing, bug fixing, and further documentation. Of course, there are sundry variations, Agile and Lean UX being the most notable, but the same activities are involved (or should be).
Let me stop here for a moment to address the Agile elephant, because if I don’t, I know it’ll stomp ominously about the periphery of the room and distract us from important matters. I don’t follow an Agile process most of the time, although I’ve worked on projects that did. I don’t have problems with the Agile philosophy, as I understand it, and I have a lot of respect for my peers in the industry who have been successful at adapting their design practices to it. If you find yourself working in an Agile environment, I recommend that you check out one of their books on the matter. I’m not an expert on Agile methods, and this book will not specifically address them. That said, I consider the collaboration life cycle I describe here to be somewhat process agnostic. I believe that designers should be involved in every phase of development, and whether your organization follows a waterfall model, Agile, or something in between as mine does, you should be thinking about how you can incorporate the following activities into your process. To read more of my thoughts on Lean UX, I invite you to visit my blog, DesignAday, where I’ve addressed the topic in some depth.
During the first phase of a project, designers are learning as much as they can about the domain. We’re doing whatever kinds of user research that time, the budget, and the client allow. We may be creating personas, writing scenarios, or any number of other information-gathering and synthesizing tasks. There’s a lot to do, and it’s easy for us to forget about the developers during this time. After all, this is where UX professionals shine. We realize the importance of ensuring that we’re building the right thing. But we shouldn’t ignore the developers, busy though we may be. They’re collecting their own information, and we should be aware of their findings, as their decisions can greatly affect what can and can’t be done.
Requirements can come from many places. If you’re a subcontractor to a primary government contractor, you’re probably familiar with the functional requirements document (FRD) that details all of the functions of the desired software. If you work in a software development firm that markets its own products, you may have received a marketing requirements document (MRD). If you work for a design firm, you may have encountered an enlightened client that realized that they didn’t know exactly what they needed, and they relied on you to help them define their requirements. Regardless of where your requirements come from, it’s imperative that you and your developers arrive at a shared understanding of the requirements.
Let’s say, for example, that your client has a high-level FRD outlining the basic functionality they want in a custom web application. Everyone on the project team should be familiarizing themselves with the requirements. You’ll be reading them with an eye out for use cases, usability challenges, and utility, given your current understanding of their domain. Meanwhile, the developers are analyzing the requirements based on their own concerns. They’ll be identifying technical challenges—features that will be more difficult or time consuming to implement. I’m reminded of the scene in the movie Apollo 13 where the NASA engineers had to figure out a way to join the cube-shaped lithium hydroxide canisters from the command module to the lunar module’s cylindrical canister-sockets using only materials found onboard: “We’ve got to find a way to make this… fit into the hole for this… using nothing but that.” It was the proverbial square peg in a round hole.
Photo courtesy of NASA.gov.
Technical challenges, and the approaches that the engineers decide to take, can drastically affect the amount of flexibility we have in designing the UI. We need to be aware of these challenges before we run headlong into them for two reasons. First, we don’t want to waste a lot of time working on a design that has already been technically invalidated. Second, we don’t want to contribute to the developers’ headaches. This requires regular communication with them. Attend status meetings, keep tabs on wiki posts, and listen in on water-cooler conversations. You have a real opportunity here to ingratiate yourself with the team. Be part of the solution, rather than an aggravation of the problem. If they already know that a certain screen is going to cause performance problems, rather than blindly designing the screen in a way that compounds the issue, you can choose to learn about the problem and try to mitigate it. You might even be able to think of a different way of presenting the information that avoids the problem altogether.
When faced with a technical hurdle, developers will often create a proof-of-concept to test an approach or try out a toolkit. As I mentioned in Chapter 2, you should understand these for what they are—don’t judge them as you would a design prototype. You may even be able to help with them, depending on what is being tested. For example, providing a basic UI or content display for a performance proof-of-concept could be useful. My team has had to meet strict, one-second performance requirements for delivering a screen full of data, and while retrieving the information from the database is the most important part of that, the rendering of the page in the browser plays a significant role as well. I could stick to my sketches and leave the developers to “their problem,” but if I can help them shave off time by reducing the amount of DOM manipulation being done, I’ll be considered an ally.
Another developer activity during this phase is the identification of the technology stack that will be employed on the project. This is also a matter of importance to designers. Technologies come with limitations—limitations that we have to endure as we design around them. More importantly, they’re limitations that our users will have to live with. Designers need to be involved in these decisions. If your development team is considering GWT as the framework for building the front end, you had best be doing some research into its capabilities and limitations and making your opinion on the matter heard. How do you feel about the UI widgets included in GWT’s library? Will they be easy to customize? Would Bootstrap and jQuery be a better approach? You’ll have to learn what problems the developers think GWT will solve for them if you want to convince them of a different approach. If you choose not to participate in such decisions, you have no right blaming the developers for the resulting limitations later.
Have you ever been assigned to a project after the schedule is set? Maybe somebody unqualified decided how much time would be given to UI design, or perhaps they didn’t account for it at all. It isn’t a pleasant situation to be in. While I’m occasionally still asked to provide the design of a small change to an application at the last minute, I’m always asked to provide estimates for projects of any significance before a contract is signed. UX designers, especially those with an artistic background, are often uncomfortable doing this, but we don’t help ourselves by claiming that we can’t confine design to a schedule or that the creative process is too fuzzy to quantify. If we’re to be taken seriously, we must do our best to support project management and help our teams deliver on time and on budget.
It’s incumbent on designers to practice estimation and improve accuracy. To do this, you must be very conscious of how long it takes you to complete small, bounded tasks. Larger tasks, which may seem impossible to estimate, can be broken down into smaller tasks that can be managed. You should get in the habit of doing this, rather than throwing out random numbers from your gut that you don’t know you can hit. It also requires that you track the amount of time you spend on each estimated task and compare the time you spent against your estimate. This is something that developers are experienced at doing, but designers haven’t historically been required to do—certainly not in as strict a fashion.
There are tools that developers and project managers use to track actual hours against estimated hours. I recommend that designers use the same tools. As you can see in Figure 3.2, only 13% of the survey respondents are currently doing so. Project-tracking and management software allows a team to create tasks, give each an estimate, and assign the tasks to people. My company uses Atlassian’s product, JIRA, in which I enter all of my design and implementation tasks.
I provide estimates for my tasks, and as I work, I log the time I spend against each task. When I close a task upon completion, I can see whether I came in over or under my estimate. Once you’ve done this over the course of several projects, you’ll be able to refine your estimates. Your estimates will be more accurate, and you’ll be able to estimate your tasks more quickly. You’ll develop better instincts for what will make certain tasks take longer than others, and you’ll learn what questions you need to answer to make accurate estimates. Improving your ability to estimate will make you a better team member and increase your value to your company.
A project manager can use the reporting capabilities of the tool to track the overall progress of the team. There are different methods of doing this, of course. One common example is an hour burndown chart, which graphs out the number of estimated hours for the entire team against the number of hours logged, while also representing the number of hours the team must work each day to meet their deadline, the number of hours the team is actually working, and projecting an actual completion date. Depending on the project, the manager may or may not include the designer in these calculations. If I’m not on the critical path during implementation, there’s less value in my inclusion. If I’m expected to be the long pole in the tent, however, my inclusion is very valuable indeed.
The red, diagonal line represents the optimal progress against the tasks to hit the deadline exactly. The green line shows how many estimated hours are left. It should stick close to the red line; if it drops below, so much the better. The blue line indicates the cumulative amount of time the team has spent working on the project and should be the opposite of the red and green lines. The orange line at the bottom shows the number of hours the team must spend each day to make the delivery. We want that to stay low. The yellow line at the top tracks the accuracy of the team’s estimates, so we’d prefer that one to stay high.
So, designers can assist the team by entering their own estimates, but let’s not stop there. We can have a bigger impact by improving the accuracy of everyone’s estimates. Now you may be asking, “How am I supposed to know anything about how long it’s going to take developers to complete their work?” I’m not suggesting you estimate the developers’ work, but designers are in a position to increase the accuracy of the developers’ estimates. You see, developers are estimating how long it’ll take them to implement parts of an application. For their estimates to be at all accurate, they need to have some idea of what they’ll be implementing. This is another opportunity for designers to be extremely helpful to their developers. One of the survey respondents provided the following frustration in his or her comments:
Ideally, the developers and I are to work closely together during the design phase… but it typically works out that they gloss over the document or attend a few meetings and get a basic understanding of what we’re planning on doing, but never pay attention to the full details. Then they tend to come to me with questions or “Are you crazy? I can’t do that!” when it’s time for them to put together a timeline for their development assessment. After a few times of close calls, they’re beginning to pay more attention to the pencil sketches and overall workflows we put together for them.
I sympathize with this person, but I also believe he or she bears part of the blame. Rather than assume that developers will seek out your design documentation, read all of it, and correctly interpret every detail, you should actively approach the developers and schedule time to sit down and review designs together. And you shouldn’t wait until the design phase to do so. For projects in which I’m involved, we often include time during the requirements phase for initial concept sketching. We’ll select some of the more nebulous requirements and do upfront design work so that we have a general idea of what the solution is going to entail. I’ll review rough pencil sketches with the developers, explain what I’m thinking, and get their input on the technical feasibility of my proposal. This gives the developers a better foundation for creating accurate implementation estimates, and it avoids those contentious debates during implementation in which design vision is compromised to reduce schedule overrun.
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.
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:
System status display: design
System status display: implementation
System status display: UI design
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.
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.
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.
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.
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:
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.
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 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.
With a BFA in Graphic Design from West Virginia University (WVU) 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. At Inmedius, a Boeing Company, Jack’s responsibilities as a Senior Interaction Designer cover the gamut from initial user research and product conceptualization through to implementation and testing. 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 US military, including Joint Service Explosive Ordnance Disposal, Naval Reactors, and NCIS. Jack has spoken at conferences and led workshops, teaching designers how to integrate with their development teams and participate in implementation, and he co-founded IxDA Pittsburgh. Jack is the author of Bridging UX and Web Development: Better Results through Team Integration. Read More