Redesigning HealthSparq.com
When seeking progress, the first step is to admit you have a problem.
For the past few months, we've been working on redesigning Healthsparq.com from the ground up. We were honest with ourselves: the old site kinda sucked. When we launched it, we were growing fast with a small team, and it didn't get much attention; we only had one marketing guy who was too busy to manage it; the agency we hired wasn't into it (we admittedly have much of a budget); the writing was without focus and replete with industry buzz-speak. And everybody knows, nobody clicks on sliders past the first slide!
Fortunately, our marketing team had both the need and the will to do the next site right. Where to begin?
Short version: Our team was not happy with our site, and there now was the will, the people, and the conditions to move it forward.
- We wanted to increase the number of demo signups (our primary KPI).
- We want to attract world-class talent to solve some incredibly hard problems. Our current site is deterring quality talent from considering work at Healthsparq.
- There are several, secondary goals, such as less publishing friction, a cleaner brand presence (more on that later - we're still developing a new brand), making information clearer to investors and media, and more.
Fortunately, there seemed to be sufficient internal pressure (we're tired of the old site – "push") and new opportunities (we can convert leads better, and hire quality people – "pull") for this project to succeed.
Don't forget the internal audience
The first task at hand was to learn as much as possible about what the business needed. In the field of user experience, it's common to focus on, you know, the users - typically the end user, the person using the site. That's important, of course, but what's also helpful and sometimes overlooked are the internal users: in many ways, these personas are as or more important to a project's success as the end users.
When you build a corporate site, you're building two things: a public experience for the end-users, and an internal communication platform for stakeholders to reach those users. A "design" and a "tool".
- Salespeople/Sales managers. As the primary KPI is tied to their needs, these folks need to know that we have the most efficient path possible for the pre-qualified leads they are sending to the site. What it also means is that the site is effectively connected to our sales tools, such as Salesforce. Some process mapping is always helpful at this stage, as it uncovers a host of hidden complexity.
- Marketing content manager. This person needs to be able to publish easily, manage content without getting lost, and have a minimum of fuss when managing the site. She is probably the internal person I tend to focus on the most: she will be using the site quite often, more than any other user.
- Executive leadership. In our case, this stakeholder needs to be kept informed and have a say at key decision points along the way, in particular with regards to content and messaging, which we'll get into in the content development stage.
The pre-qualified, potential customer is the most important user here. They will have been sent here upstream - via an email, personal contact, or some other vehicle. While we want an effective SEO search strategy, that's not our most important area of focus right now. They will, in most cases, have some information on the company and product, so we want to get them to the demo as quickly and easily as possible.
At Healthsparq, we're trying to recruit high-quality talent. We want smart professionals seeking a worthy challenge to experience these thoughts or emotions:
- This looks like a cool company. I'll dig further.
- This team is made of real people I can work with; they're not a bunch of robots.
- I can easily look for job postings and apply for one.
Once we'd established the priorities and personas, we could step into the user flows, content audit, and feature requests. We captured this quickly in Trello, which is outstanding for this purpose.
We could easily sort and prioritize as a group, and were able to create some date milestones as well to give a sense of how long things would take. It's also a great place to share images, such as other brands and sites we like for inspiration:
Trello is really an incredible app that works in real-time in a group - perfect for the loose, collaborative early days of a project effort. Note: for our app-development teams, we use Atlassian's Jira, which is much more robust and is designed to support an Agile workflow. Trello is good here for what we needed: fast, loose, and ultra-collaborative.
Content Modeling: A Content-First Design Process
Why design content-first? Because content is UX.
Liam King, in his article, Designing Content First for a Better User Experience, articulates the value of starting and defining the content first in a design projects. Often, by clearly stating what needs to be communicated to users at each step in the user journey - and building team consensus at that level - we can avoid costly visual design efforts that aren't needed, or aren't defined clearly enough.
Design is content. We made a vow, as a team, to purge Lorem Ipsum filler copy from our designs this year. Even if we don't know what the final copy will be, we can add something close (eg. "call-to-action proposition: why the user should register today"). This ensures our writing, visual, and interaction design are working together in harmony to achieve the objective at hand.
A while ago I wrote about expanded customer journey maps as a way to plan for device-agnostic design. But that document is only half the story. Expanded customer journey maps are great because they force us to plan what content will be needed before we move to page layout. That provides a great starting point, but crossing the chasm between knowing what content should go on a page, and how to design the best layout for that content can still be quite difficult.
What we need is an effective way to make content hierarchy decisions across all pages so as not to lose sight of the overall consistency of a site. Enter Content Slice Diagrams as a way to accomplish three fundamental tasks:
- Get an overview of the content across a site to make sure nothing is missing and there is consistency in layout where appropriate.
- Design the right size and hierarchy of each of the content chunks on a page, and see how it affects the page as a whole, as well as related pages.
- Provide any guidelines that writers may need to keep in mind as they create the content for the site.
Once the content slice diagrams are completed, designers and writers should have the following information:
- A clear understanding of the hierarchy of each page, which leads seamlessly into mobile first layout design.
- What the structure and nature of the content in each chunk will be.
That's everything you need to start working on layout.
...When I brought this technique to HealthSparq, my colleague Allan White had a great idea. He rightfully commented that OmniGraffle doesn’t make it particularly easy to drag content chunks around quickly. So he decided to use Trello instead. It allowed him to have collaborative meetings with the Marketing and Development teams as they discussed the hierarchy of each chunk:
Building on this concept, with a wonderful interactive tool like Trello, helped quickly "flesh out" the content chunks we needed for the various sections and steps in the site.
Wireframing & Flow Diagramming
Once we had our content slices in order, and some basic paths defined, we were able to sketch out our first flow on the whiteboard, rather messily and with lots of gaps:
But soon, with a few iterations, we had a more complete combo diagram (done in Omnigraffle) that encompassed user flow, basic wireframing, and copy:
This approach also helped with validating our designs in support of the desired user paths; it was quite easy to see at a glance if we were helping a given persona find their way to where we were guiding them. We could also point to a whole section (like News) and say, "that's in 1.1 - let's do that later". I decided to add a little bit of detail to the wireframes, enough for some basic layout ideas.
Now, we've been preaching "Mobile first" content development internally here, and I sort of broke with that philosophy here a tiny bit. However, I felt like we could do a tiny bit of 2D layout aimed at desktop designs, because our earlier efforts at content modeling went so smoothly in Trello.
Coming later: It's time to build stuff! Choosing a CMS, developing for a new brand, and more.
