A few months ago I read Lukas Mathis’ through provoking essay “Designers are not Programmers” where he makes the case for a separation between designers and developers. To summarize his argument, thinking about implementation details distracts the designer from the user and results in applications (and websites) that are easy to build but hard to use. He makes a very thorough case (you should definitely read the full essay) but something just doesn’t sit well with me. In my practical experience, I find that teams are more efficient when roles overlap and people understand what is happening outside of their silo. Here are some reasons why:
- A designer is often faced with lots of options of how to solve a user problem. When it is a coin toss between two solutions, why not choose the one that is easier to implement and apply the time and effort saved to something that really needs the additional complexity?
- The static tools that pure designers use (e.g. photoshop) have no way to express interactive functionality. All the details that the developer needs to know need to be captured in some sort of specification that can never be complete and is usually out of date. Making the developers wait until the specification is done is inefficient.
- Good software cannot be achieved by brilliant designers alone. It takes iteration and feedback to get it right. A cold hand-off between the designers and developers lengthens the iteration cycle (so you get fewer of them in a fixed amount of time and budget) and creates more of an opportunity for information loss.
In an ideal world with infinite time and money (and omniscience too), it might be better to have designers whose minds are unencumbered by knowledge of implementation details. Anything that they dream of can be implemented… with enough time and resources, of course. But I don’t live in that world. In the world I live in, product managers and publishers have to make lots of compromises. They also need to be able to react efficiently to correct bad design decisions so that the product (or website) can continually improve. For that, you need an agile team that solve problems directly. this means staying out of a designer-only loop.
The most effective teams that I have worked on have all had a talented front end developer that can rapidly design in DHTML (leveraging javascript libraries and CSS) and knows enough server side scripting to make most user interface changes unassisted. With this mix of skills, it is truly amazing how quickly a small team can get a product in front of users where it can be improved by feedback.
Related posts:
- Tale of two developers Angie Byron, has wonderful post on approaches to contributing to...
- Designing for Drupal Nica Lorbor, from Chapter Three, has a great post on...
- Iron CMS George DeMet, over at Palantir, has thrown down the gauntlet....
- The Drupal Divide Recently there has been a lot of chatter about friction...
- Developers in Pain Just had to post this…. Developers In Pain – Funny...
I’m not sure I believe in “designers” any more than you believe in “casual CMS users”.
In the most successful projects I’ve been involved in, we don’t have visual designers. We have user experience designers. They will certainly start in Photoshop to get visual direction from the client. But our designers are all user interface people first and visual designers second. The visual design is driven by a careful analysis of what users actually do with the system, starting from personas and use cases.
The designers also understand how the web works (e.g. the limitations of HTML, cross-browser concerns etc), and how CMS’s work (e.g. the need for content-managed elements to be markup, not images, and the implications for what you can achieve in the design).
The next step from Photoshop is normally UI prototyping, using a tool such as Axure. This is then tested on real users. The idea is to see how the design helps users achieve realistic tasks. For a low-budget alternative, I’ve also used Mockingbird (http://gomockingbird.com)
Once this is complete, the PSD + prototype are turned into an HTML template. I find that having a “plain HTML” template is invaluable. Building anything straight in the CMS tends to cause the design to fall apart in a way that is difficult to counteract. A canonical, cross-browser-tested HTML template gives everyone a common starting point. In many cases, it has also proved useful in other integration work. (In Plone now, we also use tools like XDV or Deliverance which means that applying a plain-HTML template to the CMS is quite easy.)
Of course, the designs and prototypes also become the starting point for more technical implementation work, which is normally specified and prototyped in parallel.
Martin
I haven’t used Axure but it looks interesting. My chief concern would be that designers spend a lot of time building a specification in Axure when they could be building DHTML that can be used in the actual application. Also, in later iterations of the site/product, you will have to keep those Axure specifications up to date.
In our experience, prototyping using something like Axure is a lot faster, and the tool offers some useful extras, like a way to capture comments and produce something that turns into a functional spec.
It’s also sometimes an advantage that these tools limit the amount of “design” and realism you can achieve: a dumber, obviously throw-away prototype allows the discussion to focus on process flows and functionality, not colours and contours. When you think your prototype is going to be used for the actual build, there’s a temptation to perfect details that are not important for the prototype build, making that phase take longer or focus on the wrong things.
It depends a lot on the team and the project, though. HTML prototyping is certainly a valid approach in a lot of cases.
Martin