Content Strategy vs Design Strategy: How They Differ and How to Implement for Success

Jeff Hendrickson's picture
 By | February 16, 2017
in Business Intelligence, content strategy, design strategy, jeff hendrickson
February 16, 2017

Content Strategy is a function of your UX design work.

It has nothing to do with UI.  At this point in the project, we're deciding what to expose in our application – full stop. We aren't concerned with buttons, colors, or pages. We are concerned with tables, charts, visualizations – the business intelligence (BI) entities and components that follow the definition we've written from our user research sessions.

Design Strategy is the synthesis of your Content Strategy and UI design.

This strategy step defines the buttons, colors, and pages. It tells where everything goes, how your user gets access to what they need, and ensures that the overall User Experience is tight, relevant, and useful.

Doing the Two-Step

Step One – Research

The nature of BI and analytics projects dictate that we very closely define the focus of any application we design and build based on the specific use case, or user journey that we've discovered and defined from our research. The research phase is the critical first step and at times a misunderstood part of the whole.

The WebFOCUS products provide the foundation on which to build but they can't solve the problem if everyone involved doesn’t first understand the problem.

So who's involved?

  • Stakeholders
  • Users
  • Data architects
  • Developers
  • Designers
  • Content specialists
  • IT
  • The business department
  • VPs, directors, managers...

I think you get the point. Everyone is involved but yes, let's whittle that down to the key players in any BI project: stakeholders, users, designers, and developers. 

In our research matrix, we start with the stakeholder to get the overall picture and scope of the project. 

The stakeholder will guide us towards the data, the users, and the objective through a thorough understanding of the challenge. Once we have the users identified, we interview them in a way that helps them understand that they're being heard, and that their challenges are being defined and solved to the best of our abilities. We aren't going to promise the world but we are going to do our best to make life easier for them.

We're discovering the types of reports they have to produce, the data they must use to produce the reports, and the format they need to export to. If your company has stated that innovation is critical, or that the major thrust is towards monetization, then the need to help play data scientist and twist often long-standing practices around what to report is the way to move more decidedly towards those goals.

Often times, being a novice to the data is a good thing. Because you're not an expert you can ask questions left of center. You can cause subtle shifts in the mindsets of the experts that could lead to new ways to do business. I have a very interesting story to illustrate.

Whiteboard Design Thinking for Content Strategy

About a year ago, I was with one of our customers in the West and research revealed that a business manager would be the first person we would be designing and building an application for. After a few discussions with him and others I asked if just he and I could get into a room together, because it was apparent that he had frustrations I felt we could solve if I had a deeper understanding of his challenges.

We hit a room for two hours: him, another manager who works with him, and me. I went to the whiteboard and started drawing and asking questions about the data, KPIs, etc. At one point I handed him the marker and had him join me at the whiteboard. We drew wireframes, arrows between boxes, wrote figures, and did calculations. And at the end of the two hours he remarked that no one had ever done that depth of analysis with him before and that it caused him to think differently about his business.

The major point in this exercise is that because I wasn't a subject matter expert, I could ask questions that were outside the norm. I suggested putting together this figure with that – which had never been done before. I suggested tracking this indicator alongside this other indicator. “Hmmm. Never thought about it like that before but yes, that would allow us to then do XYZ and compare that to ABC. Yes, that works great.”

The moral of the story is that, as I've been told by the other manager in the room, when new challenges arise, that manager reminds everyone to “approach this like we did with Jeff.” That company now has a new way to discover what it might be missing by attacking the problem in a way that's visual and experiential. They are now experts at Content Strategy.

Step Two - Design Strategy Brings It Home

Now we can design the application UI. We can sit down with our new-found knowledge of the requirements and decide how to best represent this in the UI of the application. Here are key questions to ask, assuming that we're improving or refining an existing application:

  • Does this fit into our existing UI?
    • If not, how do we create space for it that's in line with current?
  • Is all the data readily available?
  • If not, what do we have to do to expose it for our use?
  • Who will be our contact for design iteration and approval sessions?
  • Can those be grouped in a logical way for improved workflow?
  • A dashboard?
  • An InfoApp?
  • Predictive and/or prescriptive components?
  • What combination of charts and reports do we need?
  • What's best for this situation?

You're acting as a combination of designer/editor/curator. What you design and build must allow the user to get the story out of the data in whatever capacity they require. They've given you and your team the challenge; now you need to sift through all that – as an editor – and get the true focus so that you create the best solution.

Your design strategy puts the face on the application. It's where all your research on content requirements gets proven in the software. If you've done it according to the principles and best practices of UX and Design Thinking – which we teach – then you have an approved application started in a matter of weeks. And because it's approved, not just considered to be okay because you know, we're IT, then that means people will actually use it. You win because you understand how to partner with business, and they win because they now know they can trust you. 

And I don’t make that statement lightly or without evidence. I spent a year working with customers whose major complaint was, “No one’s using our application.” Research always proved that while IT thought they’d built what was needed, Business said that the application didn’t meet their needs. There was always a mismatch in expectations.

As stated by a tech manager at a major university recently, "This will help us regain trust with our users."  Well put.

If I can get you to understand and trust one thing by reading this article it’s this:  everyone wins when we work with a focused and concerted effort to use this two-step approach of content and design strategy.  Break it down and get comfortable with the differences and you’ll create usable applications that solve your businesses problems faster, and with less reworks and loss.