UX Design Versus UI Development

User Assistance

Putting Help in context

March 21, 2010

One of the more interesting tensions I have observed—since getting into user experience design about five years ago—is the almost sibling-rivalry tension between UX Designers and User Interface (UI) Developers. At the heart of the tension between them is the fact that most UI Developers consider themselves—and sometimes rightfully so—to be UI Designers. The coding part is like Picasso’s having to understand how to mix paint. It’s not the value they add, just the mechanics of delivering the creative concepts.

When I worked on the Body of Knowledge Task Force for the Society for Technical Communication, the interesting question we wrestled with was: What value does a technical communicator add above what an engineer who writes well offers?UX Designers or UX Architects have the same problem to solve: What value do we add that differentiates us from a UI developer who is user focused? This question strikes to the very heart of what differentiates us, as UX professionals, from UI Developers. If we don’t provide a compelling answer, the only one left is that they code and we don’t. Hmm…, not the kind of value proposition I’d be comfortable with in this economy.

Champion Advertisement

I was recently reminded of the import of this problem, when a UX Designer lamented that he had approached the Product Manager for a new product with the question: “Have you thought about how to ensure the quality of the user experience?” The Product Manager’s answer was: “Oh yes, so-and-so is developing the UI,” where so-and-so was a talented and user-focused UI Developer. So, how do we break into the product-design process when something like that happens?

I thought about this on my drive home that night—on almost empty roads, because the weatherman had predicted two millimeters of snow for Atlanta, and the town was shut down in anticipation—wondering how to counter in response to a statement like this: “We have a talented developer working on it.” My conclusion: I’d come back with, “Great, he’s good! Where is he going to get his user data?”

I think a mistake we sometimes make as UX Designers is that we believe, if the race starts at wireframing, we will win. But if that’s where the race starts, we have no advantage over a talented UI programmer. It’s not like we have a monopoly on secrets about design patterns and best practices for user interactions. Some UI Developers have the same knowledge and, in some cases, were even the ones who pioneered those patterns and best practices.

In this column, I’ll examine the differences and commonalities between the UX Designer and UI Developer roles and discuss how the two can complement each other rather than compete.

Role Definitions

The following descriptions of roles are a bit oversimplified, but provide a workable framework for a discussion of the respective contributions of UX Designers and UI Developers.

UX Designer—One who designs the user experience for applications after doing user and workflow analysis, producing user-centered design artifacts such as personas, site maps, taxonomies, and wireframes. A UX Designer may also conduct usability testing on prototypes or finished products to assess the quality of a user experience.
UI Developer—One who builds user interfaces that support the exchange of information between an application’s users and its back-end processes and databases. This could be either a fully dedicated role on a development team or a hat a developer who is also responsible for coding the back-end processes might wear. A UI Developer’s output is functional, testable, shippable code that lets users accomplish their goals when using an application. The UI Developer is also responsible for documentation that allows others to maintain their code.

Figure 1 illustrates the resultant overlap of traditional UX design skills and UI development skills.

Figure 1—Overlap between UX design and UI development skills

The area that tends to fall under the exclusive domain of UI development includes the programming skills and knowledge. If you had a pin labeled Ruby on Rails, the UI development role would be a good place to stick it. The area that tends to be the exclusive domain of User Experience relates to user research and usability testing. Thus, if you had a pin labeled card sorting, the UX side of the diagram would be its predictable home. The area of shared expertise between the two roles includes knowledge of UI patterns and standards—the widgets and elements that make up a user interface—as well as knowledge about the software development process. This diagram is somewhat oversimplified—imagine one where the borders are fuzzy rather than crisp lines of demarcation, and you’d get closer to the truth.

How These Roles View Themselves and Each Other

As I’ve worked with and listened to UX Designers and UI Developers, I’ve noticed how they view themselves and each other. I am reminded of the crime shows on TV and who is the primary crime solver on each of them. You get a very different impression depending on which show you watch. The CSI shows would lead us to believe that the forensic scientists solve the crimes—including the arrest and interrogation of suspects. Quincy ME tried to convince us that it was the coroner. And patrol cops, detectives, profilers, prosecutors, and defense attorneys might emerge as the central crime solvers, depending on what show you watch.

In short, if you ask a UX Designer and a UI Developer who is the principal designer of the user experience, expect to hear a resounding I am! from both of them.

UX Designers see their validity as coming from the user research that informs their designs. “We’ve talked to the customers, and we know what they want.” UI Developers see their validity as coming from their knowledge of the underlying technology’s capabilities and constraints, along with their knowledge of how to use the widget library at their disposal.

And the tension between the people in these two roles has been known to generate hard feelings. UX Designers resent the disregard developers sometimes give their designs. And UI Developers feel that UX wireframes are too static and don’t take into account what they discover during the process of building a user interface. As a design comes to life, the developers gain new insights—either while interacting with the back-end processes or by testing the interactions they are building.

Another source of resentment that sometimes arises is UX Designers’ feeling that they’re getting left out of the development process as their wireframes move into production and would like to be more involved when changes are necessary. Conversely, UI Developers feel left out up front, where they feel they could provide informative inputs about what the available technology and tools can do and what they constrain.

Complementary Roles

I think the two roles have distinct areas in which they respectively add their unique value.

The professional value UX Designers offer includes their processes and the artifacts they create that help inform and validate design and development around user needs. When we create a wireframe or prototype, it’s our way of communicating data-driven—or at least process-driven—design considerations. Such a design artifact should be a straw man that starts a collaborative process of review and refinement. (Sometimes, being a UX Designer feels like being a forensic sketch artist who draws a nose, any nose, so a witness can say broader, thinner, whatever.) The best case is when a design deliverable both visually communicates data-driven requirements and provides a working space for collaborative input.

The professional value UI developers offer is their use of technology to actually make the best user experience happen. In that role, the UI Developer is a rightful participant in the design process. Bringing a conceptual design to life is a creative function, and a UI Developer can help the design mature and emerge by applying his or her own creativity to the process. If a UX Designer were to insist that his wireframes were unquestionable blueprints, we’d lose the insights that could come from a UI Developer’s craftsmanship in building that blueprint into a functional structure in which a user would want to work.

So, as UX professionals, our ultimate value is that we follow a process that includes data gathering, data validation, collaborative design, and usability testing of our designs. Our process can channel the talents of UI Developers and support their involvement in design by informing them of user needs, then validating that the emergent design meets those needs.

If we think of ourselves just as better UI Designers, we might lose the value proposition to talented UI Developers who can both design and code.

In Teamwork | UX Professions

8 Comments

Joost Willemsen

March 22, 2010 3:03 AM

I couldn’t agree more. Our involvement as UX designers shouldn’t start or end with wireframes. The research and conceptualizing that come before the wireframes and the testing and fine-tuning that come after them, are equally, if not more important when aiming for a great user experience in the final product. Sadly, for the sake of budget and planning, both clients and project managers are often inclined to leave out precisely those phases of the project plan. So, in order to achieve our goals, we need constantly to convince clients and project managers of the benefits of following a full UX design process. I know from experience this is not always easy, but it is not impossible.

Mike Myles

April 6, 2010 2:17 PM

At the outset, I felt I disagreed with some of the assertions of this article, but I was won over by the end.

One concern is captured in the UX Designer role definition. I don’t see the designer as the only person who does the design work, but rather the one who owns creating the design deliverables—specs and prototypes—and is accountable for the quality and completeness of those deliverables. Of course, as part of generating those deliverables, the designer does design things, but so do—or should—others. I see the role of the designer as the primary arbiter of a design process that includes many interested parties—customers, product managers, developers, QA engineers, documentation writers, and marketers.

This may seem like something of a semantics issue; lets just call all that design, because that’s what a designer does. But there is value in acknowledging that much of the actual design—or components of a design—come from nondesigners.

Just as the construction foreman on a job site doesn’t cut every stud or drive every nail, the designer on a complex project doesn’t design every feature down to the smallest detail. However, at the end of the day, both are responsible for the overall project. This understanding presents a situation where colleagues are clear on one another’s primary responsibilities, without—either intentionally or not—excluding contributions from the outside.

Additionally, it’s useful to have developers and other non-UX team members involved in customer research—listening in, taking notes, offering their impressions on what they saw and heard. Actually observing customers can be a very powerful learning experience, even for those not trained in user research techniques. It’s also interesting to find out what others on the team observe. So, though UX may own the research tasks, including the wider team can be highly beneficial to everyone.

On the code ownership side, I’m not comfortable with stating that, “…the exclusive domain of UI development includes the programming skills and knowledge.” Again, the issue is ownership of the code deliverable rather than knowledge. Designers should have a working understanding of implementation technologies related to the projects they work on.

I don’t expect an auto designer to be able to rebuild a motor, but I’d expect some basic understanding of a car’s systems. Same goes for an architect: I don’t expect him to build the structure, but I do expect a solid understanding of construction techniques. The same should be demanded of software designers. Not only does it inform the designer of possibilities and limiting concerns, but it allows the designer to speak with his customer—the developer.

As designers, our primary customers aren’t users, but developers. They’re the people we need to communicate our ideas to. Without them, our designs won’t get built. Even though we are responsible for representing the needs of users, developers are the major consumers of design deliverables. Because of that, it’s important that we share a common language. This is why it’s essential for designers to have a grounding in development and, ideally, for developers to have exposure to design processes and methodologies.

You won me over in the last section on complementary roles. I completely agree that the optimal situation is for designers and developers—and product managers and QA engineers and documentation writers—to collaborate and complement one another. Each team member has primary responsibilities, but individual contributions can overlap significantly—with writers suggesting design ideas, QA engineers suggesting implementation approaches, and the like. Certain individuals will naturally cross role boundaries more than others, but everyone should be encouraged to participate in all aspects of product development.

Thanks for an interesting and thought-provoking article.

Michael Hughes

April 12, 2010 6:16 AM

Thanks, Mike Myles. Your comments add a lot of value to the discussion. I found your comment “As designers, our primary customers aren’t users, but developers” particularly insightful. When coaching writers on how to get published, I often comment that their audience is not the reader, it is the editor. Same principle.

John Zimmatore

April 16, 2010 12:17 PM

This article reminds me of the discussion I had with a lead developer who was trying to understand my role on a project (this is in the early days of in the field of HCI/UX). His comment to me was “anyone can design a user interface.”

My response was “no, anyone can implement a user interface, not everyone can design one.”

Fortunately, the story has a happy ending…at the end of the project, he came up to me and told me that he now understood what I meant by my response, and whole-heartedly agreed.

Ken Whaler

June 18, 2010 7:54 AM

The issues I have run into are not necessarily the roles—we should all comfortable with those—but from ownership.

If a UXD and a UID disagree, who has the authority to call the shots? It’s similar to a BA and a PM disagreeing on what’s better for the business. Though disagreements are part of working with others, I do think that ownership might be the root of the issue.

Our approaches are similar, but different…. I have disagreed and have had to negotiate with designers and developers alike. The concerns are the same. We all think that our way is the best way, and we don’t want someone else telling us how they can do it better—even if they are right.

David Allen

August 28, 2011 6:48 AM

You made two powerful points:

identifying the unique value UX designers offer

identifying why it is sometimes difficult for UX designers to collaborate with others

On the second point, the agile movement encourage cross-functional collaboration. Serial processes, like the waterfall approach, leave all participants feeling dissatisfied. By the way, this same problem exists for other roles such as architect, business analyst (BA). As you said:

“Another source of resentment that sometimes arises is UX Designers� feeling that they�re getting left out of the development process as their wireframes move into production and would like to be more involved when changes are necessary. Conversely, UI Developers feel left out up front, where they feel they could provide informative inputs about what the available technology and tools can do and what they constrain.”

As you implied, developers should be involved early, to help inform the design. And UX designers should continue to be involved through the product lifecycle, both to ensure the spirit of the original design is being followed and to support variations when good reasons are discovered, allowing them to learn.

Dini

January 28, 2014 7:13 PM

I doubt whether any UX designer can design rather than doing the initial concept part. Design is done by the visual designers. They play the critical part that wins or loses the case.

Joshua

August 12, 2014 4:48 AM

In my opinion, a UI Developer will work more with the code in mind whereas a UX Designer will work more with the user in mind.

Ultimately, the user is the one who is going to benefit from what a UI Developer and a UX Designer do.

If one person can develop a good interface (UI Development) in terms of performance and behavior and also can design a user interface (UX Design) with a user in mind, that’s the person who can excel in his or her career.

In most cases, this cannot happen, and a UI Developer and a UX Designer have to work hand in hand, thinking always of the user and doing exactly what the customer wants rather than fighting over who is more powerful.

I hope I have made some sense here. :)

Mike Hughes

UX Designer at TSYS

Atlanta, Georgia, USA

In his role as User Experience Architect for IBM Security, Mike’s professional focus is on designing usable user interfaces that accommodate the user as learner. Previously, as User Assistance Architect at IBM, Mike identified tools, methods, and standards for integrating the content and delivery of user assistance, including documentation, Help, elearning, and training. He was formerly Lead UX Designer for CheckFree Corporation, where he instituted their User Experience Research and Design Center. Mike has a PhD in Instructional Technology from the University of Georgia and a Masters in Technical and Professional Communication from Southern Polytechnic State University. He is a Fellow with the Society for Technical Communication and a Certified Performance Technologist through the International Society for Performance Improvement. Read More

UX Design Versus UI Development

User Assistance

Putting Help in context

Role Definitions

How These Roles View Themselves and Each Other

Complementary Roles

8 Comments

Join the Discussion

Mike Hughes

Other Columns by Mike Hughes

Other Articles by Mike Hughes

Other Articles on UX Professions

New on UXmatters