How to Design a Website . . .
There are many problems that arise when a designer (especially one with limited web experience) designs a site.
Firstly, designers seldom think "content management system", so they don't consider what would happen to their content area if it had five paragraphs instead of two, if the testimonials were longer or if the top bar link text was longer or the client wanted to add another link to the top bar. They also seldom ask for real world titles so you get designs that will only work with three word article titles for a client who averages fifteen word titles (and for good business reasons can't change).
Secondly, the design is not usually optimized for usability or achieving business intent. Only recently I was working on a site where a designer put a list of testimonials on the right hand side of the site. Now social proof is extremely powerful, but in this particular case I wondered why testimonials had been chosen over cross sells, a call to action for an email newsletter or one of the many other possibilities. Speaking to the designer, it appears that they wanted to balance the site layout visually and they had pictures of people handy but they didn't have any product pictures. Then the client approves the design and we have to implement it pixel perfect - irrespective of the HTML hacks required or the lack of critical though originally invested in the UI.
The question, then is how to solve this problem for very small web apps that still need rich functionality (you know, the "Amazon.com for $15k" crowd). We're now working with our resellers to get them to use our Intent Driven Design approach to elicit the business goals and the essential tasks (use cases) for every project. From there we're working on a system where we can basically build and populate the app and then simply skin it to provide an appropriate and professional look consistent with the business intent, Information Architecture best practices and the actual content that the site will have.
The biggest issue is that many clients can't "see" their website until it has their logo and their color scheme, but we think that for most smaller organizations, building the app first and then skinning it is a better approach that creating a design where the visual appearance trumps usability or how easy it is for people to achieve their goals using the site.
How do you handle this on projects that have to be specified, designed, programmed and deployed in under a man week of work? Any novel ideas much appreciated!
When I was in the NY consulting biz, for projects under 10K we had a gallery of designs with the list of items (usually stylesheet items) that could be changed on each for a fixed portion of the development cost. If you wanted anything more original than that, by definition it wasn't an under-10K project ;-)
Now that I work i n higher ed, my templates are determined in advance - that can be trying at times, especially for those elements of the template that I feel do not work for the web. But since the only "cost" is time, enforcing unified visual identity does take away the time pressure for building new apps!
/ejt
Of course, the designers you are talking about are almost certainly coming from print backgrounds where they can easily impose almost all of those constraints (or in fact, they are imposed upon them). Some designers I've had the pleasure to work with knew how to design for the web, so it wasn't a problem. Some apparently didn't, and it was a nightmare.
I think it might pay off to choose designers who know what to do on the web, and work closely with them. Not necessarily close with them for a long time on every project, but close enough over several projects so that they start to know /your/ style and what you are often looking for, as well as what goals there are to think about (who ever thinks about the goals? it's just supposed to look good!)
I also think having a customer fill out something that describes those goals is a good first step in getting a good design. I'm not sure I like the skin-only approach from a business perspective, but from someone who has to work with that design's point of view, I do.
@Sam, I'd actually argue that a skin based approach is BETTER for the client from a business perspective. While there are some sites that clearly need a completely custom site structure (especially portals and true web applications), for content management and e-commerce sites I'd suggest the following:
1. A "skin" based approach ensures the identity works with their real content so they don't get any surprises when their content doesn't work with the identity.
2. The wireframing first ensures that it is optimized to help them to achieve their business intent - not just to "balance the page".
3. The extra time spent designing a page from scratch and then writing custom HTML and CSS to match that exact design. What is the ROI? How likely is it that they will get (say) a 2% boost in measurable conversions because the went through that process? How much more likely would be a 2% boost in conversions if they'd spent the same time and money on creating multiple headlines, benefit statements and calls to action and running automated multivariate testing?
I actually believe that for the vast majority of smaller websites, creating custom designs and custom HTML/CSS provides a lower ROI than a number of other things they could have spent those hours on.
Thoughts?
1. The client knows from the start that we will not implement another designer's design without communicating with them directly in the design process.
2. The budget contains a set number of hours, generally 10-15, for project management time involved in working with the designer if they are the client's designer.
3. The designer must provide assets in a specific format so that we can modify them as needed.
4. All parties know they must adhere to the standards of the project. Therefore if something is not correct the designer will need to change it in a timely manner.
5. Contract terms state that the time line of the project is dependent on many factors. IF there is an outside designer then the time line may be dependent upon the designer's ability to produce the design in a timely manner and respond to requests for changes in a timely manner. These factors are beyond our control and therefore the responsibility falls to the client and their designer to ensure the time line can be met.
We are very strict on these points. We do not force a client to use our design services but we do encourage it. This is primarily due to our experience working with designers who know print design but not web and deliver files that simply do not meet web design requirements.
We typically do something like this, but it just seems to me a fundamentally bad approach as the client ends up paying (usually) for 30-60 hours of work (plus their designers time) for educating the designer, reviewing the design, implementing it using custom HTML and CSS and then fixing any issues on certain browsers. We can build an entire custom commerce site in less time than that. It just seems bordering on unprofessional to allow clients to waste so much money for almost no real value.
Of course, as always the client is right, so if they WANT to burn an extra $6,000 for no value (and on a larger project that isn't horrible), then so be it, but it just offends me that they'd ask us to spend even billable hour doing something that often provides no real business value.
Then again, I couldn't ever see myself building a custom website in any form in 30-60 hours. I would be afraid to release a custom project that I spent that little time on.
Then the problems begin . . .
As client adds more content we find some article titles are too long. We also find that "best guess" layout we went with for the product detail needs tweaking.
The client also needs the site template tweaked as they want a cross sell within the store they never mentioned earlier.
As fix grows on top of fix, we start to find that some of the tweaks don't work in all browsers or some of the changes to the site template to solve one problem break the other screen templates - someones only in some browsers.
I find that when this starts to happen we are VERY lucky to keep it to under 60 hours.
As for building custom web apps in 30-60 hours, that's why we live for code generation, DSLs, custom in-house frameworks and the like. Without that we wouldn't have a chance!
Absolutely, your development paradigm definitely saves you tons of time. A major difference for me is that, while I have been developing CF apps for over 10 years I have been inside a box, so many of the techniques you use I've not been exposed to.
That being said, I think a large percentage of my time is actually spent working on the "tweaking". That is to say that most sites I work on contain volumes of content and like you, I
have to tweak things to get it to fit and look good with the design, no matter the design being used. My solution to this has been to build that cost into the overall contract price. Naturally this does mean a higher price point. For me, this is a non-issue because I aim for a certain type of client that would see the value in those costs. It does put me in the position that I have to pass on many projects that might be profitable if I didn't otherwise care.
I think the answer is this: Does the client care enough to pay the extra fees? If not, explain to them the downside of not paying for that service and remind them of "out of scope" changes. The only way to mitigate the losses is to be strict about scope of work.
Of course, let me know about any of those projects you have to pass on - with my systems I might just be able to provide a solution and a referral fee and still turn a profit :->