Trying Something New: Going from Idea to Web Site Reality
Written January 10th, 2008 by Judy StokesIn Jake Bunger’s great post, he discussed the challenges of trying to create Web sites when we need the talents and cooperation of people from vastly different worlds: the left-brained, logical IT experts and the right-brained, creative communications and marketing folks. The lively comments to that post indicate that most of us have faced this dilemma. I have also likened it to serving as an interpreter and translator between different worlds and even between slightly different species. 
Here in my organization, we are trying a different approach to building a critical new Web site. I am sharing this process early in the game – check back with us in the summer to see how it worked!
What’s different? Well, here are the old methods we have used over the years.
Someone on “our” side has an idea for a new Web site or Web feature. Let’s say it’s the ability to search to see which of our doctors accept which health plans.
We go to the Web Team (the IT coders and developers) and say: We need a health plan search.
They say: OK, what do you need?
We sit in a meeting and discuss what we need. We say logical but vague things like: Well, we want the patient to be able to see a list of health plans and choose theirs, then see which doctor accepts that plan. We think that’s all very clear.
The Web Team says: OK, give us the list of plans and we will go build it.
Then we spend months of back and forth – at each stage a new question emerges. The Web Team comes to us and says: Well, how will this list be updated? What about doctor so and so’s record? We tackle the issues one by one, as they arise.
Then, on some date way into the future, the Web Team presents the product they have built. They are proud and happy – and get squashed by our reaction, which is usually “Huh? That’s not what we imagined! You didn’t do this, and this, and this. The list should be alphabetical (duh!). It looks awful!”
So, back and forth we would go, our timeline slipping ever outward, until we complete a feature just in the nick of that, that ended up frustrating all of us.
This time around, to create a brand new, highly interactive site, we are trying a new approach. Thanks to my colleague Jennifer Blake, who recently completed a course in usability training by Human Factors International, and took part in an HFI site evaluation of our intranet, we are trying out a new plan for site development – focused on building a truly user-friendly site. In the process, we are finding it helps our side focus and define our desires, and helps the Web Team in building exactly what we need.
It is proceeding like this:
The site concept was fleshed out and supported by stated goals, defined audience and features, expected ROI and tracking measures.
A pre-build usability process is in place, including concept testing with our target audience, feature definition, wire framing (rough, unattractive pages that define site activity and user page sequences), further user testing of those wireframes, graphic design exploration, and presenting our Web Team with the wireframes prior to any site or feature build.
In addition, we are sitting down in twice-weekly meetings with the Web Team to hash out and explore specific features, in an attempt to eliminate surprises and miscommunications.
How’s it going? Well, we are only a few months into this brand new process, but so far, so good! It has been a challenge to change our method – I am continually anxious that “nothing is being built yet!” But I am also encouraged by the increasing clarity we are gaining by taking this slower, more methodical approach.
Challenges? Our timeline is, perhaps, unrealistic. This new approach requires more upfront time, and how it will all come together in the end has yet to be seen. We still experience the IT/Communications push pull: IT wanting everything defined upfront; Communications knowing that we learn as we explore and user test.
I’d welcome feedback and comments from any of my colleagues who have tried the old method, our new method – or something else entirely!
January 23rd, 2008 at 12:34 pm
I’m sure we’ve all experienced the deadline-creep that happens when a large project is entered into without any agreed-upon goals. This applies to functionality as much as it applies to look & feel (“who authorized that teal background and blinking marquee text?!”) I’ve found the most difficult part is in selling the “assess, collect, coalate, design, then build” approach to launching a new website. A lot of time & money gets spent up front and the appearance is that “nothing is being done”, because it’s almost all vapor until the final (build) stages. But when I taught web design & development in college, I used the following analogy & example:
I’d tell the students, I want you build a deck for the back of my house. The back of the house is 45′ wide. Go. The questions would start in earnest at that point. We’d cover all sorts of stuff, and after about 15 minutes I’d say so what do we have? A lot of great ideas milling around (and a couple thinking about hammers instead of HTML), but no defined expectations or constraints. This was an exercise to get them to realize that the best way for me as the client to get what I wanted, was to define my expectations; and the best way for them to begin formalizing their grandoise ideas was to pin down my expectations as well as my limitations.
Judy, you are following the formula that I prescribed to my students, same as the one I try to follow for any project that lands on my desk. Bridging the gap from strategic to tactile takes the most work – but doing that work up front consistently nets the best results, and usually in the expected time frame and sometimes budget. But the intangible benefit is that everyone involved is on the same page once the building gets underway.
I predict, by the end of your project, you’ll be amazed at how first assessing everyone’s requirements and expectations, then collecting all the data and constraints, then assembling that into an agreed-upon hierarchy will facilitate the build process. Especially in terms of final design: you’ll see how taking a content inventory, then creating a content hierarchy from that drives your navigation and layouts, which drives your wireframes, which is the framework for your site’s “storyboard” … then a dash of color, stir in the content, bake @ 350º and voila. Let them eat cake!
Please keep us posted as your project progresses!
And no, I won’t build you a deck (but I could PM it for you!)
ps. thanks for the kudos too! (aw shucks)