Developers are from Mars, Designers are from Venus.Chad Udell cd2ug - meeting September 3, 2008

A little contextI’m a Designer

I love design, i studied it in school. I have a degree in design and art history. I have my favorite designers, my favorite web safe hex colors, my favorite pantones. I have designed record cover art, T-shirts, posters, web sites, game interfaces.

A little contextI’m a Developer

I’ve written code. Apps, games, websites, cms, crm, custom stuff, flash, flex, ajax, stuff.

What’s the difference?Some generalizations.

What good is a soap box without a sweeping hyperbole or two? Right?

What’s the difference?Developers are killjoys, squashing creativity to make a deadline or taking the easy way out to build functionality.

developers are task oriented. goals and milestones are their lives.

What’s the difference?Designers are fun but reckless, they create great work but aren’t concerned with the bottom line.

designers tend to be highly iterative. they use revisions to allow their ideas to grow and shift. they often need ‘inspiration’ or a mood to produce what i lovingly coined ‘design whoo hah’

What’s the difference?A little reality, please.While each may contain a grain of truth, both are way off.

Neither of these are true. Obviously designers like to work on profitable projects that launch on time and developers enjoy creating groundbreaking well designed projects. Where does that lead us?

We Need BothWe are on a team, right?Work habits and communication styles need to be standardized to succeed.

The sooner that your team members get that and can move on it, the quicker you can succeed.

Changes are NeededDesigners need to be practical and able to move on when the goals are achieved.

You must remember the scope of the project.

Pay attention to your estimates. Pay attention to your hours logged. Be able to end a design cycle and work through the remaining design issues so you can stay on target. Developer’s use a mantra of “Release Early, Release Often”... how can you use this mantra as a designer? Paying mind to component based design parameters may help you here. I recommend designers read a “Pragmatic Programmer” series book or two and possibly “Getting Real” by 37 Signals.

Changes are NeededDevelopers need to realize that design does matter. Ideas need to be able to mature.

Simply because you have wireframes or block diagrams that are ‘approved’ by the client doesn’t mean they are final. Some metaphors may just not work when realized into prototyped. Be ready to adjust. Agile methods can aid you here. Think of a design as the ultimate form of “Extreme Programming”... until the pixels meet your retinas for the last time, the design can change. Get used to it. Read “Design of Everyday Things” by Donald Norman for a little insight.

Integration PointsProcess, Process, Process

“4D’s” of Iona Group

What works for your company?

This is a big topic... Where do your teams match up? Where do things get handed off from one team to another? How do you interface with each other? Who rules the project’s server?

Integration PointsWorkflow?

Who is in on that first meeting?Which team is serving which on this project?

So, do wireframes get created by the developers? Or the Designers? Are the developers creative enough? Are designers aware of the toolset enough to make intelligent UI choices? Does the lead developer lead the effort or is it the CD? let the project dictate this. Is it a branding exercise with a little interactivity/application functionality? Or is it a true deep RIA with little need for “aesthetic” design and a lot of need of functional UI design?

Integration PointsFile Organization

Directory Structure is Not a Battlefield!

Who rules the project’s server? A thought: Maybe you can organize your folder structure based on your process? Define, Design, Develop, Deliver works for us. Keep people’s names out of directories. It lacks historical importance and breeds blame in the short term.

Integration PointsNaming“blue mockup 8 14 08.psd” or “mock1.psd”

what will mean more when the project is complete?

visualrinse.com/2007/06/12/deep-thoughts-on-file-naming-conventions/

What’s in a name? A freaking lot. Designers favor real world words. Fun words. “blue first mockup 8 14 08.psd” designer’s favor tight short names... “mock1_81408.psd” my tips... eliminate spaces and odd characters. use v2, v3, r2, r3 to denote version and revision info. See my post “http://visualrinse.com/2007/06/12/deep-thoughts-on-file-naming-conventions/”

Integration PointsVersioningSubversion, CVS are good but can be tough to use for designers and aren’t really suited for PSD or other binary files.

Version Cue from Adobe is nice, but can be tough to set up in a bigger workgroup.

Some other options... Unfuddle for SaaS SVN, Warehouse for an easy to use Web SVN, and Versions for Mac. The upcoming “Flow” looks great.

SVN=OMG!

Design and Develop teams may go head to head on this often. Developers live in SVN, CVS, SourceSafe, etc... Designers rely on file structure... my main tip... no “mockup_v3_final.psd”, “mockup_v3_final_final.psd”

Integration PointsTaxonomyStandardize the way you talk about things!

http://edweb.sdsu.edu/courses/et650_online/mapps/Glossary.html

Are they wireframes or block diagrams? Mockups or Comps?

Don’t get overly jargon-y or use it as a weapon. TLA dueling and art history barbs just lead to animosity.

As a designer you can flip flop between calling it gutter and margin, leading and line height, tracking and letter spacing... when you are talking with people that only use those terms occasionally, use the same term each time.

Moving ForwardDevelopment 101Designers, realize that Graphic Design will not save you!

Change the toolset to meet development specs.

When things are slow, opt to take on some typically “developer” tasks.

Designers with great color sense and excellent use of typography are ahead of developers when it comes to aesthetic, but what about usability? Interaction design? Data design? I recommend picking up “Designing Interfaces” by Jennifer Tidwell for a little insight on UI design patterns...Understanding Functionality, Data Follows Function, Form Follows Function, Design Patterns, A Bit of Needed Tech Jargon for Designers

Moving ForwardDesign 101Developers, no one likes programmer art!

Use palettes from sites like Kuler or ColourLovers to avoid eyesores.

Skins and themes for your apps are out there. Check out Scalenine.com for some great Flex themes.

There are rapid prototyping tools out there that will help you make good design decisions. Also, if your designer friends can help you out by providing basic guidelines you should follow for a specific project, great. When Developers run the design end of a project or are in charge of making UI pattern choices, the user often pays the price with poor usability or marginal aesthetics. With a few key concepts under their belt, the dreaded “programmer art” syndrome can be avoided.

Changing your ProcessTeamwork FTW!Parallel Design and Development Tracks

Rapid App Development (Blend, Thermo)

Proximity matters

Are there ways to do a roundtrip design/dev cycle? How about adopting agile like methods for your design process? New tools are coming out and maturing on various RIA fronts to help this, but a tool is still only a tool. ... How close are you to your counterparts? Can you talk in a office level volume and have them hear you?

Changing your ProcessTech to tryLet your designers help with XML (yes, even designing schema)

Have your Devs prep some graphics and maybe even do some skin design from time to time

Does your toolset allow for component creation? Teach your designers how they work!

When you have time in your workload, why not have designers and devs trade off a bit? Living in each other’s shoes a bit is a good way to cross train and will at least breed some empathy. Wearing more than one hat can be a productivity booster for a team and can serve to strengthen a teams understanding of the talent and value the other ones bring to the table. We have found it valuable when schedule and budget allow, it is a great idea to allow people to stretch their skills a bit and dust off some tools they might not frequently work in. Think of it as a training wheels approach.

Changing your ProcessPresentation and PitchingUnified front!

Who leads? Who follows?

Before the work is even won, it’s important to show a strong united front to a client and to use each team’s strengths to their advantage. After the contract is signed and work is under way, a team designee from each side should be appointed as a liaison to work with the Project manager when presenting work to the client. These presentations should be worked through with each team liaison prior to the client meeting to again give a united front for the client.

Growing ForwardHow do you keep the afterglow?Lunch and LearnsBarcampsSharing “AHA”s via a team blog

Continued development and grooming of the team dynamics are needed if the integrated approach is to take hold. Often, designers are not aware of new technologies in the development arena and vice versa. Little gotchas and tool tips are also great to share over a team lunch. When more confidence is achieved in the respective alternate roles, cross training can produce stronger, better more productive teams.

Growing ForwardRealizing the benefitsMeasuring

End of Project recapsKeeping up with trends and tech

After moving to such an approach, how will you know you have benefited? Is it simply goodwill amongst team members? Higher margins on projects? Happier clients? Higher overall billable percentages? When the success is realized and the process is fully implemented, what additional tools can be used on a fully cross trained team to make the work even stronger? Advanced tools, techniques and new software will be explored.

Following Upvisualrinse.comThis presentation for download

Reading list More posts on this topic - category: “ria”