In the future, will we *all* have to code?
In Jared Spool’s presentation at the IA Summit, he talked about the “Holy Grail” being a UXer who can code. He didn’t mean someone who could just do both, but someone who could do both really well. Jared posited that in the near future, all UXers will need to know code.
It immediately begged the question, when we talk about “a UXer who can code”, what do we mean by “code”?
I assume we mean front-end development, a good handle on HTML and CSS, and a bit of jQuery, to quickly be able to knock together a clickable prototype. However, if you want to put together a quick prototype, but use real content, then that kind of implies hooking it into a back-end database. Karen McGrane’s suggestion of what is best practice - trying out your new thing with the best and worst examples of your real content - requires that. And if you’ve got something that works in the browser, and is hooked into the back-end, then surely you are just duplicating the work of making production-ready code?
What struck me even more than this, though, was that here I was at an IA Summit being told that the future of the trade is in learning to code. And I’d just been to the “Future sound of music” panel at the Media Guardian Changing Media Summit to hear David Haynes from Soundcloud suggest that developers are the people who are shaping the sound of modern music. And there is a constant debate these days in the journalism world about whether journalists need to learn how to code.
So, are we all going to have to learn how to code?
Really?
There are some people who can design furniture, and then build it. And there are some people who can design furniture, and then get a craftsman to build it. I think we should be wary of dispensing with the craft skills that go together to make up digital products.
I can throw a bit of code together in a smattering of languages, but that has taught me enough to know that I am not a specialist in this area. What I think we need much more of is UXers (and journalists for that matter) with a coding mentality, and with a greater technical appreciation of the world that they are inhabiting.
As Karen McGrane put it in her presentation - look at the sheer number of people and job titles that go into making a movie. Why are we seemingly driving ourselves not just to make terms like IA, UX, IxD interchangable, but also trying to assimilate the craft skills of software developers?
In his excellent “Beyond the Polar Bear” talk in Denver, Mike Atherton suggested that a great way of developing products was to:
“Pair an IA with a developer, so that you can get real prototypes in front of real people, really fast”
I think that sounds like an exciting prospect, that allows both parties to use their areas of expertise to develop something that is potentially bigger than the sum of its parts, rather than dumbing down software development to a commodity level.
Oh, and just a little something to throw into the mix - the pressure seems to be coming from both directions. Last week Tyler Tate posted “Why developers should become UX designers”...
Perhaps coding will get easier to do? It might not seem like real coding then. The first people to play electric guitar had to build it themselves. Gradually this changed, but in the 60s you still had Brian May building his own guitar for cost reasons, but it also means he got it exactly how he wanted. In the 80s the Human League made some of their own synths for the same reasons.
I'd agree with Mike, sometimes its good to delegate tasks (even if you can do it yourself) and get more done in a shorter time. Two heads are better than one, right?
I would call the central '?' area in your diagram 'The Devigner' - a mythical type who can both design and code to a very high standard. In fact at least one large software company I can think of has that exact role in their organisation, but in my experience they don't really exist.
Don't get me wrong, I know (have hired and worked with) many excellent designers who can code and many superb front end developers who can design - but I don't know of any who I can say without doubt are experts at both in both principles and practice. It's the classic 'Jack of all trades; master of none'. Its a lot of skills to juggle and keep relevant.
Personally I've always been more of a fan of having a well balanced team of the right and complimentary specialist skills, than a team of generalists.
Simples!!
1 designer + 1 front end dev + 1 back end dev + 1 qa + 1 ia = 5 salaries
The full stacker = 1 salary
More money for managers' bonuses...
I believe most importantly we will all need to have a coding mentality. The world has changed from 50 years ago. It is hard to imagine making serious decisions about priorities for most any organization without a basic appreciation of coding. Here I am talking about something a bit different than you, I am talking about program managers that are not going to be doing anything related to creating the code behind the effort and executives... I don't understand how people think they can continue to be ignorant about technology and hope to be relevant. I don't think you need to have the knowledge to code yourself but you need to be much more knowledgeable than most people are today. And really if you are under 40 (maybe over that you can hope to slide by into the sunset without suffering too much from your ignorance but that is a dangerous gamble), I think you have to try to pick up coding in simple ways. Not to be an expert but to be able to at least understand the capabilities, the tradeoffs, databases, Ux principles...
My guess is over the next 20 years we will figure out much better ways to let people gain knowledge of coding ideas without having to become coders. But until then I think it is imperative for most people to realize to comprehend the modern world they need to gain an understanding of coding (even if they are not going to be an expert).
I agree strongly with your thoughts on pairing with experts. It is much easier to pair if you at least comprehend the general ideas of the others areas of expertise. I don't think it is great to dumb things down to the level one expert can do the others job. But I think it is critical to understand that your expertise is part of a system. The Ux is part of the solution. Coding is part of the solution. The whole is what matters.
"However, if you want to put together a quick prototype, but use real content" Absolutely. Prototypes without real data lose a great deal. Super quick, first drafts maybe that is ok. But quickly getting to prototypes that are integrated with real data should be the goal.
If this does happen don't expect compliant, accessible and scalable websites to be output.
It won't happen because then UX people wouldn't have the time to attend conferences.
You can see Jared's point; in a standards-based web, where design and layout elements are more often outputs of CSS rather than Photoshop, then code is the only true output of web design. Most everything else is either an interim deliverable (which gets translated to CSS) or else a fake prototype. If a visual designer can express themselves via the native tools and formats of the web, the workstream gets much more efficient. I don't know, but I'd put good money on the 'winners' of the web (Twitter, Facebook, Youtube et al) not going down the wireframe/Photoshop comp route at all.
There's always (in my experience at least) been a mutual fear and loathing between designers and developers, which is as much cultural as it is skills-based. I believe it's UX designers who must bridge that divide, because UX is not, not, not just about interaction and visual design. I'm with @cennydd in that 'UX' has become a byword for 'web design', which was always distinct from 'web development'. But really (and as I say in my talk that Martin references above) real user experience goes far deeper than front-end design. It starts with how your data is modelled, and then how that bubbles up through the software stack, eventually surfacing on pages. It's everything from URL design to caching and load-balancing, to external findability. All these things have a profound effect on the users experience, yet few seem of real interest to the more snowboardy of our UX design cultists. As @fantasticlife is keen on citing, the smartest, most influential people working at Last.fm are those that sit tweaking the recommendation algorithms. Design does not just mean front-end visual and interaction design. /rant
But yes, pragmatically-speaking it's unlikely that a designer versed in colour theory, typography and layout principles, or indeed an IA versed in library science and ontolification, would become a CSS wizard overnight. Hence the suggestion of pairing up an IA and a developer. This has the obvious advantage of breaking down the pin factory model, but also increases understanding from both sides of the benefits of the respective crafts. As Martin rightly says, its more than the sum of its parts.
I think its perfectly valid to suggest that a developer can have a UX leaning or a designer can have a code leaning. This is perfectly healthy. However, if one person is for filling both roles is usually symptom of business necessity (i.e. speed/cost) rather an ambition to have an accountable and thoroughly defined solution. On a side note: UX is an overused term. Everyone seems to do it yet everyone has completely different deliverables depending on their experience, skills and leaning. This creates confusion.
+1 to all this.
I can't understand why we pull down the shutters between different disciplines. Just because my job title is an IA, and I know some stuff about domain models, doesn't mean I'm not interested in other stuff too. I'd love to know more about colour theory, typography etc - that stuff is really cool. And I'm in awe of people who are comfortable knocking up a quick, working prototype in Ruby/Rails (c.f. @fantasticlife).
The ideal would be for everyone to be expert in everything - the worst case is to be specialised in one thing, and hostile to all else. Even if someone isn't an expert coder, or hasn't spent years learning colour theory, they should understand the basic theories behind both, and appreciate their importance....and that goes the other way, too. Ivory towers and all that...
This might be disloyal to my profession but if I had a choice between getting a developer to skill up in UX and getting a UX designer to skill up in code then I'd go for the former. Especially if the desired end result is someone who can do both really well.
@graham Agreed, that that's the danger of being multi-skilled; it gets corrupted by businesses who don't want to pay for specialist resource, and think 1 all-rounder is the answer. Ironically, that's how it was back at the start - back in the good old days of '96 web design was as much about hand-crafted HTML as it was making animated GIFs :) I think the subsequent divergence into distinct roles was partly down to the increased complexity of putting a (increasingly dynamic) website together, and partly just a resourcing issue; one person can't deliver on all those things in a realistic timeframe.
@paul So yeah, it's probably more about being sympathetic to all disciplines, rather than being equally skilled in them all, with all team members considerate of the others' skills and understanding of what those skills add to the mix.
So obviously I'm with Mike. The important thing is not to be prescriptive in mapping skill sets to job titles. HR departments might care about the kind of thing but once you're in and working the only thing that matters is the quality of your ideas and how well you communicate those ideas (to product managers, hackers, designers...). But...
...I do think there's a problem with "UX professionals" just not knowing enough about how a modern web stack works; what the data structure looks like, what the business logic looks like, what the controller code does, what the markup should look like, how to use css to layout pages responsively, how to use css to decorate and where/how to use javascript to layer over behaviours.
I've seen a ton of wireframes and photoshop comps that conflate and confuse document design with page layout with behaviours and state. The answer, in my mind, is bottom up user experience working up thru the layers of the application, all informed by a user centric domain model and a decent content strategy. Rather than working down the stack from the visible and dismissing the rest as an implementation detail. Top down UX just feels like too much concentration on the visible bit of the iceberg whilst being willfully blind to the important bits below the waterline.
The difficult bit is how you educate UX people about the web app layer cake. And since people tend to learn thru making mistakes I suspect the best way to learn is to try to write code and fail and try again. Else it's just lectures and whiteboards. Not saying UX people should be writing production code (maybe some should be writing production markup and css? possibly javascript?) but they should be aware of the separation of concerns and which particular concern they're designing for / what assumptions they're making.
I don't think any of this is as scary as it seems. Modern web app frameworks (rails, django) do a lot of the heavy lifting for you. I'd encourage any UX person to give them a try. If not to ship production code, then at least to learn more about the anatomy of a web app