Great User Experiences Require Great Front-End Development

By Jim Nieters, Amit Pande, and Uday M. Shankar

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.

“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.”

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

“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 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 best front-end developers think and talk using design language more than tech talk. To be sure, HTML5, CSS3, and JavaScript require some technical skills. That said, most software engineers believe—but seldom say—that JavaScript is not a complex language, and very few stress their knowledge of front-end technologies. More than this, most Engineering organizations reward employees who grow their deep technology skills, not those who excel at front-end development. From a cultural perspective, great front-end developers are typically not part of Engineering’s inner circle. Because people improve their skills in areas for which they’re rewarded, most engineers are not great at front-end development. They focus on back-end development and their front-end skills atrophy.

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.

Front-End Development teams produce more differentiated and robust user interfaces when they reside within a User Experience team than when under Engineering.

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, [1] 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. [2] 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 [3] 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?

“A strong front-end designer should be able to understand, critique, and help improve a basic interaction model and wireframes.”

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

“improving your ability to innovate means bringing two core functions that actually create innovations closer together: User Experience and Front-End Development.”

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

“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.”

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

“Project management methods are very different in User Experience and Development, and often the two teams’ mindsets differ greatly. This often causes friction between User Experience and Development teams….”

Clashes between UX designers and developers are the stuff of legend. UI specifications don’t always work well. Specifications can encounter serious translation issues. Production code for front-end technologies—whether HTML, Flex, or JavaScript—evolves frequently. Project management methods are very different in User Experience and Development, and often the two teams’ mindsets differ greatly. This often causes friction between User Experience and Development teams and increases overall coordination efforts and, hence, costs.

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

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

Engagement model with Front-End Engineering integrated into User Experience

Two Examples of the Successful Integration of FED into UX

“An engineering-driven culture often makes it difficult to experiment with new ways of thinking about the design process.”

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.

All stakeholders have greatly benefited from this integrated approach to UX design and front-end engineering. The global airline customers were able to participate in the design process more effectively because of the team’s use of prototypes for frequent validation. Engineering and Architecture stakeholders have benefited by receiving presentation-layer code—HTML, CSS, and JavaScript—that they could simply plug into their back-end systems, as well as reusable code for common UI controls. Product strategists have leveraged the team’s many innovations to generate new business at trade shows. Though the team is still in the early stages of this experiment, the results so far suggest that this hybrid approach is much more effective than the traditional UX design team.

Roadmap: How to Bake Front-End Development into Your UX Organization

“Integrating a Front-End Design team into your User Experience organization … is about setting up a structure that enables … deep collaboration between UX designers and front-end developers, and strong linkages between front-end developers and back-end developers.”

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

“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.”

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, [4] Bootstrap, [5] and LESS [6]

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.”

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.”

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

References

[1] Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. New York: Crown Publishing Group, 2011.

[2] 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.

[3] Cagan, Marty. Inspired: How to Create Products Customers Love. Silicon Valley, CA: SVPG Press, 2008.

[4] Scalable and Modular Architecture for CSS (SMACSS)

[5] Bootstrap Framework

[6] LESS CSS

8 Comments

Your article summarizes a lot of points I’ve experienced working as a UX designer for a software development company.

I’ve written a blog post about my experience with Agile and UX.

It’s nice to see that many of your roadmap points match my observations.

The only thing I didn’t really like was the use of yet another acronym (FED) for an industry that’s full of them. Other than that, really nice read!

I’m not sure why you’re referring to front-end developers as front-end designers. They’re two different things. It just muddles the field of UX even more than it already is.

I realize this article is about creating a new type of team, but some of these qualities of a front-end developer in a UX team need more clarification. For instance, these three seem at odds with each other:

  • “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.”

It sounds like you’re suggesting teams hire a visual designer who can code, or am I missing something?

The student intern idea is okay, but only if you pay them and pay them what they deserve.

Fantastic article.

I found myself nodding in agreement throughout it. It’s nice to read a piece about front-end development, like that, especially when I’ve experienced both sides—as a UI/UX Designer, and now as an Engineer.

Classifying this relatively new role and saying what skillsets they should and should not have is very hard. It’s always changing, and every company has their own definition. For now, I think the Front-end Developer/Designer/Engineer title is suitable. This is the Web; it’ll always change.

Front-end developers do oscillate between the design and the engineering side of things, and I like the way the authors outlined how front-end developers should be aligned with UX and interact with Engineering. As front-end development has gotten more complex and more varied devices are being used to browse Web sites, and we have to account for all those experiences, I think it makes sense that a Front-end Development team would reside under UX and be an arbitrator between UX and engineering.

Companies are definitely specializing and aligning teams in this way, as shown by the questions people are asking, and the companies that now have these titles/skillsets, and are developing these kinds of teams:

I partially agree with this. Great UX requires efforts from all people involved in its creation—not only designers, not only front-end developers. It requires support from back-end developers, a copywriter, designer, and photographer, too.

UX is not limited to any specific skill or department.

Which party is responsible for documenting each and every pixel dimension on a pixel-perfect mockup?

The front-end designer/developer or the user interface designer?

I believe from the intent of the author that no one should be producing pixel-perfect specifications. Instead, the product is the spec. After getting far along in conceptual designs—flows, IA—the designer should work closely with the FED so the built UI is pixel perfect.*

This is in line with lean and agile practices that de-emphasize writing documentation in favor of just building the product—with the assumption that, unlike building a skyscraper, big changes are possible in future iterations.

*Or as perfect as necessary or possible given practical constraints of meeting schedules, doing as little as possible in each iteration to enable more iterations, and so on.

I am a front-end developer. My specialties are HTML/CSS/JQuery. My company is on Microsoft for back-end development. One problem that hits a nerve is that, on my project teams, they are now starting to use the back-end developers to do the front-end developers’ work. I always get into the argument that that was what they hired me to do. Any recommendations on how to increase the FED importance?

“On the other side of the divide, engineers get excited about solving hairy technical problems—and whether their solutions impact users is always secondary.”

LOL. As a software engineer, the first thing I do before starting any sort of design or coding, is to sit down with a user and watch them work.

You’re referring to bad engineers or siloed engineers.

This whole UX mess is giving me indigestion.

Join the Discussion

Asterisks (*) indicate required information.