As Erin mentioned in her last post, I serve as the U.Va. Library’s User Experience Web Developer. But what exactly is a UX developer and how is the role different from a web designer, front-end developer, or generalist programmer?
Perhaps foremost, a User Experience Developer allows assessment to lead design. When we set out to create a new tool or feature, we don’t start with sketches or Photoshop documents or the like, but with surveys, focus groups, and user testing.
Erin’s efforts in this area allow me to focus on the areas that are affecting users the most and also often point me toward a likely best solution. An assessment-based approach to design allows me plenty of artistic freedom while also ensuring that I’m paying close attention to the most critical areas of need. Even better, trustworthy data gives me confidence that my design decisions are taking our sites in the right direction—often allowing us to pursue innovations that would otherwise seem too risky.
A User Experience Developer also balances attention between interaction design—crafting individual points of engagement—and overall site architecture and flow. Spending vast amounts of time perfecting a single form element or banner means little if your users consistently lose their way in a labyrinthine site architecture. Likewise, the sleekest and most sensical arrangement of web pages can ultimately fail if the site is filled with clunky interactions, poorly edited content, and aesthetics that don’t inspire trust in your site. For a more extensive take on this concept, I recommend Jesse James Garrett’s diagram and book, The Elements of User Experience.
While I spend a good deal of time creating design deliverables (wireframes, mockups, and actual front-end code), the single most important skill for a User Experience Developer to master is communication. Staying in close contact with our librarians (who in turn learn from our community of students, staff, and faculty members) and constantly reporting on design challenges and improvements while garnering feedback is the key to ensuring buy-in from stakeholders at all levels. If we can accurately relate the narrative that led us from initial assessment to the formulation of design principles all the way to implementation and refinement phases, we can foster acceptance by our internal audience and also ensure that we ourselves are remaining focused on our users’ needs, consistently improving our online experience.
How do you stay connected to your users’ needs? How do you improve acceptance among both stakeholders and users? Let us know in the comments!