Great User Experiences Require Great Front-End Development
Published: April 24, 2012
With this article, we’re introducing our new column—Breakthrough Application Design—Designing game-changing experiences. In this column, we’ll discuss innovative approaches to application design that are based on our personal experience in the trenches.
How can it be that so many digital products fail deliver any inspiration when so many technology and digital media companies spend millions of dollars on design and user experience? Merely following user-centered design (UCD) practices by the book is not sufficient to create truly transformative digital products. In fact, despite UX teams’ following UCD processes, the digital product industry confronts this alarming paradox: More and more UX teams claim to follow user-centered processes, yet most digital products are mediocre or even substandard. And things won’t get easier. As interactions progress from clicks to taps and other gestures, traditional UCD processes will face even greater challenges. In this installment of our column, we suggest that one of the reasons for poor design execution is that UX teams need to own more than just design. We need to own front-end development. In fact, we argue that front-end development has always been more strongly aligned with design than with development.
Of course, we’ve all seen transformative digital products. Some products like Apple’s iTunes, Intuit’s Mint.com, Facebook, and Twitter have achieved high status in the consumer software world. The challenge is that these few iconic examples of well-designed digital products stand out in a landscape of poorly executed designs. We see more designs in the physical world that evoke delight—and are at the same time highly usable—than in the digital world. Take the experience of driving a Porsche, with its elegant curves, sounds, and overall experience, or that of listening to music on Bose headphones. Each of these products meets a very real user need, but more than that, they evoke a powerful emotional connection. When was the last time you felt a deep emotional connection to a digital product other than an online game or one of the few consumer products we mentioned earlier?
There are a lot of reasons why product teams deliver substandard user experiences. In some cases, Engineering vetoes designs or simply does not have the necessary skills to build transformative designs. We’ve seen this many times: a UX Design team comes up with a cool design, only to have it vetoed. If you’ve been in digital design for more than a few years, you’ve almost certainly run into this problem in one way or another. (If you haven’t, we want to work where you work!) This problem is pervasive, and it’s toxic to creativity. Fortunately, it’s a solvable problem: the UX team needs to own front-end development, for several reasons.
Why the UX Team Needs to Own Front-End Development
The foremost reason UX should own front-end development boils down to the alignment of skill sets. Front-end developers fall into a middle ground that most product development professionals do not acknowledge. On one side of the divide, designers get excited about delivering great experiences. They look for opportunities to create a great user experience or solve user challenges through novel designs and get excited when they find ways to do so. On the other side of the divide, engineers get excited about solving hairy technical problems—and whether their solutions impact users is always secondary. As long as the code solves the problem it was meant to solve, they expect users will be able to figure out how to use the product. If a Front-End Development team reports to Engineering, the team gets rewarded for solving back-end technology challenges. But front-end development is not about solving back-end technology problems. It should be about making sure a product’s user experience differentiates the product in its marketplace.
The second reason is a matter of ownership, and our desired ability to move as quickly as possible from a concept to a fully functional front-end prototype that users can validate. Some ten years back, an Executive VP at one of Jim’s previous companies taught him a valuable lesson: he said that if he did not own a resource, he could not trust that he could deploy that resource or that the resource would align with his vision and objectives.
So it is with front-end engineers. When they report into User Experience, they’ll optimize for the user experience, but if they report into Engineering, they’ll optimize their code to meet Engineering’s goals. It’s that simple. Of course, we believe in forming deep partnerships with our peers in Engineering, and there are some companies where having front-end developers report into Engineering makes sense. However, this is the exception and is the case only in companies whose UX practice is in the top 10% of the industry in terms of UX maturity.
If front-end developers report into User Experience, we can assign tasks to them and know that they will strive to meet our UX objectives. They will also meet our requirement for developing pixel-perfect representations of the designs that we give to them. Likewise, when a design idea does not make sense technologically, front-end developers within UX teams are more likely to offer new ways of solving the same problem that are more viable and robust rather than simply saying, “that can’t be done.” This isn’t theory. We’ll share several first-hand experiences.
We still love the book The Inmates Are Running the Asylum from back in 1999, because it rings true for today: Designers need to design. And, in our experience, Front-End Development teams produce more differentiated and robust user interfaces when they reside within a User Experience team than when under Engineering. When designers and front-end developers work together on the same team, under the guidance of design leadership, they get measured by their ability to execute on the implementation of great designs, not just creating technology for technology’s sake, regardless of whether it delivers any value to users. And isn’t that the goal in the end? Shouldn’t we first strive to meet user experience goals, then ensure that the technology can support our user experience goals?
Have you ever been part of a UX design team and delivered wireframes or a User Interface Specification (UI spec) to Engineering only to have them come back and say, “You can’t do that?” Or, have you delivered a detailed UI spec only to find that the resulting user interface differed in meaningful ways from your design? We find this to be more common than not in the software industry. Resolving such disconnects requires more time and negotiation, extends deadlines, and frankly, frustrates everyone who is part of the discussion, including User Experience, Engineering, and Product Management.
When UX teams are responsible for actually building the front-end, presentation-layer code—not just delivering visual representations that it may or may not be possible to build, they can deliver more innovative, delightful, and high-impact user experiences. Moreover, they deliver these superior experiences much faster and at a much lower cost—by an order of magnitude!
Incorporating Front-End Development, or Front-End Design (FED), as we call it, into traditional UX teams also encourages new ways of thinking about design. Our experience to date suggests that UX teams who incorporate FED into their practices will thrive better in the digital era. Why? The teams that can move from idea to functional, front-end code most rapidly can iterate much faster.
In Lean Startup,  Eric Ries suggests that the most successful businesses are those that can pivot most rapidly. UX teams that incorporate an FED function are able to pivot most rapidly, because they can leverage an iterative, parallel experimentation framework.  Regardless of whether they employ agile, waterfall, or lean development methods, they can validate their ideas, iterate on them, and generally respond more quickly to new business threats and opportunities.
In his book Inspired, Marty Cagan  argues that the only way to truly validate a concept in the marketplace is to create a functional prototype—not pictures stitched together in a PowerPoint presentation, but a product that interacts like the real thing—and get it in front of potential customers and users as early as possible. The goal of product managers should be to get their ideas visualized quickly, then iterated as necessary to make the biggest impact in their industry. Some of the most successful companies in the world don’t always show their early concepts to customers. Moving quickly from concept to a functional user interface enables UX Design teams to quickly evaluate complex interactions such as kinetics. Theory is just that. Some user interactions you just have to experience to internalize and successfully modify them.
UX designers cannot lead if they constrain themselves only to doing user requirements, wireframes, and basic prototypes. Design alone simply is not sufficient to lead in this new world.
What Is Front-End Design?
Front-End Design is a specific term that describes a set of competencies for individuals who work at the intersection of traditional front-end engineering and user interface (UI) design. A strong front-end designer should be able to:
- Understand, critique, and help improve a basic interaction model and wireframes.
- Create pixel-perfect page structures through front-end markup code.
- Apply visual styles through different visual layout technologies.
- Develop interactions using various interactive technologies.
- Experiment and create dozens of variations of typography and dynamic interactions.
- Understand why a product behaves the way it does.
- Keep track of emerging technological trends, understand their impact from a design perspective, and educate designers to empower them to design for the greatest, most up-to-date user experience possible.
An FED works within an engineering context, but serves the interests of the UX team. FED teams with these skills are starting to appear at companies like Facebook, Quora, LinkedIn, Twitter, HP, Yahoo!, and other companies.
Key Business Reasons FED Should Be Part of UX
There are several reasons why Front-End Design should be part of User Experience rather than part of Engineering. We’ll discuss some of these reasons here.
Integrating FED Improves Your Overall Ability to Innovate
In a marketplace that’s continuously in flux, sometimes the only arbiter of success is how fast you can launch, whether customers love your product, and how quickly you can pivot to keep launching things that people love before you run out of time or money. For UX teams to generate hundreds of innovations to test in the marketplace, they need to support their organization’s ability to innovate. A specific set of capabilities enables a company to innovate at the lowest cost and the highest scale and optimizes its creative effort. Often, in large organizations, the reality is that there are dozens of people playing the role of innovation manager who simply add layers of bureaucracy. In a democratic economy, where, in a sense, awesome products create their own markets, improving your ability to innovate means bringing two core functions that actually create innovations closer together: User Experience and Front-End Development.
Integrating Front-End Development within User Experience enables you to work better with other core functions and assess and evolve hundreds or even thousands of ideas without collapsing the organizational infrastructure.
Creating Scalable Designs Enhances Users’ Productivity and Increases Product Adoption
While UX designers generally do a good job of driving customer adoption by optimizing things like total numbers of clicks and total numbers of pages in flows, they are rarely able to accurately assess how a design will scale when a user interacts with a running system comprising hundreds of interactions and objects. For example, UX teams often design data grids, or tables, to show a dozen or so entries, often formatted for ideal conditions. While this may seem like a trivial design problem, a running system should be able to display many hundreds of values in a data grid. Within the context of internationalization, complex values in tables can present display problems.
Front-end explorations during the design wireframing process can help ensure better product adoption by more realistically simulating a product’s functionality. Optimizing hundreds of interactions and data transactions before writing any actual back-end code improves the chances that users will adopt your product for the productivity enhancements it offers at scale.
Lowering Coordination and Transaction Costs Accelerates Product Development
A key challenge is overcoming the difference between good enough and outstanding. Often, when designers hand off a design to the Development team, as shown in Figure 1, the developers produce a user interface that they think meets the general requirements that the designers documented in the UI specs. Unfortunately, in our experience, when we let developers interpret our design specifications, they virtually always fall short of our expectations.
Figure 1—A traditional User Experience / Engineering engagement model
Why does this happen? Although engineers understand and have had training in back-end technologies, most are not trained in the newest front-end technologies. One reason is that front-end technologies change and evolve quickly. But a bigger reason is that engineers are typically rewarded for having expertise in solving deeper, back-end technology problems such as database issues. While the front-end presentation layer presents as many development challenges as the back-end technology, engineers generally seem to think that the human-machine dialogue has less significance than that which occurs between machines. But, in reality, if we expect people to interact with user interfaces that we have not built to optimize every aspect of their experience, our products will fail in the marketplace.
When Front-End Development is part of the User Experience team, as shown in Figure 2, front-end developers can act not only as a mediation layer between UX designers and back-end developers, but also as a catalytic layer, helping both groups to achieve their goals faster.
Figure 2—Engagement model with Front-End Engineering integrated into User Experience
Two Examples of the Successful Integration of FED into UX
Now, let’s look at two examples of the successful integration of Front-End Engineering into User Experience.
Our first example comes from a consumer Web company—specifically, a development project for a very popular communications product with over 300 million users. This company had a strong design culture and a history of creating good user experiences from its inception in the 1990s. However, in recent years, the company has evolved into a more engineering-centric culture, as is typical of large companies. So, over the past few years, the company has had to rethink how to keep its communications product relevant and competitive with many new innovators in the marketplace.
The main problem in rethinking any product within such a context is that an engineering-driven culture often makes it difficult to experiment with new ways of thinking about the design process. Even when designers deliver detailed wireframes and UI specifications, once engineers start building the actual user interface, much gets lost in translation amid the transitions from the design to the actual, working front end. Even exceptional screen designs can get reduced to average user interfaces when engineers make ad hoc design decisions during implementation. Often, this happens at a late stage of development, when it is too late to rectify the problems because of tight schedules and fixed roadmaps.
In 2010 and 2011, after the company set the goal of redefining their communications product, the core team recognized that their conventional approach to implementing UX designs would not work. Hence, they started working with a completely different UX team structure, consisting of one Design Director, two designers, and two prototypers/front-end engineers. Additionally, it was very important to blend this new system with a highly agile engineering process. This system involved 2 parts:
- a new UX infrastructure—This enabled designers and prototypers / front-end engineers to collaborate on design artifacts more dynamically. Also, the infrastructure allowed the creation of running prototypes—which used dummy data that simulated back-end systems—rather than static screens. The designers used this approach to experiment and come up with new interactions and visual styles. These prototypes also served as reference implementations that allowed us to validate our assumptions with product managers, marketers, users, and other stakeholders.
- a code check-in process—This allowed front-end engineers to check in production-quality code to the actual Engineering code repository. Since UX teams could now deliver presentation-layer code, including screens and interactions, it became possible to truly decouple the front end from the business logic. Engineering could focus on other important aspects of the application, such as scalability, security, and performance.
This team not only defined detailed interactions and visual designs for the product, but also prototyped the entire front end, or presentation layer. This meant they could deliver actual pixel-perfect, front-end code instead of design documents.
After nine months of product development, some concrete benefits of this approach became apparent:
- The team reduced front-end development time by 30 to 40%.
- The UX team’s tight control and ownership of front-end development enabled them to realize the desired fidelity and richness of the intended design.
- They created more standards-compliant front-end code that they could actually use in the product.
- They validated and progressively evolved the product by iterating on a real, working prototype.
- Given this new infrastructure, both UX designers and front-end developers generated a greater number of design ideas.
Our second example is from a new software division at a Fortune 20 technology company. In 2011, the company created a new business unit to build industry-vertical software products, in markets with strong incumbents and customer preferences—for example, the consumer travel industry. The challenge was to create a user experience studio that would help take user experience and design to the forefront in this industry.
The team started with a clear idea of their top five UX goals: Discoverability, Learnability, Efficiency & Action Orientation, System Performance, and User Delight. However, during the first few months of the project, they realized that, to achieve these UX goals, they would need not only to establish their product vision through a cutting-edge interaction design model and actual screen designs, but also to develop the ability to test this model for robustness and scalability. In working with global airline customers and the Product and Engineering teams, they realized that simply showing them good wireframe designs and visual styles was not enough; stakeholders needed to see a living, breathing product before they were even able to tell us what they needed.
This led the UX team to design their organization in a very different way from they way UX is typically structured in most Fortune 500 technology companies. The team was distributed globally—between the US and India—creating a broader talent pool, with deep expertise in interaction design, visual design, prototyping, and front-end development at both locations. This mix of skills let the team create a funnel from user requirements, wireframes, visual comps, and prototypes, to reusable UI components, and finally, to presentation-layer code.
Roadmap: How to Bake Front-End Development into Your UX Organization
Integrating a Front-End Design team into your User Experience organization is not just about finding the right people with the right competencies. It is about setting up a structure that enables rapid experimentation, a greater number of design iterations, deep collaboration between UX designers and front-end developers, and strong linkages between front-end developers and back-end developers. We propose a four-step process that lets you establish a strong foundation for integrating Front-End Development with a UX team.
Step 1: Hire a Front-End Team with Hybrid Skillsets
Hiring a Front-End Design team within an existing UX team is a non-trivial challenge. Expect some resistance from designers who are used to traditional models of working with Engineering. Also, expect some insecurity on the part of front-end designers themselves about reporting into a UX chain of command. We recommend the following:
- Hire front-end talent with a hacking and tinkering mindset, who are passionate about creating great products.
- Design an interviewing and testing process that is geared toward gauging creativity, the ability to write good code, teamwork, and an obsession for detail.
- Front-end design involves both look and feel and behavior. It is important to hire talent with skills in both areas.
- Hire people who are comfortable sharing their work and getting it critiqued. One way of doing this is to check whether your interviewees are active in the open source and tech support communities.
- Leverage student interns if you can. They bring an amazing freshness of perspective. Most graduates today have had deep exposure to consumer Web applications and, thus, are immediately able to contribute to actual product designs.
Step 2: Set Up an Experimentation System Leveraging the Latest Technology
Given the pace at which front-end technology choices are evolving, both UX designers and front-end developers must be able to learn continuously and update their product and technology assumptions, so they can offer users the best experience possible. This front-end infrastructure is an example from the world of Web applications, and variants of it are in place at Twitter, LinkedIn, Storify, and other companies:
- templating frameworks—for example, Mustache, Embedded JS, and Smarty
- a lightweight scalable server like Node.js
- open, standard technologies like HTML and CSS, SMACCS,  Bootstrap,  and LESS 
Step 3: Enable a Loosely Bound Process with Designers
Because the goal of a User Experience team is, ultimately, to produce highly differentiated, even unique products, a UX team needs an atmosphere that combines open collaboration around novel ideas with disciplined execution on the production of those ideas. In other words, great UX needs both outstanding design and rigorous front-end engineering. We recommend the following guidelines for creating an integrated team experience:
- colocation of UX and Front-End Design teams in a common studio space
- availability of next-generation platforms such as tablets, gaming systems, and multiple operating systems
- frequent knowledge-sharing sessions on both UX and front-end topics, so everybody shares a base literacy
- an emphasis on rapid sketching and fast coding to maximize your numbers of iterations and variations.
- minimizing busywork like creating UI specs and PowerPoint presentations for meetings
Step 4: Follow a Tightly Bound Process with Developers
The goal of a good Front-End Design team is to make UX designs a reality by working closely with designers and, simultaneously, to make the final product a reality by working just as closely with Engineering. Most engineering is ultimately a systematic, problem-solving process—whether for enterprise or consumer product spaces or following traditional or agile development models. Front-End Design teams should complement Engineering by
- becoming familiar with the engineering technology stack and making designers aware of the constraints and opportunities that stack presents
- setting up formal code and architecture reviews between Engineering and the Front-End Design team to ensure consistent quality
- following Engineering’s code check-in model and using their code repositories
 Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. New York: Crown Publishing Group, 2011.
 Dow, Steven, Julie Fortune, Dan Schwartz, Dan Athringer, Daniel L. Schwartz, and Scott Klemmer. Prototyping Dynamics: Sharing Multiple Designs Improves Exploration, Group Rapport, and Results. Stanford: Stanford University, 2011.
 Cagan, Marty. Inspired: How to Create Products Customers Love. Silicon Valley, CA: SVPG Press, 2008.
 Scalable and Modular Architecture for CSS (SMACSS)
 LESS CSS