Replies to This Discussion

Permalink Reply by Carleton Hall on February 9, 2012 at 1:14pm

Here's a good book that will explain it: Men Are from Mars, Women Are from Venus

That's a joke, but it's still relevant.  You don't really need a book.

Communication between the design and dev teams is a big problem.  The cultures are different and how they measure success is different.  They are like cats and dogs.  Very few companies (or people) do this well.

Usually the design teams make designs that are difficult to implement and don't want to hear that from dev teams.  So, design either ignores them or says that they don't know what they are talking about.  Then are pissed 3 months later when the product sucks.

Basically, design writes checks that dev has to cash...and they never ask dev if there is enough money in the account.  Then the client (and management) is pissed when the check doesn't clear :)

The design is effectively a promise to the client.  Design should not only verify with Dev that they can deliver on that promise, they should work with Dev in actually coming up with the promise.  Design should also be open to hearing how Dev can deliver in the best way.  Just because a product works well in a demo doesn't mean it will be easy to maintain, support, and update.  These are all things that must be considered and usually fall on Designer's deaf ears.

Design needs to also understand that they have TWO customers: The dev team AND the client. They can't just draw anything on paper and expect it to magically happen. Some are accustomed to Art/Design school where the art/design is the finished/graded product and their job is done.  Well, in actuality, that product is now input into another phase.

Also understand that developers don't like saying "no" for fun.  They actually LOVE making things work.  It's a challenge that is rewarding when it's met.  Usually when a dev team pushes back, it's for a very good reason.  But, many design teams automatically assume that dev is either doesn't know how to do something or is being lazy.  This *could* be the case, but it's usually something to do with a seemingly easy thing to do that really isn't.  I mean, it's easy to make a robot scramble eggs, right?  How hard can that be?

Understand that dev teams have limited control over their application servers.  Some app servers are very, very powerful...but like to do things a certain way.  The custom code to tweak how that's done may cause more problems than it solves, which creates a maintenance and support concern.

How do you get over this?

- Put Design and Dev in the same workspace, not in separate parts of the office.
- Listen to each other.
- Be open to alternate solutions.
- Most importantly, get Dev involved EARLY in the SDLC.   Not at the end.

• ▶ Reply

Permalink Reply by Shilpi Joshi on March 26, 2012 at 12:24pm

Hey Carleton, I simply loved the "check and cash" scenario you presented to explain this very commonly observed design challenge so simply :). 

It's no surprise that good communication between the design and development team plays a big role in avoiding design issues in the final product outcome. And most certainly, the communication does have to start early and continue through out the project life-cycle, and not be observed only right before rolling out the product.

Having the development and design team work in one workspace could certainly ease in that communication and create better work rapport and understanding.

• ▶ Reply

Permalink Reply by Jaime Wolf on March 15, 2012 at 12:44pm

I have a lot of good resources I can recommend, but it would help if I knew your role- are you a UX designer who wants to increase your own knowledge to help you communicate these things? Or are you looking for resources to recommend to the design/tech teams for them to learn more?

thanks

Jaime

• ▶ Reply