The Web Gambit

Thoughts on Web Development

Developers and Designers

Web Developers that lack skills in User Experience Design often turn to Designers to flesh out websites via the creation of Comprensive Layouts (or comps). Comps are usually created in an image editor like Adobe Photoshop or Fireworks and are exported as static images, usually in the form of Photoshop (PSD) files. These images are then “sliced” into HTML/CSS markup and incorporated with both server-side code and client-side code by the web developer.

For those developers coming from a more traditional Application Development background, the inclusion of Designers adds a new element to an often neglected part of a developer’s workflow, the User Interface. While this can present challenges for inexperienced developers, it is the preferred way to launch high profile sites on the web today and the User Experience can be far richer.

I first gained exposure to this type of environment when I was a developer on the Professional Service team at Telligent.  The ideal project flow for sites that we launched on Community Server went as follows:

  1. Initial design work begins by Designers and they work to deliver a comp.
  2. The resulting comps are reviewed and approved by the client.
  3. Comps are then shipped off to a third party “slicing service” such as PSD2HTML or XHTMLized.  The resulting HTML/CSS is sent back and compared against the comps.
  4. Developers spend a lot of time working within the constraints of a web framework (such as ASP.NET) to get the markup to be generated exactly as desired.
  5. The final site is tested, approved by the client, and launched.

Unfortunately, as noted by Jon Galloway, this perfect workflow rarely exists in the real world. In my experience, this workflow is extremely inflexible to minor changes and hiccups.  Here are some of the common problems I ran into while doing this kind of work at Telligent:

  • The clients change their minds about the design after initial approval and the whole process has to start over, often resulting in a lot of wasted work.
  • The markup coming out of the “slicing services” isn’t clean enough and can’t be implemented within the web framework.
  • Designers aren’t able to meet their deadlines due to clients not providing timely feedback.
  • It’s difficult to find developers who are both skilled with cross browser CSS issues and can provide good quality server side code.

Because of the strong segmentation between Designer and Developer, there’s not much flexibility when direction changes and web development firms often build in large amounts of buffer time and high margins to make up for this.

I think web development firms that have put most of their energy behind ASP.NET are at a distinct disadvantage here.  In general, most ASP.NET applications are line of business applications with limited complexity in the UI.  Thus, most developers on the .NET platform have limited experience with cross browser quirks and don’t have enough CSS/HTML expertise. In addition, only recently with ASP.NET MVC has the platform provided sufficient control of the generated markup. For a long time, ASP.NET developers had to write their own Custom Controls or work within the constraints of the built-in primitive controls. Such custom controls often provided the necessary markup control, but usually required a costly maintenance cycle with difficulty making changes later on.

Other platforms such as PHP and Ruby On Rails were built with reduced friction between the Developer and the Designer. Most PHP and Rails developers can wear both hats when needed. I’ve worked with such individuals and I find that their workflow is far more flexible. Many of these developers are able to skip the comp step completely and work directly in markup. What they lose in speed by staying outside of Photoshop, they gain back in having flexible designs that can respond to change quickly.  And because their chosen development platforms are much friendlier to markup, the move to Service Side code is much more seamless. The downside is that their resulting code may have a lot of mixed UI/Data concerns, may not be very maintainable over the long run, or may not perform well under large amounts of traffic. But due to the limited shelf life of most of the sites, these issues can have a limited impact on the developer’s overall success.

I think it will be interesting to see how tools like SketchFlow and Expression Blend help blur the lines between developer and designer. And I think the potential is there to create a better workflow. Coming from an environment where UX was a first class citizen, I certainly miss the inclusion of Designers in the process. Hopefully one day some of the ideas coming out of the boutique shops will work its way into mainstream software development.


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: