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.