Scripps in Beta
Written May 12th, 2008 by Marc NeedhamOur core values here at Scripps Health talk about ‘putting the patient first’ and the fact that ‘quality is our passion’. Our current website, scripps.org, doesn’t do a very good job of projecting those core values to the world.
The navigation, seemingly randomly selected, has been governed by the loudest voices in the room. In my experience, that voice never belongs to an advocate of the patient experience. The site itself has grown like a patchwork quilt or a weed – random shoots growing off according to which department happened to have the time, resources or attention span to develop content.
So we decided to fix it.
We began the redevelopment project with a team of one and a half and a long discovery phase. The first two months consisted almost entirely of in-depth interviews with organization stakeholders and people that interacted with patients on a daily basis. From there we got a solid idea of our primary target audience (patients, duh) and the amount of work ahead of us.
We worked closely with a local web development firm (PINT) to craft a thorough report of the findings and a new information hierarchy for the site.
Discovery dovetailed nicely with design where we applied what we had learned to the front-end of the site. Starting with the new navigation and some user personas we worked with three separate design firms and one internal design resource to produce a set of comps. These we further refined with some user testing and feedback from internal brand watchdogs. The final two design selections were then opened up to Scripps employees via a survey and a ‘winner’ selected.
Meanwhile, we worked hard setting baseline metrics, roughing out a content revision calendar and filling empty spots on the marketing web team.
Today we’re sitting on a fully-functional beta site waiting for the internal hosting environment to be ready for deployment. Due to some internal resource constraints we decided to build the site in Ruby on Rails. This proved to be a tremendously successful decision from a development standpoint but standing up a pair of Linux boxes in a Microsoft data center has presented one or two unique challenges.
Feedback on the beta site has been nearly universally positive. We continue to tweak it and smooth the rough corners while it lays waiting in the shadows.
Next steps for us include implementing a bevy of new features on the site, including a full third-party health encyclopedia, the ability for patients to book appointments and pay their bills online and creating some innovative and hopefully effective online marketing programs.
If you have any questions about the project, the site or what comes next, please feel free to get in touch with me – my email address is in my profile. The beta site can be seen at ScrippsBeta.org.
May 12th, 2008 at 3:03 pm
Ruby on Rails is an interesting choice. We’re a big fan of FOSS solutions here, and I feel your pain on deployment. How much of the development timeline was dedicated to building the CMS functions editors use? Where there any particularly good CMS samples for Rails out there you could leverage.
It was a bold move putting the design vote to the organization. But what a great way to get buy-in from everyone. Kudos!
I see the development office had a strong voice in the layout. I bet there’s a good story, there.
May 12th, 2008 at 7:41 pm
Marc,
Great job - the new site packs lot’s of options and navigation choices without feeling overwhelming. Web 2.0 is now the new normal. I’m also impressed at how quickly you handled the development process, and got buy-in from the organization.
As for us – we‘re going in a different UI direction. Here’s our inspiration:
http://producten.hema.nl/
(it’s in Dutch, just give a page a few seconds to load)
May 13th, 2008 at 5:05 am
Love the use of menus and the clean design. It definitely invites the user and puts them in control.
I believe RevolutionHealth used Ruby in their development, too- they used NavigationArts for UI and over 150 in-house developers.
May 13th, 2008 at 1:13 pm
I laugh at RevolutionHealth’s 150 developers. We had one developer. One incredibly talented, incredibly dedicated developer.
Bart - we devoted the first week of the Month Of Development (hereafter: MOD) to requirement gathering, analyzing the current CMS, site structure, user models, &c… Luckily our developer had a couple of recent CMS projects in his back pocket so he was able to pull from his code library and make appropriate modifications.
The CMS represents the bulk of the code base (15K+ lines of code all told) but probably only a week or two of development time, plus the time after beta launch we’ve spent tweaking and improving it.
Buy-in from the organization and the decision to go with Ruby came out of necessity. We just couldn’t get it done in-house and the clock was ticking for a variety of reasons. Some significant decisions were made under pressure but I wouldn’t change any of them if I had to go back and make them again.
We had a month to get it all done, I don’t think a team of people could have completed it in that time (too much bureaucratic overhead) and I don’t think another language could have gotten it done in that time.
July 8th, 2008 at 2:24 pm
Marc,
Very informative article. Thanks for the post. The decision-makers in my organization are pushing for a commercial WCMS solution (Oracle/Stellant or Vignette) to give order to our current web chaos. It’s frustrating since we have in-house development staff that are willing and capable of using open source technology to develop a CMS; yet I get the impression that senior management thinks we may be biting off more than we can chew by implementing a home-grown CMS . Did you encounter any of the same issues when going through your re-design? -LOVE the new site by the way-
July 8th, 2008 at 4:08 pm
Email’d.