Two words. Light Cycle

This is why people freak out about user experience design, or UxD, these days. We can define and justify and normalize everything we do during the course of a web project by referring to the user experience, and we can keep this experience in mind as a theoretical model to help us make decisions along the way.

But the user experience is only just that — a theoretical model — until you get real users. This is why we can’t begin a project with all the answers.  The answers to many important questions are provided by the users.  But the users don’t come until we’ve actually designed and built something.

Oh, the Catch-22!

The way out, of course, is by agreeing to launch with something that’s in some important way unfinished.  Knowing that our users will provide us with feedback that will shape the future site — that we plan and build the site in phases, and that these phases are informed by an ongoing engagement with the user experience.

As an agency, you need to go to great lengths to get your clients to understand this.  They can’t provide a spec, like a blueprint for a shed, and get a quote and schedule based solely on the blueprint, and then expect the actual shed to look exactly like the blueprint.  This is what they’ll want, because it’s easier to plan, and easier to budget for, and just generally easier to think about.  But it doesn’t comport with reality, so you’ll have to make a strong case for agility throughout the process.

And as a client, you need to go to equally great lengths to factor this fluidity into your own plans.  Remember the great triangle of software development: one side is budget; the second side is functionality; and the third is schedule.  You can’t fix all of these sides, because you’ll end in horrendous failure (the great triangle of pain and disappointment).  If you must, try to fix two; but leave the third one agile.

Say you’ve got a project with some fairly well-defined requirements, and pegged to a particular real-world date.  You’ve got your functionality and schedule fixed.  This means you must remain agile with your budget.  In practical terms, you’ll need to provide the agency with a budget range that is acceptable, and trust them (Trust them! Seriously!) to keep their costs down.

(Side note: if you can’t trust your agency to keep their costs down, you should find another agency.  This shouldn’t be an antagonistic process, but one where both sides share common goals.)

A second example, one that we see very often at HM: Say you’re a not-for-profit institution that secured funding for a particular project proposal from a big foundation.  You may see all three sides of the triangle as fixed: you promised a set of functionality in your proposal.  You also received a fixed amount of funding, and have a delivery date as part of the funding timeline.

In truth, though, one side of the triangle has to be flexible in this situation.  Chances are the foundation won’t increase the budget, so one of the other sides needs to be subject to change.  This may require some advocacy on your part to get the flexibility you need from the funder, but the big selling point here is the main goal: a beautiful, functional, memorable web experience that users will visit again and again because it was built around their needs.  If you can’t get it all done in the budget and timeline provided, consider this a first phase.  Phases are good!

Check back next month for a new installment.

Tucker Viemeister is Lab Chief, heading research and development at Rockwell Group. The Lab recently made an interactive introduction installation for the Venice Architecture Biennale. He was a founder of Smart Design where he helped design the widely acclaimed OXO “GoodGrips” kitchen tools. He also was president of Springtime-USA, a partnership with the Dutch industrial design company, he helped to found Razorfish’s physical design capability and frogdesign’s New York office.

A graduate from Pratt Institute, Viemeister has worked for clients like Apple, Corning, Gap, J&J, Jet Blue, P&G, McDonald’s, Timex, Levi’s, Motorola, Vodaphone, Unilever, Coca-Cola, Nike, Toyota, Viking, and Kate Spade. He serves on the Board of Directors of the Architectural League of New York, chair of the Rowena Reed Kostellow Fund, president of the International Design Network Foundation He was called “scruffy brand-meister” by the Architect’s Newspaper (2/06) and New York Magazine selected him as a “Living Design Innovator” (10/29/07). He teaches at NYU’s ITP, holds 32 US Utility Patents and was named after a car.

Then we really started using it.  Then Drupal 6 dropped.  Now, D6 is our development platform of choice, and our default platform for many kinds of projects.  Here are a few types that range beyond the typical “site with managed content” category.

Flash front end with CMS

We’ve developed two sites where the client needed pervasive animated elements that required us to build in Flash.  We still wanted to give the client content management capabilities, however, so we resolved to do it with Drupal.  Our Flash developer, who is awesome, built his piece around an assumed XML data source, and provided us with a static XML sample.

We modeled the data as Drupal “books”: each book is a site section, and each section contains pages and other nodes as needed.  CCK and its closest friends (Filefield, ImageAPI/cache) are sufficient to fill out the core modules for this.  The we wrote a custom module that iteratively goes through each book and uses the structured node content to fill out an XML template.  The system handles image attachments and Flash video references with aplomb.

Our theme consists of a quick modification to Garland that serves up the Flash file on a clean, white background if the home page is requested, and the typical Garland page rendering otherwise.  This lets Garland show the structured content and admin pages to authorized users, while public users only see the Flash.

• http://mesaglobal.com/
• http://uniworldgroup.com/

News aggregation and volunteerism portal

The three founders at Fractor, no intellectual slouches, won themselves a MacArthur grant for their novel idea: a way for users to look at top news, and for each story see a list of related opportunities for volunteerism.  Facts plus acts equals Fractor.

We designed and built the identity, design, and site with them.  The site is in semi-private beta now.

The theme consists of typical Drupal-rendered pages, but also of a persistent “news finder” layer, a jQuery-run news browser application that shows by default on the home page and stands at the ready on other public pages.  In this layer, you can easily browse through thousands of news items by category and see the top volunteer act related to each one.  If you click on one of the news items, you’ll see a detail view that shows a longer list of related acts.  All of this happens with a good bit of Ajax, so that the user experience is of an application that lives in a separate layer over the rest of the site.  Since it’s aggregated news and constantly updated, we had no SEO worries with supplying so much content through Ajax.  Fun stuff.

• http://demo.fractor.org/

Rapid prototyping

As we’ve said before, Drupal’s flexibility actually allows you to prototype a site before you need to commit to much in earnest.  It also allows you to fill out content without making huge commitments to content structures — or the site structure, for that matter.

One of our clients came to us in January with a need to get a prototype up for an international media conference — in February.  The idea behind the site is to serve as a support and networking platform for independent citizen journalists.  They can store and share footage, craft their projects online, and learn from seasoned professionals.  The client didn’t have the whole site structure or functionality in place; indeed, they wanted to use feedback from the conference attendees to help determine the course of development.

So we took a month to prototype a fairly robust site that allows users to create profiles, upload footage, and contribute footage to other users’ projects.  We’ve also got a second set of professional or “faculty” users who can create instructional blog posts and upload footage and files.  We did this by making three important decisions:

1. Write a minimum of custom code, relying instead on the most rock-solid modules in the community.
2. De-emphasize theming, which can eat up a lot of time without providing much benefit in the prototyping phase.
3. Take advantage of a third-party media delivery network (Kaltura) with a well-written Drupal module already available.

http://mojo.helen-marie.com/

It was an open question how best to take advantage of this community to benefit the magazine.  But instead of starting with obvious questions — Who are these users? What do they care about?  How can we increase their enthusiasm for our brand? — someone high up in the magazine’s interactive food chain had a classic technological panic. The panic took this form, probably late at night:

What about social networks?  What about Facebook?  What about Twitter?  What about blogging?  Everyone’s doing it but us!  We need to catch up.

So the magazine built a social network.  It probably hired an agency that affirmed the magazine’s fears of obsolescence and charged them an outsized fee to build every last microblog and Twitter integration, user profile, friend-manager, minifeed, video uploader, and widget that they could imagine in their darkest nightmares of media isolation.

The magazine launched their Spanking New Social Presence and, to their shock, lost all of the users who had made their old bulletin board such a lively place.

That’s how this writer I met, a young, urban, male Brooklynite, got his job: every day he logs in as five different women and maintains their ghost user profiles.  He simulates social activity on a social network that was conceived in panic, cost the magazine a good deal of increasingly scarce resources, alienated the community it was supposed to engage.

Instead of starting with open questions, this online initiative started in a panic.  And now they have a structure that requires them to lie through their teeth just to present a semblance of activity.

Don’t let this be you!  Start with the right questions about your situation, and be open to the answers that you’ll find.  For some organizations, blogging, Twitter, and a Facebook presence are just what the doctor ordered.  Those who are  lucky enough to have an existing online user base need to start with their users.  Users are the lifeblood of a participatory web.

And remember this: the structure you build brings with it a certain infrastructure, and that infrastructure must be maintained.  If you create employee blogs, you better make sure that your employees have something to say, and are trained to publish on a regular basis.  If you push your staff to sign up for Twitter, you need to make sure that they’re actively writing — and, I hope it doesn’t need to be said, that they want to write.  And if you let users create profiles and write blog entries, you need staff to review those profiles and posts on a regular basis.

An empty social network is just like bad standup comedy: nobody wants to be in the same room.  Make sure that your room, regardless of its size, makes your audience want to come back.

For many of our clients, the worth is apparent, either because of their past experience in this arena or their experience with similar creative services (advertising, brand strategy, business consulting, etc.).  It’s a relatively straightforward process to translate a strategy into a proposal and budget with clients like these.

For many other clients, though, even those with deep pockets, the web is a hard place to get a grip on.  This could be because technology scares them.  They might equate their IT budget with the kind of work that we do, because of they perceive a shared arena of activity.  Or the web to them is an infinite realm of untold, mind-boggling possibility.  Or, maybe, they’ve stumbled through every creative project they’ve ever embarked on in the past, and expect that we operate in the same fashion.

There are myriad ways to get to a common vision of the value of the work that we do.  And keep in mind that we don’t mean only us; we want to arrive at a common vision of value for our industry, not just ourselves.  We may not be the firm for you, but you’ll have a much more successful search if you can better quantify the worth of your project.

So, the “we” and “us” below don’t refer just to us at Helen Marie; we’re presumptuously speaking for the industry.

The bottom line

An easy one. You, the client, need us to do something that you estimate will affect your bottom line by X dollars in the next year.  You want to come out ahead, so obviously our work can’t cost X dollars.  But it shouldn’t be surprising for it to cost, say, half of X.  Your payment to us is fixed, but the value to you increases beyond the next year.  Our fee, then, decreases over time in relationship to the change in your bottom line.  This is math that you can do in advance of your agency search, and that will help you square your available budget against what you’re asking an agency to produce.

What it would really cost you

This often comes into play with calculations against your IT budget, because you imagine that the IT team can do work similar to ours.  Our long experience working with (and in) IT departments is that this assumption is always, always wrong.  And your IT team will be happy to disabuse you of the notion that they can magically transmogrify into a group with decades of collective web experience who can give your project the attention and focus it deserves.

If you can’t square our cost against your IT team, then what other point of reference do you have?  You can look at the job listings for web designers, web developers, information architects, and interactive project managers, and piece together the cost of bringing them on salary for a year or more.

Our experience

If you think a project is expensive, try doing it twice.  Or three times.  This happens often.  As we’ve said elsewhere on this blog, we’re often approached to redesign the client’s current site.  And the current site is often some kind of minor tragedy of wasted time and money.

We don’t guarantee that we will design and build a product that will answer all your needs for the next ten years.  What we do offer is the experience to make intelligent choices, and the opportunity to educate you on the process and help you to make informed choices.

Peace of mind

There are few experiences more relieving than finding the perfect experts for your problem.  You can’t quantify the dollar worth of that feeling.  But you can imagine paying for it.

This matrix exists in a Platonic form where all of the requirements and conditions map neatly to available functionality and structures. It’s only when I populate it with the real-world facts of a project that gaps emerge. Those gaps identify the responsibilities and data structures that we’ll need to delegate to our own modules. Once we group these by logical or functional affinity, we have our module strategy.

For instance, while scoping a recent project it became clear that the client was asking for functionality resembling part of an e-commerce application.  Part, but not all: the client wouldn’t specify the order, but would rather be supplied with a template of an order, and given the option to alter details of the order before submitting.  And instead of processing payment, our application would submit to the client’s fulfillment department, who would then issue an invoice and process the order through existing systems.

We could have scoped this by documenting order flow, architecting the process, and writing a technical brief that would summarize business requirements and accompanying functional requirements.  Instead, we built a Drupal prototype to explore how far existing modules would get us.

You can see a very basic iteration of this prototype here:

http://d1.helen-marie.com/

Barebones indeed.  But that’s the point: this took fifteen minutes, and supplied us with much more accurate information regarding how we could work around the assumptions of the UberCart module.  Those assumptions form the core of our module strategy.  On top of that, we build in time and budget to cover theme development, and we have our basic scope and requirements.  We also know a lot more about our upgrade path than we would from an abstract scoping document, because we can cite UberCart’s support and upgrade history (as well as Drupal’s, of course).

And on top of that, we could show the client a working example of a portion of the proposed functionality.  That’s exciting for everyone involved, and comes at a very small internal cost.

The customization strategy becomes clear:

• A user of type A (or, in Drupal “role A”) can create an order for a user of type B.
• Type B user receives email notification and link when order is created.
• Order is considered “paid” by UberCart when submitted.
• Type A user receives email notification with order details when it is submitted.

That wasn’t so hard, was it?

One of the reservations underlying this approach is this: “What if I pick the wrong modules the first time around?  What if my scope is affected because I change my mind about my module strategy after the client accepts the budget?”

This is a risk you run whenever you pair a scope and a budget.  It doesn’t matter what platform you use, or how specifically you set your scope.  This is a problem you solve by setting a budget that allows for a certain degree of agility (i.e., making useful mistakes, learning from them, and correcting) during development.

Happy 2009!  OK, back to work.

Note to developers and designers: you still can’t layer HTML over Flash, and you still need to design around it.  Sad, but true.  For instance, this page on change.gov has the classic problem: a Flash video player at the top of the page, and a menu that draws a layer on rollover.  The two are not friends.

In its natural state:

On mouse over — whoops!  The video’s “play” icon shows through the menu:

It’s a problem on standards-compliant browsers and elsewhere.  There are two ways around it: hide the Flash player when the menu layer appears, or design around it.  We recommend the latter, as it enables you to avoid hacks or sleight-of-hand.

If you need the video right there, though, you’ll have to figure out a better way.  And if you have to resort to trickery, you might as well entertain yourself.

Fixing change.gov’s problem

This page uses the uber-popular Media Player from Jeroen Wijering, which unlike the QuickTime player is fairly scriptable.  But instead of making any calls on the Flash player or its helper scripts, we’re just going to destroy it entirely.

The goal is to replace the video player with some kind of flat HTML whenever the mouse is over the menu.  Then we can guarantee that the menu layers will always layer properly over boring HTML elements instead of being invaded by underlying Flash goobers.  When the mouse leaves the menu, we can restore the original video player.

You’ll need two main entities: a listener, to respond to the menu rollover event; and a Flash player handler, to hide and show (or destroy and re-create) the player.  Luckily, change.gov already has the former; it’s in this JavaScript file.  Our modified version, available here, has two additional method calls at lines 95 and 106.  These refer to a nav handler object defined in this additional JS file.

I made one substantial change to change.gov’s original HTML: I gave a class of “wrapper-video” to the div that contains the video player.  The nav handler will work on the assumption that every video player that might be affected is classed with “wrapper-video”.

When the handler’s setOver() method is invoked, it loops through “wrapper-video” divs.  For each div, it caches the original HTML and the calculated width and height.  Next, it sets the div’s background to an image: in this case, an exact still of the video player.  E.g.:

Looks convincing.  The image file name contains the dimensions, and setOver() takes advantage of this by constructing the file name dynamically.  This way, if you had more than one video player size, you’d be covered.  For good measure, we also explicitly set the div’s width and height, so it doesn’t collapse when we erase its contents.

Once all of this is done, we call jQuery.html(”") on the div, erasing its contents.  Now it just shows the background image, and will play nicely with the menu layers.

When the mouse leaves the menu area, navHandler.setOut() restores the original HTML contents of each video wrapper div.

You can see a working example here.

The files are also available for downoad as a ZIP.

The better solution clearly would be to design around this issue, but all too often we don’t have a lot of choice.  If video is the featured page content, there’s rarely a good way to push it safely towards the fold.

(Caveats: browser testing, your mileage may vary, etc.)

• Words
• Links
• Buttons
• Input fields
• Columns
• Boxes
• Scroll bars

Mmm, boring list.  That’s good, though: this should not be the exciting part.  The exciting parts should be the purpose and content of the web site, and the look and feel that give it life — the struggle and the glory of web design. The elements in the list above should be the basic tools, not the wheels you’re going to reinvent in order to make your site the greatest thing ever to happen to the web.

We’ve come a long way on in web design in the last ten years.  We all used to feel compelled to re-think every element of every page: scrollbars, link treatments,  you name it.  There was scant agreement on a common toolbox of elements and techniques, even though experts like Jakob Nielsen were (and still are) pushing us to adopt just such a toolbox to make the web a more usable place.

To organize these basic elements, your agency will engage in a period of information architecture, or IA.  IA is a discipline that organizes the information, structure, interfaces, and functional goals of a site, and provides guidance in these areas to both the designers and technologists involved.  (At Helen Marie, we consider IA a cross-disciplinary practice that involves all of us: producers, programmers, designers, and clients.)

The process of creating these documents will also enable you to see the first abstract view, the “bones”, of your site.  If you were designing a house with an architect, you’d use this phase to decide where things go: is there a bathroom attached to the kitchen?  What about in the front hall instead?  You’ll run into similar structural issues with your site: Do we have a separate “frequently asked questions” page?  Should it be its own section in the site, or in a larger “help” section?

Sitemaps and Wireframes

On common IA product is a sitemap.  This document provides a bird’s-eye view of your site, its major sections and pages.  Another is a wireframe.  This is typically a collection of documents that describe the interfaces and organization of elements on each page of your site.

A simple sitemap might look like this:

As you can see, the sitemap can indicate pages or sections that you want to include in the future, as well as those you mean to build immediately.  This is a smart, cost-efficient way to start planning your site in phases.

A wireframe can be more or less complicated, but generally looks something like this:

Wireframing is an opportunity to hash out what each page will contain, and how it will prioritize and organize its content, before the designers get to work.  This process also enables you to make concrete decisions about what features and content are important on your site.  These decisions can be easy or difficult, and this can affect the length of the IA process.  But it’s always much easier, and more cost-efficient, to wrestle with these issues at the very beginning, before designers start putting the flesh on these bones.

Part of our job is to focus this enthusiasm into disciplined decisions about how best to serve a particular client and a particular project.  We have a lot of healthy arguments that start with, “Wouldn’t it be cool if…?”  The question is often followed by, “I agree, but we shouldn’t do that in this case because….”  Or, just as often: “That’s great — but let’s consider that for phase 2.”

We go through this in order to avoid three big pitfalls: building more than the client needs or can immediately use, rejecting new approaches or techniques because we’re unfamiliar, and committing to unreliable approaches or techniques because the coolness factor affects our judgment.  We wrestle with these issues so you don’t have to.

(There are a lot of interactive technologies that are the equivalent of a two-seat Lotus Exige: extremely cool, but maybe not what you need.)

You may have done your own research before you even found us, however, and decided that your new site absolutely has to include X, or be built on Y.  We often meet with potential clients who say, “We want our new site to be built on [insert trendy platform or poorly-understood technology here].”  Why, we ask? “We’ve read about it, and it looks like the best new technology for us.”

This is an ideal point to ask us what we think of the idea, and whether we have other recommendations.  That’s the beginning of a great conversation that will help you to educate yourself about your options, learn something about us and our experience, and save money in the long-haul by making the right decisions when you have the most flexibility – i.e., before you start down any road.

You’ll be able to meet the overwhelming majority of your project’s critical strategic needs with proven, industry-standard design and interface practices.  Your agency, if they’re up to snuff, will have a toolbox of information design, user interface, and technology solutions that apply in some manner to almost everything that can come up.

Your first contact with an agency should be a great learning experience.  I know that I love talking to potential and new clients about the broad strokes of planning and building a web application.  I call it Everything You Always Wanted To Know About The Web But Were Afraid To Ask.  For you, the client, it’s free advice; for us, it’s a chance to show you how we think and work.