What's a healthy relationship with your web developers? [closed]

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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).