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

Building effective partnerships with PMs requires stepping outside of any frustration, ego, or resentment at being ignored, and building empathy. How to do that? Here is what we’re going to find out.

How To Research So PMs Will Listen
  • PMs are the most critical audiences for research, they are also often the hardest to convince, and the source of many of researchers’ frustrations and heartaches.
  • Building effective partnerships with PMs requires stepping outside of any frustration, ego, or resentment at being ignored, and building empathy.
  • The author shares:
    • Some practices of working with PMs
    • Questions to ask PMs and stakeholders
  • The baseline expectation setting:
    • Level set
    • Set guardrails based on your role
    • Ask for candid feedback and engagement
    • No surprises
  • When researchers and PMs are in conflict or in separate silos, neither role gets the value of the other, but strong researcher-pm partnerships can be game-changing for extending the strategic impact and influence of both design and research.
Share:How To Research So PMs Will Listen
6 min read
How to research so PMs will listen
How To Empower An Organization Through Design?
  • The author believes that the following reasons are why design/branding/marketing agencies end up damaging the image of design as a tool for getting results:
    • Lots of jargon and little to no action at a fundamental level.
    • Large companies with “foolproof” processes.
    • Fake cases and invented touch points
    • Romanticized view of consumers
  • In order to centralize an organization, designers need to map its interdependence relationships and understand how a project can strengthen all sectors in an equal way.
Share:How To Empower An Organization Through Design?
4 min read
How to empower an organization through design?

And, Is OneReach Under The Radar By Design?

Is OneReach AI The Tesla Of Conversational AI?
  • The author gives his perspective on OneReach.ai as the top scorer in the Gartner 2022 report.
  • The author believes OneReach.ai to be one of the most granular no-code environments that support an exceptional degree of fine tuning.
  • The author refers to the platform as an orchestration canvas, where multiple processes can be orchestrated for multi-dimensional customer service, and gives some details on how the platform works as a single front-door for customers.
  • Cobus Greyling explores two cautions from Gartner about the OneReach.ai platform.
  • He concludes that voice is a strength of OneReach.ai and the company has extreme focus on customer experience, and orchestrating experiences
Share:Is OneReach AI The Tesla Of Conversational AI?
4 min read
Is OneReach AI The Tesla Of Conversational AI?

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