Category: UX Development

I’ve been using the job title UX Developer for a while now, it just seemed to best describe what I do. When it came to setting up my business Dogwonder Ltd/> I wanted and needed to describe what I do, not in a manifesto type way, I haven’t thought that far ahead, I wanted to do what I know – UX Development seemed the obvious choice.

Given I have been hanging that term off of my own logo for 18 months, it got me to thinking about what that actually meant in practice. What happens when the verb becomes a noun, from -er to -ment. Was my business really worth of such a noun, am I living up to it?

The vast majority of the engagements for Dogwonder Ltd/> lean more towards web development, mostly SMEs wanting a website that they can ultimately control (text editing, menus, social media, SEO etc). As such the traditional UX phase tends to be much leaner that I was previously used to in consultancy land where engagements could be upwards of several weeks. When a project has a budget that stretches to around 5 days worth of work, the UX phase needs to be quite lean indeed. That’s not to say it’s not important, but usually that part tends to be about understanding the primary goals, users and business needs quickly. I will often start with an initial stakeholder meeting and a 1-2 hour workshop with a various focused exercises, followed up with a brief report and page sketches to validate ideas. For most projects this tends to suffice, still it’s probably 10-20% of the overall budget, so not too shabby. But more than anything it’s essential I understand what problem I am trying to solve for the client, what do they ultimately want the website to do? Without understanding this from the outset, any chance of completing the project successfully is very low.  In addition often is necessary to understand the clients business at least from a zoomed out perspective.

I quickly realised that even if the traditional UX phase of a project was proportionally much smaller on smaller sites, it didn’t mean it had to end there, I found that UX was inherently weaved into the fabric of the rest of the project timeline:

• Design phase
• Site development and administration
• Measuring success
• Touch Points (social, IRL)

Given that my projects tend to be quite short, on average 1-2 weeks  (project time, not elapsed time), the various project phases are likewise short, and so it’s important that I bake in as much UX goodness throughout.

Design Phase

Often I will receive maybe two or three design comps for a website, mostly likely a homepage, single page/post as well as a feature page (gallery, forms, petitions etc). These will usually designed for desktop (900-1000px) and mobile breakpoints (320px). Sometimes I might only receive a PDF style guide and some assets such as fonts/images.

So mostly it’s up to me to fill in the gaps, mobile, landscape, tablet and everywhere in between. Graceful degradation for older browsers that don’t support opacity, gradients, animations. Often pretty important decisions not just from a design perspective but from a usability perspective. I might not be deciding how a page layout is put together, but I am certainly ensuring it is usable for the device and platform in question.

Often there are other page types and design patterns that emerge over the project, where it’s necessary for me to extrapolate from the original designs. So 404 pages, alerts, form submission errors, external dependencies (social sharing, like buttons, video includes), cookie warnings (grumble grumble), all of which need to work within both the design framework as well as from a usability perspective. We could design for every one of these scenarios, but this would take too much time, so we (designer(s), client(s), me) design directly in the browser as situations emerge. So from an initial lean UX/Design phase a working breathing site emerges responding to content, devices and platforms as the build process develops.

We might only design for 20% of the final site, and the ‘final’ designs may differ substantially from the final site, but it’s enough to get us to the build phase we we can make UX decisions with real content on real servers through real devices. What worked in photoshop doesn’t so much work in the browser.

Site development and administration

I am a big believer in enabling administrative users to manage as much of their content as possible, having to rely (and pay) me to change something on the site invariably leads to inaction or delay thus compromising the original goals of the site. Why hardcode a google map or team photo when through things like Advanced Custom Fields we can enable site administrators to change that themselves. Or for example enable site administrators to change a hero image/text on the homepage allowing them to be more responsive to their user’s and business’ needs.

If I make a bad decision on how a site is administered it might mean that specific functionality that was meant satisfy end-user needs is not used to it’s full potential. Questions like, correct terminology, ease of access, clearly labeled forms, taxonomical organisation, complexity of administration, editorial work flows all combine to decide whether a site is easy to administer and directly proportional to how successful that site maybe, if the site administrator doesn’t feel comfortable updating the site, then no amount of up front design or UX will aid the eventual success of the site.

Measuring success

In the same vein empowering stakeholders with analytics is a very important part of the whole process, enabling them to see what’s working and what’s not. Often as part of the development process I will set up a GA account and add the client as an admin and encourage them to use it. We can then use those analytics to improve the site, based on actual usage rather than assumptions.

Touch Points

The website is only one part of the whole. Social and offline are just as important, without promotion in these channels the website is likely to only exist in a vacuum, again missing out on it’s initial goals. How does the site look when shared on Facebook, optimising og:title and og:image can be essential to ensure Facebook users are getting a good experience when sharing the site, and not some random image from the homepage or elsewhere. Ensuring facebook and twitter profile and banner images as well as google places are also considered as part of the process can make a big difference to how end-users might find and interact with a site, as well as potentially offer feedback on the experience.

Even IRL, does the print media reflect the goals of the business? Often I have spent time with a client on re-aligning the website much more towards core business needs, only for the business card and other print literature directing users to the site not reflecting those needs.

To sum up

So I realise that not all of this is strictly UX (although a fractal definition of UX seems to be pretty common) however, if we are talking about ensuring a website meets it’s primary goals and serves and responds to users, then I’ve found considering the impact of development decisions on end users and stakeholders essential in the ongoing success of a website. Thus I am going to be continuing to use UX Development as a description for my business function, it’s what I do.

Moving forward I would like to demonstrate some of the methods used on projects, with code examples and screen grabs.

So recently there was a debate about the title UX Development, following on from a blog post by Leisa Reichelt and a response by Andy Budd. A lot of good points raised on both posts as well as in subsequent comments and tweets. I can see validity on both sides of the argument so I am not here to argue so much with either side, but simply talk about why I felt the title UX Developer suited what I do.

A little history about myself

I started working in this industry in 1999, learnt HTML/CSS and managed the design, build and evolution of a commercial site for a publisher for eight years. I also designed and built my own site as well as others on a freelance basis (such as this one in 2001, apologies for the font, not my choice, I was young. Oh and the code, ouch). I didn’t even realise I was properly a front-end developer until I started looking for a new job nearly four years ago, ofcourse I had heard the title, just didn’t realise that’s what I did. Up to this point I didn’t give much thought to titles, as I mostly worked on one site and was effectively a one-man web team.

I did indeed then become a front-end developer proper, along with some design as well. I sat in the design team and for a while I simply cut code directly from PSDs (either ones I had designed or from others’ PSDs). A little while after I started, we in the design team embarked on a journey into user-centered/user-experience design. Not because it was the cool new thing but because it made a lot of sense with designers getting more involved in the process of understanding the need, context, users and problems and creating a solution rather than just colouring in wireframes. It was a big push and took a lot of effort by my colleagues in the team.

I have always been interested in audience/user motivations and behaviours, wether it was from my art school days from the perspective of the audience reaction to my work or later as I gobbled up the writings of Alan Cooper in About Face. Involving users in the process of defining products was no brainer for me and I used some of the techniques from About Face (particularly user interviews) in the mid 2000s. In addition I read alot about the theory of perception (a top influence was Edmund Wright – Language, Perception Language and Faith) and how important it is to understand intentional perspective.

So in essence this was not something I thought I needed to get into because it (‘UX’) was what all the cool kids were doing but a natural and obvious reflection of my personal beliefs and interests (as well as a clear need for it within our professional approach).

A journey into UX

So as my company and design team colleagues started to get more involved with user research / user testing / wireframing / user journeys and the like, I wanted to get involved as well and not just be the guy that turns coloured pixels into css. I wanted to be more involved with the decisions about how the product/service/application comes to life and felt I had something to offer in this respect. So after dipping my toes in a couple of workshops and toying around with wireframes and sketching I went to UXLX in 2010, found much of what was said made a lot of sense and realised I actually did some of this naturally in my work. I read lots, learnt from colleagues, made massive mistakes and had some successes. I got more involved in the initial discovery phase through stakeholder research and end-user workshops, utilising techniques such as those written about in Gamestorming. I enjoyed it massively and found the experience really fulfilling.

Developing experiences

When it came to me actually developing sites UX massively influenced my approach. If time was an issue for users, I would reduce the number of clicks required to get to a service. If the need was to quickly browse a complex set of information I would architect a complex hierarchical taxonomy and content types to enable the user to tailor navigation of the site to their needs. If mobile access was a need I would ensure responsive design was a part of the build. It often was small details like ensuring the button in the header was just a few pixels bigger to ensure that users can actually click it without overshooting with their mouse. Increasingly I am using advanced CSS3 and HTML5 techniques that wouldn’t necessarily be represented on a sketch, wireframe or PSD. It might even just be a simple CSS property or HTML attribute:

1
2

a.button:hover {cursor:pointer;}
img src="image.png" alt="Assisting the user"

Whatever the need, I like to think these methods enhance the user experience and in some cases are essential, for example image attributes for where the user is visually impaired or responsive design for mobile usage.

In addition I do quite a bit of WordPress development, If I install a bunch of plugins that means the load time of the site is 5 seconds, does that affect the user experience? I think so. We might do the perfect discovery and design phase, but if the do phase ends up meaning the user has to wait 5 seconds for a page to load all that previous good work can be invalidated.

So what we do in the development phase is essential as a part of the UX gestalt, infact bringing development into the discovery phase early on can ensure we make technical decisions and start the solution early, more informed and ensure the end result is likely to align with the original needs and expectations. Sometimes it’s simply advisory, ‘is feature x viable?’, other times it’s essential to be involved in the early phases and workshops to properly realise user needs. Even if it’s to ensure the vision is carried through the implementation phase and not diluted by technical limitations or extended throughout an application where wireframes don’t go (404 pages, user notifications, admin systems). As was mentioned in the comments on Andy Budd’s piece ‘long after a user-experience designer has left the project’. Maybe people that ‘dabble’ in UX as developers might just ensure the end solution matches the initial need more directly that if we try and separate out the roles too much. Maybe we don’t need to reflect that in their titles, but certainly we need to reflect that UX is not the domain of designers only.

So, finally…

So that’s what I think, maybe there aren’t many of us that run workshops, perform user research & testing as well as building websites. So maybe ‘UX developer’ is a niche term or clunky combination of skills, or yes, yet another UX title to add to the growing hoard:

But for me, I wanted to ensure my title reflected the fact I do both. Other titles I considered put me too firmly in one camp – designer (or UX) or developer, leading to perception that I either don’t understand UX or Development. I want to span them both as in my experience this often produces the best outcomes when any technical implementation is required in a project (esp. as the scale of the project increases).

If anything I intend to take this role’s definition further, utilising UX principles further into development (consider an activity stream algorithm that considers more user context and need?) as well as consultancy (devising training programs for users or informing strategic thinking?). I am a strong believer in cross-team collaboration and see my role as being able to further encourage that through the lens of UX.

When I started out in this industry we pretty much just had web designer and web master, neither of those reflected what I did then, not many do now. But ‘UX Developer’ is the closest thing to what I do, so I am going to stick with it for now.