We stand with Ukraine and our team members from Ukraine.

The Community Of Over 640,000

Home ›› Development ›› Hi, I’m a UX Developer – You’re a what?

Hi, I’m a UX Developer – You’re a what?

by Tim R. Todish
6 min read
Share this post on


Like a geeky, mythical creature, UX developers are part designer, part developer.

“So, what do you do for a living?”

“I’m a UX developer.”

“You’re a what?”

“I’m a user experience developer…”

“Uh-huh… what’s that?”

I have this conversation just about every time I meet someone. I can’t say I really blame the person on the other end, though; my job title is sort of an ambiguous and buzz-wordy. I often opt to take the easy way out and just say something about working for a company that builds software applications for the Web, desktop, and mobile devices. “Ohh, okay. I get it.” Admittedly my answer is a cop-out, but I’ve found it’s quite difficult to explain to someone what a UX developer is.

So What Is a UX Developer?

The realm of the UX developer exists somewhere between that of the traditional developer and the designer. We’re not really designers, yet to be a good UX developer you certainly need to have an eye for design. In the same vein, we’re not traditional developers but we certainly need to have development experience and expertise. Often this experience spans multiple technologies, languages, and platforms.

It falls on the UX developer to bridge the gap between design and technology. We need to be able to think and speak the language of designers. It’s our job to help translate their vision to the development team in a way that they can understand and accept. This can be a critical piece of the puzzle in a project, especially if the design and the interactions behind it are complex.

Similarly, we need to speak on behalf the developers to help reign in the designers, at times. If they are coming up with concepts that will be extremely difficult or time consuming to implement, we can explain the limitations of the technology and the complexity involved in implementing their designs, and try to come up with an acceptable alternative.

In addition to helping bridge the designer–developer gap, UX developers actually build stuff, too! In my experience, for the most part, UX developers are not building production level applications. That’s not to say they couldn’t or that they never do, but most of the time their skill set is better utilized in other ways. Rather than building full production-level applications, UX developers more often are building prototypes and proofs of concepts. A proof of concept may be as simple as building out a single interaction to see if it works, or testing to see if something is possible. Seeing if something works doesn’t mean seeing if it works technically (e.g., if I put data in this form field does it go into the database?). Instead, the UX developers build out interactions to see if the methods they’ve come up with works from an experience perspective. Is it intuitive? Does it flow correctly? Et cetera. This is one of the main differences between a traditional developer and a UX developer.

The prototype is another powerful tool of the UX developer. The level of fidelity of these prototypes can vary but the concept is usually the same. Like the proofs of concepts, the idea is to build and test various interactions and designs. Prototypes usually mimic an entire application or, at the very least, a large chunk if it. The job of the UX developer is to build out the prototype to look and function as closely to the real application as possible. This serves a few purposes. First, it creates a version of the application that can be used in user research testing. This can provide very valuable data by allowing users to interact with the application in its native environment. A high-fidelity vision prototype can provide a much more valuable and holistic experience that design comps or paper prototypes. Another major benefit of having a UX developer create a vision prototype is that, in most cases, the code used to skin the prototype and build out the animations and interactions can be handed over to the dev team for use in the production app. This is a huge benefit to traditional developers because oftentimes they don’t want to waste their time worrying if things are pixel perfect, or if an object faded when it was supposed to slide, etc. It frees up their time to focus on what they’re best at: making sure the application works, is scalable, and is “bulletproof.”

UX Developer vs. Traditional Developer

One of the fundamental differences between the UX developer and the traditional develop is the focus of each discipline. Both are concerned with whether or not the application works. It is in how they define “works” where this fundamental difference in focus is found. For the UX developer, the focus is on whether the interactions, process, flow, and overall experience of the application works for the end user. Is the application intuitive, simple (not simplistic) and, most importantly, does it meet the user’s goals? Of course, the traditional developer is also concerned with whether or not the application works. However, for the traditional developer the application works if it executes all of the items listed in the functional specs. The focus of the traditional developer is centered on tasks rather than goals.

Another difference lies in the skill set of each type of developer. Obviously this will vary from individual to individual, but in general, a traditional developer is likely to have more of a, well, traditional background. They’ve probably got some sort of degree in computer science, have mastered a heavy duty backend language such as Java and are familiar with all of the best practices and design patterns that are out there. A UX developer, on the other hand, probably doesn’t have a computer science degree. Maybe something in the design realm or even a completely unrelated field. In addition, they’ve likely studied a variety of front-end development technologies.

How and Why Would I Become a UX Developer?

The UX developer role is a discipline under the overall user experience umbrella. This means that to become a UX developer you need to have at least a general understanding of the core UX principles, philosophies, and methodologies. This includes, but is not limited to, the how and why of user research, wireframing, and the use of personas.

You also need to have a solid and broad range of development abilities. A good deal of your time will be spent writing throw-away code so it isn’t necessary to learn the ins and outs of every framework out there. What you will want to focus on is how to add interactivity to components—for example, some basic animations; touch, tap, and swipe gestures; component skinning; etc. Learn how to do these things well, and learn how to do them quickly. If quality is the number-one goal of a UX developer, speed is a close second. Timeframes are often short for prototype projects. Most likely, you’ll also be creating multiple iterations of each project therefore it becomes important to create new builds quickly to get them in front of your clients for their feedback.

Why bother? The short answer is that it’s exciting! As a UX developer you’ll often be working on new products and applications or breathing fresh life into existing ones. Many times you’ll also be creating for the latest and greatest technologies and devices. This can be challenging because you’re always working in uncharted waters but it can be very rewarding when you develop a new interaction model that creates an exciting, successful paradigm for your users.

As you can see, defining what a UX developer is can be a bit fuzzy. Like some sort of geeky, mythical creature, they are part designer, part developer. I’ve heard them described as a sort of human Flash Catalyst. If you find yourself in that middle ground between the design and the technology and you enjoy merging the two together, then a UX developer role is for you! Just be prepared for the quizzical looks you’ll get every time you tell someone what you do for a living.

post authorTim R. Todish

Tim R. Todish,

Tim Todish has been working in the Web/RIA industry for more than 10 years. After cutting his teeth on HTML, ASP and SQL, he shifted his focus from back-end technologies to developing rich front-end experiences with early builds of Flex and AIR. Tim has a passion for using technology to create engaging user experiences across multiple devices.

From his years working closely with creatives and designers for companies including Meijer, Inc and Crowe, Tim has developed the unique ability to view both the technical and creative sides of any challenge. This has also honed his talent for bringing “techies” and “non-techies” together, fostering cross-cultural communication between the two.

Tim is currently working as a UX Designer for Maestro.


Related Articles

Tips on how to champion HCD and design research to stakeholders and get them on board with all of your UX processes.

How to Champion HCD and Design Research to Stakeholders
  • The article covers:
    • The importance of stakeholder management
    • Challenges to overcome with research resisters
    • Common objections to doing user research and how to respond
Share:How to Champion HCD and Design Research to Stakeholders
8 min read
How to Champion HCD and Design Research to Stakeholders

Curious to know about a philosophy that liberates our innate need for control? Then read to find out.

A Philosophy for Systems Change
  • The author talks about the nature of systems change and unpacks the following ideas:
    • Dynamics of Change: Our Situations Devolve and Evolve
    • Wabi-Sabi: A Design Philosophy for Complexity
    • Social Systems: The Beauty of Imperfect, Impermanent, and Incomplete Information
    • Social Systems: The Beauty of Modest and Humble Learning
    • Social Systems: The Beauty of Unconventional Thinking
Share:A Philosophy for Systems Change
5 min read
A Philosophy for Systems Change

Technology makes seemingly inconvenient tasks easier — but at what cost?

The Value of Inconvenient Design
  • The article covers the problem of friction and its impact on design.
  • The author explains the problem friction brings to design value based on examples of IKEA, Facebook and Amazon.
Share:The Value of Inconvenient Design
8 min read
The Value of Inconvenient Design

This website uses cookies to ensure you get the best experience on our website. Check our privacy policy and