We recently began a website redesign for a nonprofit foundation in the arts using a unique process: we’re going to develop the CMS for the site first and work on IA and design later. It may sound a bit backwards, but given this client’s particular needs, we’re pretty excited about the potential.
Since this is so different from our usual process, I thought I’d keep track of the project and share the ups and downs.
How is this different?
Every site I’ve worked on has gone through a planning and information architecture stage that laid out, at the very least, a sitemap, some wireframes, and functional specifications. This way designers and developers start out on the same page.
With the increase in sophisticated, user-friendly web development tools, though, this is no longer necessarily the case. When it comes to designing the presentation layer of the site (i.e. what elements appear on what page and where), there is now a lot more flexibility.
So, with this new project, we decided to skip past the wireframe stage and jump right into database and CMS development. I’m not suggesting that this is a great idea for every project, but in this case we felt we could make important headway, and gain important insights for user experience design, by getting content into the system, understanding the needs of this content, and letting what we learned along the way inform site functionality and structure.
How’s it going?
In short, it is going well. Several things, right off the bat, that I found different and interesting:
We started building the Content Management System first, creating buckets for all the information that needed to be displayed, the creating rudimentary, unstyled HTML pages. We set up basic navigation, created some listing pages, and started to see the site take some shape. We also created some taxonomies and other methods of tying related information. Issues came up, we resolved them right away, and gained a lot of valuable insight along the way.
The reason we decided to build the site framework first, and deal with UX and visual design later, is that the client was not positive what shape their content would take. This is actually a pretty common situation that is addressed during content strategy.
But this time, our client wanted to start adding content first so we could identify issues (e.g. missing buckets, incorrect data types, information relationships) early on. I’ve written before on the problems that can arise when content is entered late in the game. And Ross Berenson, our lead front-end developer, wrote a great article about the pros and cons of waiting to get content to begin design. So it’s been pretty cool to start with an almost completely populated database.
This, for me, has been the most educational part of our little experiment. The client and I sat together as I set up the CMS. Talk about crazy! As I installed Drupal and did the initial CMS configuration, he analyzed his needs, kind of the way a developer or UX Designer would: What content types do we need? What relationships need to be created between them? What are we doing with images and media files? A huge benefit here: our client has a much better understanding of how the site was built, and why.
We’ve gotten a good way into completing the back-end. Our client’s entered a lot of content and we’ve fixed some snags along the way. At this point, he’s almost fully trained on the CMS, and the website is almost fully populated with content, with very simple pages outputting real HTML on each page.
Now, we’re bringing in the Design Team to turn all this raw data and HTML into a great user experience. What’s great is they get to start with real content and content relationships that reflect the client’s needs. There’s no gray area as to what the content will be or what needs to appear on each page. As a result, our designers can focus on creating a user experience that effectively meets the goals of our client and their users.
Modern Page Building Tools
We’re using the Display Suite module to extend Drupal 7’s control of the HTML output. This system is so flexible and easy-to-use, almost anything the Design Team comes up with can be implemented. And it’s so straightforward that our client, with no Drupal or CMS experience, picked up on it right away.
Here’s a taste of what you can do with Display Suite’s drag-and-drop interface:
- choose which elements are displayed
- change the order of elements
- put elements into single or multi-column layouts
- control the output of display in different contexts (e.g. what is displayed in a listing view versus a full page view)
- control the specific output of a field (e.g. show the thumbnail image here, show the full size image there)
Pretty good stuff!
So what’s the rub?
Everything in life involves trade-offs, right? There are, naturally, some downsides to this approach. A few that I’ve experienced at this point:
Working this way is certainly less predictable from a budget perspective. Without up-front planning and architecture, how do you get a handle on project scope? This is a real problem that most likely requires a client with some budget/scope flexibility.
Most clients are not going to have the time to sit down with a developer each day and work through the site build. They’ve got jobs, too! But I’ve learned that the higher level of client participation in this process is incredibly beneficial. Developing for weeks with just the IA and specs gets the job done, but it can be challenging to explain everything to clients once development is done. It also can be time-consuming to make adjustments after things are fully baked.
But what’s it going to look like?
Seeing site designs early in the process is very reassuring to everyone. All the stakeholders get a great feel for what the finished product will look and feel like. Working in this abstract world of content types and unstyled HTML output can be a tough sell. Even in this experiment, I had to throw in some basic CSS to style it up a bit to make it palatable to the client stakeholders.
Organization of Complex Sites
The site we’re working on in this experiment is relatively straightforward. More content-heavy websites often have more complex needs, and therefore a lot more up-front planning. In this project, it was pretty clear we could move forward without as much planning. It’ll be interesting to see where the inflection point is for us in terms which websites we feel would benefit from this approach.
So, where are we headed?
Here are the top level takeaways of where we stand with our experiment:
- As the developer, I’m pleased because I feel the client is totally on-board with every development decision that has been made (a level of transparency that is normally difficult to achieve);
- The client is happy because he has a tangible tool that he is using to codify and enter his content and can already see the power and utility of the Drupal CMS;
- The client at this point is very informed about the structure, capabilities and limitations of the site and the CMS;
- I think the information architect and designer will be happy to know that they’re working with the real content to inform their decisions;
- The front-end coder will be happy because they can work on the actual site HTML
As I mentioned before, this is not a one-size-fits-all kind of thing. But, for me, I’m excited to see the potential gains as we progress through the remaining phases of the project.
Check back with us later, and we’ll let you know when our design team finishes their work, and they can let you know how the process helped or hindered them. Onward!
Projects & Insights
Put Your Content First!
Now and then, flashy website features serve content and user experience to great effe
The Aspen Institute
Writing for the Web: Developing Voice, Tone & Editorial Structure
Developing engaging content for your website demands a thoughtful approach to both st
4 Mobile Design Strategies for Content-Heavy Websites
You’re redesigning your website. Of course you want it to look as good on a mobile device as it does on a large screen. But do you need an app, too? For most organizations, a responsive website is more than sufficient. But, there are some things that a mobile browser just can’t do. Here’s a quick breakdown of four approaches and key considerations for mobile design.