UX Developers: Unicorns or Narwhales in woolly hats?

February 2, 2012 by Pete

There has been a bit of a debate recently on the validity of the job title ‘UX Developer’, much of it as result of Leisa Reichelt’s post What is a UX Developer and are they really a thing?.

In some fields, job titles are easy. But in a such a new field as web and application design, where processes and roles are still being thrashed out, and are adapting to rapidly advancing technology and thinking, its not so easy. Job titles from a decade ago like ‘web designer’ and ‘web master’ are now deemed too vague, too indicative of a generalised skill set, in an industry that increasingly expects specialism. The industry likes to hear ‘UX Designer’, ‘Web Applications Developer’, ‘Visual Designer’ etc. People with such job titles are seen as focussing on being really good at one thing, instead of diluting their value by spreading their skills across multiple disciplines.

I have a problem with this trend. Although I too believe that it is possible to spread yourself too thinly and end up being a jack of all trades, I think the industry is becoming very militant and prescriptive in what is and isn’t a valid skill set, and draws somewhat arbitrary lines between one ‘specialism’ and another.

There are developers out there who specialise in one single programming language. There are other developers who successfully work with multiple languages. There are designers who specialise in typography alone, while others specialise in interface design, and still others work across digital and print. Depending on the developer or designer’s skills and inclinations, any of these approaches can work. There is no ‘right way’, and no guarantee that a narrowly focussed skill set will necessary be a deeper one.

Similarly, most UX Designers I know are involved in everything from user research, IA and interaction design. It is quite possible to specialise exclusively in any single one of those activities, and quite possible to do all three. Some UX Designers are very good at all three, but I’ve met some UX Designers who are actually pretty lacking in some areas – specifically interaction design.

A ‘UX Developer’ seems to me to be a perfectly adequate description for someone involved in interaction design and front-end development, much the same as ‘UX Designer’ is a description of someone involved in interaction design and user research and IA. After all, the overlap between front-end development and interaction design is no smaller than that between user research and interaction design.

Interaction design demands an understanding of how things get built, and can benefit hugely from being prototyped within the actual medium in which it will be built (in this case HTML). Front-end developers often have specialist knowledge of the nuances of building accessible interfaces, something that should be fundamental to all interaction design for the web. Most front-end developers make daily interaction decisions anyhow, simply because no amount of prototyping or wireframing can account for every scenario in the usage of a site or application. Additionally, many of the important nuances of interaction design, such as the timing and subtlety of transitions, pretty much have to be done in HTML/JQuery.

I don’t mean to suggest that all front-end developers are natural interaction designers, only that the front-end development skill set dovetails very well with that of interaction design.

On the surface, ‘UX Developer’ could be seen merely as a synonym for an interaction designer who happens to prototype in HTML, but I think the term could prove to make an important distinction, in that a UX Developer would be assumed to be capable of delivering production quality front-end code based on those prototypes – an ability not all interaction designers possess. The value in this – in increased efficiency, in less risk of things being lost in translation – is obvious.

A UX Developer is not a hybrid. There are no ‘hybrids’ in this industry. There are simply people, all with their own unique skill sets. Some of these skill sets fall easily into established job titles, while others don’t. If they don’t it is because those job titles are based on outdated and arbitrarily drawn boundaries in what should be a seamless process with no fixed cut-off points in responsibilities. We can’t ditch job titles altogether (it would be hopelessly impractical) but if the hats we have don’t fit everyone, then at least lets knit some new ones.

I’ve been working in this industry for over 10 years, and have been involved with everything from server-side coding to interface design. My core skills though are front-end development and interaction design. I’m never quite sure how best to summarise what I do to others – perhaps UX Developer is the closest fitting hat there is right now.

How to design things properly

September 6, 2011 by Pete

Not long ago I heard an otherwise talented designer complain that accessibility guidelines “impose more restrictions” on them.

I never heard that same designer complain that brand guidelines imposed restrictions on them. They rightly considered brand guidelines to be an essential parameter within which their designs needed to work.

A designer who begrudged having to work within brand guidelines would not be taken seriously as a designer. Yet a designer who begrudges working within accessibility guidelines barely raises an eyebrow amongst their peers.

Why is this?

In short, it is because accessibility is viewed as a minority need.

At worst, this manifests itself in outright prejudice – a resistance to “cater for a minority” in favour of a preferred solution for a majority.

At best, it manifests itself in a view that the disabled are a minority who don’t really care about design, and are happy to be accommodated separately.

But guess what? Disabled users don’t want an accessible version of your site – they simply want the sites they visit to be designed properly in the first place.

By ‘designed properly’ I simply mean this – a site that is designed well, that solves its problems with solutions that work for as many people as possible – a design which is inclusive. A solution that excludes people unneccesarily is not a solution at all, it is a failure.

It is not sufficient to have a list of bolt-on ‘accessibility enhancements’ to run through after you’ve designed for your idealised user. Because there is no ideal user – there are simply users, all of whom have different motivations, different feelings, and yes, abilities. Take that approach and you’ll end up compromising the experience for everyone.

Inclusivity should be embraced by designers because it is the socially responsible thing to do, and because it is fundamental to good design. Or as @SandiWassmer (who writes eloquently on these matters), summed it up nicely: “Inclusive design is about making a product fit for purpose. “

There is much debate amongst designers these days about how to design for the increasing range of devices being used – from mobile to desktop, and everything inbetween. New methods are emerging such as responsive web design, which attempts to allow sites to adapt effortlessly to device and context.

But to my mind, a more pressing problem is this – how do we design for such wide ranging people? There is no ‘normal’ user just as there is no ‘normal’ device. We have to embrace the fundamental principle of inclusivity, and ensure our sites are usable by all who wish to use them.

In short, we have to start designing things properly

Wizards, Rockets and Exploding Heads: why designers should code

June 30, 2011 by Pete

There’s continual debate within the web design community as to whether designers should (or indeed can) write code.

The answer is that yes, designers can code, and yes, designers should.

Why you should code

Efficiency – You’ll work better with developers

If you know how websites are built, developers won’t send work back to you with an apologetic “sorry, we can’t build it quite like this”, because all those carefully considered decisions around typography and layout that you made will have been better informed.

You’ll have more control over the design

A Photoshop comp isn’t a design, its an artist’s impression. That italicised Georgia pull-quote may look beautiful in Photoshop, but it may be almost illegible rendered in Windows. Designs almost always need to be revised once they’re in the browser.

Additonally there are always dozens of pages, elements, fringe-case situations etc that aren’t covered by those Photoshop comps, and someone needs to design them. You might be lucky to be working with a developer with a good eye, but you might not, and micro-managing a less design-savvy developer is inefficient to say the least.

If you can build sites as well as visualise them in Photoshop you will be able to adopt far more flexible design processes. I routinely switch back and forth between designing in Fireworks and designing directly in the browser with CSS. Its a fluid process that works well for me, and I bet it would work well for you too.

Being able to build your own designs, and have full control over every nuance, is a great thing.

Be prepared for the future!

There’s a real momentum gathering around the idea of responsive web design – in a nutshell, websites that adapt themselves to a wide range of screen and device widths, with no fixed layout. For obvious reasons it is very hard to design such sites without taking the design into the browser, and playing directly with CSS.

You’ll be more employable

Being able to design and code means that you will be able to dive in to help out in a wider variety of situations. That makes you a greater asset to any team, and especially attractive to startups, who often don’t have the resources to employer both a designer and a developer. And if you’re freelance, you’ll have a wider choice of gigs.

Why you can code

Some designers feel they can’t code, or that they could but that it would somehow dilute their design skills. Many designers are discouraged from doing so.

All these barriers are based on two myths.

MYTH 1: You can’t do both – they’re a different mindset

There’s a widely believed myth that designers and developers have different mindsets, and that it simply isn’t possible to do both jobs well.

That simply isn’t true.

Contrary to popular belief, using both the left and right hand side of your brains doesn’t make your head explode. It can be done. Many great contributors to culture and science, like Leonardo da Vinci, have done it.

I think its true that some developers can’t design. Design requires an innate ability – without it, all the design principles in the world won’t make a developer a great designer.

And I think its true that there are few designers that can become equally great back-end developers (by which I mean all the really hardcore programming and database stuff).

But I’ll let you in on a secret…

CSS isn’t rocket science

This is rocket science:

rocket science

Pretty damn complicated, isn’t it? You’d have to be a rocket scientist to understand it.

This is CSS

rocket science

‘p’ stands for paragraph. You can guess what the rest of it does, I’m sure.

CSS is written in something approaching English. HTML is pretty straightforward once you’ve learnt it. There’s no logic involved, no calculations, nothing to make your brain explode. You just need to take the time to learn it. Trust me, it feels more like a craft than a science.

MYTH 2: Designing and Coding means you can’t become a specialist in either

When I was a kid I used to play Dungeons and Dragons. In that game, players would choose a profession – a fighter, a wizard, a priest etc. On their adventures players would gain experience points for using their profession’s skills. As they gained more experience, they would become more powerful. A Level 10 Wizard was far more formidable than a Level 1 Wizard, for example.

But you didn’t have to choose just one profession. You could become a fighter-wizard, for example. A fighter-wizard would take longer to progress through the levels, as experience points would be divided between the two professions. It would take a fighter-wizard twice as long to reach Level 10 than a fighter or wizard would. But crucially, they would have the exact same skills and proficiency as their single-profession counterparts when they got there.

If wizards can do it…

The analogy is obvious, and accurate.

Some would argue that if a designer concentrates purely on design for 10 years, rather than dividing their time between design and development, then they’re going to be a better designer.

But I would take issue with that. First, how much better would they be? The more experienced we become in something, the slower our skills grow – there’s a much greater difference in ability between someone with 1 years experience and someone with 10 years experience than there is between someone with 10 years experience and someone with 20 years experience.

I’d also argue that when it comes to web design, that an understanding of front-end development is itself crucial in making you a better designer.

A designer who codes is a specialist

Besides, what constitutes a specialist? I don’t do all aspects of design – I don’t do print design, and I don’t do campaign work – I design interfaces. Similarly, my development skills are concentrated on developing interfaces, not any of the ‘behind-the-scenes’ stuff. I am, in essence, a specialist in interfaces.

I’m at least as specialised as a designer who specialises in ‘design’, working in both print and digital, or a developer who writes both front and back-end code. The only difference is that my skillset overlaps two more generalised areas.

Summary

Being a designer who codes isn’t as hard as some people make it sound. Nor does it make you a worse designer. It makes you a better designer.

So why not give it a go? You may even enjoy it.

A pragmatic approach to responsive web design

June 23, 2011 by Pete

There’s a lot of talk these days about ‘responsive web design’, and I believe that the techniques and approaches that it encompasses are going to prove invaluable as we design new sites for an ever widening range of different devices.

Retro-fitting responsiveness

But those techniques don’t need to be limited to new designs or major re-designs. They can be applied to existing fixed width sites to improve the experience for users on handheld devices. And though adapting an existing fixed width site so that it behaves more responsively can seem like a daunting task, it can actually be relatively painless.

I’m going to share my experience of doing so on a site I built for an artist’s portfolio, and highlight some of the techniques and decisions that were made.

The site

The site was initially prototyped in HTML. Layout, typography, colour palette etc were then explored within Fireworks mockups and then developed and refined within the prototype itself. A few markup tweaks later and the site was essentially done.

The problem

The site was fixed at 960px wide. It worked fine at desktop resolutions but was fiddly to use on mobile devices, requiring an awful lot of scrolling and zooming to look through the artwork.

A pragmatic approach

In retrospect I should have taken a responsive approach from the outset, eg. allowing images to stretch/shrink to best serve the many resolutions they might be viewed on. But rather than try and retro-fit an ideal approach, I wanted to see how quickly and easily I could fix the biggest issue – the need for better presentation on mobile devices.

Setting up

First I added two media queries to my global stylesheet – one to target mobile devices (ie. device widths 480px and below), and one to target anything larger than mobile. Anything outside of these queries would be applied to all devices. It then became a simple process of moving existing styles into the second query if I didn’t want them to be applied to mobile devices, and adding new mobile-specfic styles to the first query.

The changes for mobile

Page widths

The site is currently fixed at 960px. I wanted it to be full width of devices up to 480px wide, so changed the page width to 90% for device widths 480px and below.

Navigation

The tabbed navigation simply doesn’t work. If shrunk down the fit a small screen it becomes impossibly fiddly to use. I’ve re-styled them completely, ensuring they have large hit areas, and allowing them to stretch, in a manner similar to that demonstrated by Ethan Marcotte’s ‘Responsive Web Design’.

Desktop

Mobile

Mobile (landscape mode)

screenshot of navigation on mobile landscape mode

Title

The graphical title didn’t work well with the revised navigation, so I moved the image-replacement technique to the larger-than-mobile media query and re-styled for mobile devices using the Typekit styles used elsewhere on the site.

Desktop

screenshot of page title on desktop

Mobile

screenshot of page title on mobile

Line-height

There’s a generous 1.8em line-height on some passages of text on the desktop version that feels uncomfortable on the mobile version when those passages are reduced to less than 300px wide, so I reduced it accordingly.

Background imagery

The CV page has a large typographic background image that makes no sense when cropped on the mobile version, and looks fussy when scaled down to fit. It is simply removed from the mobile version (by moving the image out of the global styles and into the larger-than-mobile query).

Whitespace

The desktop version uses a generous amount of vertical whitespace in its compositions to group elements together, and to give the design an airiness. In the linear mobile version the whitespace breaks the flow of the page, and so I reduced it.

Desktop

screenshot of whitespace on desktop

Mobile

screenshot of whitespace on mobile

Hover states

Obviously hover states on links have no value on a touch-screen mobile device, so all hover states are moved into the larger-than-mobile query (though I could have left them for the benefit of some future hover-sensitive touch screen device). I then double-checked that there were enough visual cues for links after those hover-states had been removed.

Homepage Carousel

I’ve removed the carousel on the homepage entirely for mobile devices using a simple (albeit crude) “display: none”. The decision to do this is more of a hunch than anything – a feeling that users on a mobile are likely to be browsing quicker than desktop users, and won’t be lingering long enough on the homepage to enage with the carousel. I’m not sure its advisable to second-guess the context in which users are using their mobile device, but I’m comfortable with the decision.

Tweaks and fixes

There was a fair amount of kinks to iron out (eg. margins between floated columns caused alignment issues when linearised in the mobile version, and some larger images needed to be changed from fixed width to percentage-based to stop the layout breaking).

Conclusion

And that’s about it. I’m not suggesting that this retro-fitting approach is preferable to rebuilding a fully responsive layout from scratch – it isn’t. But this exercise hopefully shows that with just a couple of hours work you can get a previously fixed width site looking pretty respectable on a mobile, and far easier to use.

To learn more about responsive design techniques I can thoroughly recommend ‘Responsive Web Design’, and to see some properly responsive designs (as opposed to the hatchet job I’ve described above), check out the Media Queries website.

The Page Fold is Dead… Long Live the Page Fold!

December 6, 2010 by Pete

The page fold exists. It influences users’ behaviour. And it needs to be considered.

What is the Page Fold?

The page fold is a classic case of a widely agreed upon print design phenomenon that was adopted early on by web designers, as it was assumed to hold true in their discipline. The principle is simple – newspapers folded on a newspaper stand have only the top half of their page visible to the passer by, so if you want a headline to grab attention it must be ‘above the fold’.

Clearly, a rule in one design discipline does not necessarily apply in another. After all, it takes far less motivation on the part of the user to scroll a web page than it does to pick up a newspaper from a news stand and unfold it. But we have to remember that in the early days of the web, designers and users alike were unfamiliar with the medium, and it made sense to adopt tried and trusted principles from other areas of design.

And so the idea persisted, with designers often cramming as much content as possible ‘above the fold’, afraid that anything below it would be likely to be missed by the user.

Page Fold – Myth or Reality?

But although this idea of page fold as significant barrier has been rightly debunked in articles such as ‘Myth of the Page Fold’, too many people are now rallying behind a cry of “There is no page fold!” as blindly and unthinkingly as those that promoted the idea of the fold in the first place.

To begin with, dismissing the fold is to dismiss not a myth, but a simple observable fact – that some content is visible in the user’s browser when a page loads, while some content isn’t.

And this fact has consequences.

For example, content above the fold is essential in forming a user’s initial, split-second impression of a page, which can be formed in as little as 50 milliseconds (‘Web users judge sites in the blink of an eye’). If a user isn’t instantly convinced by a page, then they may not wait for the page to finish loading, let alone scroll down the page to explore further.

That doesn’t mean cramming content above the fold (if anything it means keeping things as simple and focussed as possible), but it does mean that the area above the fold has to work hard to be visually engaging.

The question of course is ‘where is the page fold?’ – the answer to which is that could be pretty much anywhere. With the enormous range of platforms and devices on which we view web content these days, it is impossible to know how much of a page’s content is visible above the fold.

But just because something is elusive, that doesn’t mean we should stop considering it. In fact, I’d argue that we should now be thinking about the page fold more, as it is manifesting itself in ever more nuanced and interesting ways.

The New Page Fold

Starting up Safari the other day I was struck by how much the Top Sites layout resembles a newspaper stand. The more I looked at it, the more I saw similarities, most significantly the fact that, for each website, Safari was showing me only the content above a ‘page fold’.

screenshot of Top Sites

The reason this is significant is because the thumbnails are not static images, but continually updating representations of actual content. When I launch Safari I get an overview of the actual content of my bookmarked sites. If something catches my eye, I click on the thumbnail to open up the site. But in order for something to catch my eye, it has to be ‘above the fold’.

Take the example of ‘Typography Served’, the site shown in the upper left thumbnail. There are six rows of images on the website, but the thumbnail in Top Sites shows only the first of those rows. If an item of content isn’t in that top row, then it isn’t going to catch my eye, and isn’t going to be explored.

Yes, I can open the site to see what is ‘below the fold’, but that requires an additional level of engagement, much the same as lifting a newspaper off a news stand does. I don’t do it.

An example of how the phenomenon of the fold still influences how we engage with content, and as the ways in which we experience web content diversifies and evolves, it is starting to manifest itself in all kinds of ways that we have not foreseen.