Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

This is always something that's interested me. I've sat at both sides of the table. I've been the developer who has had a first look at designs after they've been sold to the business, only to have to let the designer know almost none of it is actually technically possible in the timescales.

Similarly, I've been the UX designer who has been on the receiving end of a far too development heavy team and been told to work in boxes with no real movement. I know it's good to know a bit of each discipline, but it's very rare for 1 person to completely own both sides in a single project.

What level of relationship should UXers and developers have? Should developers be engaged at proposition / concept stages, or does this hamper and dull creativity?

Should designers be free to run with a design with no creative restraints so there is always innovation through design?

In your experiences, what has worked well, and what would you make sure you never done again?

share|improve this question

closed as primarily opinion-based by Erics, Matt Obee, ChrisF, rk., Benny Skogberg Nov 13 '13 at 11:26

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

1  
I think your scenario is already a little biased. Designers are definately concerned with prettiness and developers with functionality. You set up UX as something which designers come up with when really it sits between the two and requires input from both. –  JamesRyan Nov 7 '13 at 17:47
    
I've been in projects where that's almost exactly how UX has happened, where designers have sat in an echo chamber and championed each others ideas without any dev inclusion. I am very much for it being a cohesion of the two, I was just looking for any other good ways of working. –  SidetrackedByLife Nov 8 '13 at 12:05
    
I've been in projects where that has happened too. The designers come up with interfaces that would be fantastic except that they are completely impossible or unfeasible to implement. Without input from either side you are relying on the secondary skill of the other to second guess that input. Usually where I have seen one side or the other take whole charge of UX it is down to who is the most arrogant rather than who is the most widely skilled. –  JamesRyan Nov 8 '13 at 13:10
    
Generally speaking, there isn't much innovation that's going to happen when it comes to building web applications. Form always needs to follow function (ie. you can't know how something will look until you know how it will function). –  cimmanon Nov 8 '13 at 19:42
    
@cimmanon but sometimes how something may function is highly dependent on how it looks. Admittedly this is an oversimplification but it's more of an issue of scope. Yes, broad functionality has to be determined first. Detailed functionality, however, may come from any direction (engineering, visual design, copywriting, marketing, etc) –  DA01 Nov 9 '13 at 0:14
add comment

6 Answers 6

In your experiences, what has worked well, and what would you make sure you never done again?

Works Well:

  1. Be a designer who develops AND a developer who designs.

  2. White board concepts and solutions with developers as you either flesh out features or solve technical solutions. Be willing to bend and compromise and stand up for your ideas. Expect the same out of your counterparts.

Never do again:

  1. Conduct a "design" meeting or user interview without a developer present.

  2. Join a firm where user experience is not a priority

That's my $.02 on each aspect.

share|improve this answer
6  
I don't agree with either of your "never do again" items. There are plenty of reasons to discuss design or to conduct user research without a developer present. I would never hold up user research because a developer couldn't be present, for example. Joining a company where UX is not a priority also isn't necessarily a deal-breaker. The question is whether you have the opportunity to influence the company such that UX is a priority. There's a lot of hard problems out there to solve, and companies that haven't yet learned the value of UX have many of those problems. –  nadyne Nov 8 '13 at 0:40
1  
Maybe the never do again item should be "Never proceed blindly into designing without first checking the achievability with the developers" –  SidetrackedByLife Nov 8 '13 at 12:02
    
By speaking (worse, writing) these points, their spirit is unavoidably corrupted. I have been in plenty of meetings w/o developers but I am invariably sorry when I don't at least invite one. Conversely, I have NOT attended tech meetings where decisions that affect UI were made and I was sorry I wasn't there to advocate for them. Nadyne, most valid... I have instituted UX practices at three places so far in my career. And failed at a fourth :) It's not easy even with it as a priority. So that truly is a NEVER for me. Others may not be in the same space. –  Itumac Nov 8 '13 at 18:33
    
Perhaps worth adding (depending on your workflow with the client) - "do not let a client sign off a design before letting a developer eyeball it" –  jingtao Nov 9 '13 at 6:04
add comment

You could create the "perfect" design when you have the freedom to do so. But the goal is usually not the design itself but have it build in real life with all it's technical constraints and with business goals to reach. You gain more support for your designs if you involve everyone that is part of the development process as early as possible. If developers have influence on the design, they will feel more involved with the product. And if they are motivated to get it to a higher level than you will get more freedom to be innovative.

share|improve this answer
    
That's generally been my approach, but it's good to hear how other people set up their stalls on a project –  SidetrackedByLife Nov 8 '13 at 11:47
    
A design that can't be implemented because it ignores real life constraints is by definition not perfect. It should not be just about getting people on board but a desire to fully understand the requirements. –  JamesRyan Nov 8 '13 at 13:15
    
@JamesRyan I totally agree. That's why I double-quoted the word perfect. That said, requirements aren't static either and are affected by aspects as design and technical opportunities/constraints. –  jazZRo Nov 8 '13 at 14:32
add comment

I can't say I have a definitive answer. But I can tell you what my guesstimate is. I'm only a developer, but I'm a "one guy shop" developer so I'm forced to learn at least a little about UX.

So let's pretend you're the UX guy and I'm the developer guy...

I should always have the final decision in everything. How fast something is built is pretty much up to me, and it's a crucial factor in any project. But developers aren't gods (although some think they are). Everybody has to tell the developer the specs in a detailed and clear enough manner so that he can just go "ok, got it. time to write code.". The more time your developer spends asking questions, the worse things get. As a UX guy, you supply specs. Along with the people who know WHAT it is the product should do and those jerks in marketing who give you the unrealistic deadline. The UX guy is an idea guy who has to already know how to design the pretty and the simple, and has already done so on tons of past projects. Unfortunately, developers love to dive into the complex (it's what we do), and they usually can't tell the pretty from the ugly.

So you need to already know what to do. You need to tell a developer how in a simple and detailed manner - and especially why. You need to tell him that he needs to jump though these hoops so the system stays as simple as possible and how fewer hoops will make the system more complex. Developers always (should) respect simplicity and clarity.

Good luck dealing with your developers. We are not easy to deal with.

share|improve this answer
    
I was a Senior Front end Developer in a previous life, so I know the issues on both sides of the table. But whilst I agree that inclusion of the developer is key, I don't agree that how fast something is built is purely up to the developer. If I know where the flexibility is needed in future, I think there should be a discussion as to what is acceptable to meet the experience to achieve the business goal, but maintain a robust base. The more a developer is included, the more they get the why in the instance an FSD isn't quite as solid as needs be. –  SidetrackedByLife Nov 8 '13 at 11:58
    
The 'final decision' in anything should always be a collaborative consensus. Granted, that's not always possible, but that's what the teams should strive for. –  DA01 Nov 8 '13 at 16:33
    
I can go along with that. I wasn't trying to say the developer should make all the crucial time decisions. Just that if there's a disagreement, that the developer's opinion should usually trump the others'. But, really, it's all a judgement call. It all depends on the people you have to do the job and what their various strengths and weaknesses are. Same project, different set of people, probably gonna execute the project differently. –  Stephen Hazel Nov 8 '13 at 16:33
add comment

It'll depend on the talents and attitudes of the team members, as well as the corporate structure, but that aside:

UX and Development should be one and the same. They should be working together from day one.

To be sappy, it should be akin to a marriage...lots of open communication, listen to each other, transparency, avoid blame, etc.

share|improve this answer
add comment

One book on this subject I'd recommend is Designing from Both Sides of the Screen, written by UI designer Ellen Isaacs and her developer husband Alan Walendowski. It's written in the form of the dialogue between designer and developer from inception to completion of a new project (albeit a desktop application, not a website).

It's a few years old now and a more modern tome might take more of an Agile/Lean UX slant, but it's certainly still worth a read.

share|improve this answer
add comment

As a professional, I should be aware of the constraints on the project that are brought to bear by different disciplines, no matter which seat I sit in.

A developer shouldn't pick an obscure programming language or framework just so they can add it to their CV, if the learning curve will cripple the project; neither should they spend a week on UML diagrams for a prototype or a campaign website that's only going to be live for a month.

Similarly, UX designers need to be aware of the constraints the development team face — if a UX designer is designing something that's technical not feasible or will require a large amount of effort, this has to be taken into account. Brainstorming should be unhampered when coming up with ideas for best creativity, but this then needs to be tailored to suit the needs of the project (e.g. deadlines/budget/ability), before the idea is signed-off.

In terms of working well together, I think that there needs to be a shared understanding of what is important in a project and why, which cuts both ways. Maybe that comes from presentations to each other, or sitting in on workshops, but without it, there is often frustration from each group as they see push-back as being contrary rather than enhacing the product.

For example, some developers at times don't understand the importance of consistency across user experience, e.g. with labelling or messaging. The UX team on the other hand may overlook aspects like accessibility legislation or the trade-off that occurs between animation & load speed.

Generally, I'd go with having regular catch-ups between both teams, though not going as far as putting developers into ever UX meeting or workshop. You may even find developers offering possibilities that the UX team hadn't thought of, given their closeness to the technology (a different way of filtering when implementing a search system, for example).

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.