“Content dictates design,” a UX designer colleague of mine once told me. At the time, I was less experienced, and just nodded and agreed—not understanding exactly what she meant.
Participating in a few large marketing transformation projects has helped me better appreciate the way in which content inevitably impacts the user experience. Content marketers, UX designers, technology teams, and other key stakeholders are connected in ways that aren’t always apparent at the project kickoff meeting.
Setting up a new site or app design with existing content is one of the most difficult digital projects to undertake, but it’s also one of the most common. There are just so many moving parts, hidden problems, opportunities, and unknowns. It can be difficult to get even a small project like this right, on time, and on budget.
What are the biggest challenges that leaders of these projects should keep top of mind when they’re launching new digital destinations? I came up with a list of my top six key UI and UX questions below.
The quick answer: setting objectives. If you don’t define objectives for each project, how will you know if they’ve have succeeded or failed? It seems like a simple enough concept, but in my experience, too many design projects don’t begin with objectives—or, just as bad, they begin with the wrong objectives.
Let me clarify what I mean by wrong. Many digital marketers promote a focus on the user, abiding by the philosophy that if you give the user what they want, you’re more likely to see success. That’s absolutely true. But why is it, then, when we define the goals and objectives of our site, we come up with stuff like this:
Yes, these are potentially valid objectives, but they only account for our own brands’ perspectives, and not the perspectives of our users. If we really want a project to succeed, we need to start focusing on the user before the first page is ever designed. Our users’ priorities should be our priorities, and their goals should be our goals. If we put ourselves in their shoes and make decisions based on what we learn, we’ll likely reach other objectives, like the ones defined above, organically.
The teams you choose to enlist, and the extent to which you include them in your project, can really make or break a project. If you include too few teams or stakeholders, you may have difficulty achieving buy-in as you get closer to launch. If you include too many, you’re likely to experience a launch-by-committee conundrum, and get stuck in the minutiae of trying to gain everyone’s consensus before you go live.
I asked Scott Ludwig, senior director of content services at Skyword, to weigh in on when and how to include other teams in your project. Here’s what he said:
From a role perspective, there should be buy-in from the most senior people on those [most invested] teams, as they are the ones that can communicate the vision down. Buy-in happens when key stakeholders are all in agreement. If they aren’t, a conversation should be facilitated to ensure all questions/concerns are put on the table—then a resolution can be determined collaboratively.
Scott made a great point: it’s important to include stakeholders and teams that have the most riding on your project early on in the process. Failing to do so can cause real problems later on. Sometimes a single conversation or small collection of well-timed meetings can accomplish a goal.
Defining the goals of your site or digital destination should be the first step. However, as I mentioned earlier, it’s important to know that you’re defining the right goals. The goal-definition stage of your project is a great opportunity for you to enlist the help of other teams. You should include teams and stakeholders that will know, firsthand or through empirical data (preferably both), what the priorities of your users are at the various stages of their decision process.
Empathizing with users seems easy, but it’s not. It takes real knowledge and experience to drill down past the fluff to get to the core of what they really need. When you’re setting project goals, acknowledge that your business objectives may or may not align with your customer’s objectives. If they don’t, you’ll want to get input from other teams—especially if they have firsthand knowledge of customer goals, behaviors, or preferences that they can share. Once you have their input, start by prioritizing your customer’s experience, and then, where appropriate, include business objectives if they don’t align.
Here are a just a few of the cross-functional teams I’ve included in the UX and design process in the past, to great success. In working with these teams, among others, I gleaned insights that might not have surfaced otherwise.
I love technology. I don’t really get worked up if I see an entertainment or sports celebrity, but put me in front of a tech CEO, social media personality, or famous startup founder, and I get giddy.
Many of us modern marketers are like that—we go to conferences to learn, but also to rub shoulders with “famous” marketers who inspire us. Technology can become like a drug to us. We want better, faster, more customizable technology; we want more gadgets and wave-of-the-future updates. If it’s new, we want it.
The problem comes when we choose our technologies without truly mapping them back to our objectives. (Are you noticing a pattern here?)
Knowing your project objectives is key in determining what technologies to use. And once you’ve defined your goals, you can decide how you’ll deliver on those objectives. Never approach a project the other way around—for example, developing a native mobile application just so you can say your brand has one, without a few good reasons why you’d want an app versus a responsive website. Your goals should always dictate your solution. Be confident that you make the right choice by weighing the pros and cons of each platform as it relates to your objectives.
A simple, yet effective way I’ve found to make technology decisions is to make a list. Put your choices in columns and your characteristics in rows. Either place a check box in the item for the one solution that wins the category or provide a relative score for each characteristic. The solution with the most check boxes or the highest score wins.
Here’s a good example from Mind Tools of a simple decision chart to get started:
The user experience and user interface steps almost always occur before corresponding content that will fill the page has been completed. That’s okay, but it’s important to mitigate your risk as part of your UX strategy. These tips will help:
The great thing about digital projects is that they’re all different. There is no one single plan or strategy that works every time. Is it sometimes okay to skip the UX or wireframe phase of a project and go straight into design UI?
I think the answer can be yes, but it’s really up to the business to determine when this is appropriate. For example, if you’re making a variation on a page or app because of a branding difference, it’s likely appropriate to skip the UX step and just produce a design. However, it’s important to not make too many assumptions: If you’re creating a variation in a page’s design, do the objectives of the user also change? If the answer is yes or maybe, then you should focus at least little on goals and UX. Assuming user goals don’t change without thinking things through can be a huge project risk.
Once again, I turned to Scott Ludwig of Skyword to weigh in on this:
In my experience, no. It’s easier to make changes with wireframes than UI. And even if you shorten the delivery timeline, I think it’s a critical step to get everyone on the same page before getting too far along.
Scott makes a great point about weighing the risk of having to redo something. Risk calculation is more of an art form than a science, and it’s something you can become better at over time. If the risk is too high, or you’re not comfortable skipping the UX phase, it’s probably best to include it. How does that old saying go? No one was ever fired for not skipping the UX phase of a project? Something like that.
One of the great misnomers of a project such as an app build or website launch is that the UX and UI phases only occur at the beginning of the project. The assumed project progression looks like this:
The above steps aren’t totally incorrect, but they don’t really illustrate that the user experience and design effort should be a focus both at the beginning and at the end of your project.
Here’s how I would update the process:
Notice the inclusion of UX and UI quality assurance near the end. I include this step because the creator of the experience is best equipped to validate that the intended experience has been achieved. Documentation can help, but a review of the final product before requesting user sign-off is a key step in releasing a product that does what it was originally intended—and designed—to do.
If you’re eyeball-deep in a marketing transformation process and still not quite sure about your upcoming project, download the Skyword Website Solutions Guide for more insights and best practices.