Clear: A good dashboard clearly displays the required information. When a user looks at the dashboard, he should be able to get the purpose of the dashboard within the first 5 seconds. He does not need to stay there for a few minutes just to understand the purpose of the dashboard.
Meaningful: A usable dashboard contains meaningful information. Meaningful information describes what the designer wants to convey using this dashboard. The story behind the dashboard visuals should be understandable to the user.
Consistent: Great dashboards display information in a consistent format. Consistency needs to be taken care of for its layout, organization, and content.
Simple: A complex dashboard does not fulfill the purpose of its existence which is to present complex information in a simple form. If presenting information visually does not make it simple, then there is an issue with the dashboard design.
The most important step towards dashboard design is to know about the audience for whom you are creating the dashboard and what value will it provide to them. Knowing the background and level of their understanding will help you to create a design that is valuable for them.
While knowing your audience, it is necessary to understand what kind of data the audience is interested to see.
Focusing on the audience needs makes it easier to produce an outcome that they would love to use.
It is a possibility that your audience level varies from level one to the other. This is a challenging point and like any other design project, you can segment your audience and divide the information accordingly as basic and advanced content.
Selecting the correct metrics (KPIs) is another key element in designing a meaningful dashboard for your audience. There are multiple ways to represent a set of information in a dashboard. However, choosing the correct metrics is a key step in designing the usable dashboards. This also relates to your audience preferences that what kind of information they want to see.
Design dashboard as per needs — use different types of dashboards for different businesses.
Below are a few important rules to consider while designing a dashboard for your audience.
A very common mistake in designing the dashboard is presenting all information as if it is equally important. Use the size and position of content widgets to show the hierarchy of data.
Make it clear to the viewer what’s most important by defining information levels.
Display more important information on the top left. Move towards the bottom right direction with the information from more to less important level.
It is also possible to divide the information into categories and display them in different views.
The real purpose of the dashboard is to present complex information in an understandable and simpler form.
Don’t provide a lot of information that would be difficult to absorb for the user.
Use fewer columns to display information.
Reduce clutter by removing redundant content.
A dashboard looks better when it is designed using a consistent layout.
To make your dashboard easier to read, use similar visualizations and layouts between groups.
Put related information closer to each other.
Group related content visually.
Displaying related information together in a dashboard will help the user to understand it quickly.
Put related information closer to each other.
Don’t scatter related information across the dashboard.
Group related content visually.
Present related information on the dashboard in visual groups.
The elements of a dashboard need to align visually to make it a balanced look.
Do align dashboard elements with each other to organize better.
Try to place dashboard widgets in a Grid view.
An unaligned view does not give a good impact to the user.
An unaligned dashboard looks like incomplete design work.
Whitespace is as necessary to design as air to breathe. It provides a breathing space to the user when he is using your design.
Whitespace in the dashboard design appeals to the user when he comes to see the information.
Reducing whitespace will overwhelm the user with a cluttered view.
Use whitespace to group related information visually.
Lesser or no whitespace will encourage the user to leave your dashboard soon.
Use an effective color scheme to grab the user’s attention and help them go through the information easily.
Choose colors carefully to make the content readable.
Use maximum contrast to display the visual elements properly over the background.
Avoid using inefficient gradients and less contrast.
Standard fonts are the best fonts to display on a dashboard unless there is a specific need to use other fonts.
Use standard fonts as they are easier to read and scan.
Unusual and stylish fonts may look good visually but are difficult to understand.
Avoid All caps text as it is difficult to read and the human mind takes time to absorb it
Use a suitable size and style of font that communicate the information effectively.
Don’t use a font that affects the dashboard readability.
Displaying numbers with the more than required level of precision make them difficult to read and understand.
Round numbers where necessary as long numbers can confuse the user.
Truncate the unnecessary information.
Make it easier for the user to compare simple details.
Free speech in the patent world saw a big win on Friday, when the New Hampshire Supreme Court held that calling someone a “patent troll” doesn’t constitute defamation. The court’s opinion [PDF] is good news for critics of abusive patent litigation, and anyone who values robust public debate around patent policy. The opinion represents a loss for Automated Transactions, LLC (ATL), a patent assertion entity that sued [PDF] more than a dozen people and trade groups claiming it was defamed.
EFF worked together with the ACLU of New Hampshire to file an amicus brief [PDF] in this case, explaining that the lower court judge got this case right when he ruled against ATL. That decision gave wide latitude for public debate about important policy issues—even when the debate veers into harsh language. We’re glad the New Hampshire Supreme Court agreed.
Last week’s ruling court notes that “patent troll” is a phrase used to describe “a class of patent owners who do not provide end products or services themselves, but who do demand royalties as a price for authorizing the work of others.” However, the justices note that “patent troll” has no clear settled definition. For instance, some observers of the patent world would exclude particular entities, like individual inventors or universities, from the moniker “patent troll.”
Because of this, when ATL’s many critics call it a “patent troll,” they are expressing their subjective opinions. Differences of opinion about many things—including patent lawsuits—cannot and should not be settled with a defamation lawsuit.
“We conclude that the challenged statement, that ATL is a well-known patent troll, is one of opinion rather than fact,” write the New Hampshire justices. “As the slideshow demonstrates, the statement is an assertion that, among other things, ATL is a patent troll because its patent-enforcement activity is ‘aggressive.’ This statement cannot be proven true or false because whether given behavior is ‘aggressive’ cannot be objectively verified.”
The court ruling also upheld tough talk about ATL’s behavior beyond the phrase “patent troll.” For instance, the court looked at statements referring to ATL’s actions as “extortive,” and rejected defamation claims on that basis, finding that was rhetorical hyperbole. Another ATL critic had complained that ATL’s efforts “cost them only postage and the paper their demand letters are written on.” This, too, was hyperbole, part of the give-and-take of a public debate.
This case has its origins in the patents of inventor David Barcelou, who claims he came up with the idea of connecting ATMs to the Internet. As Barcelou describes in his defamation lawsuit, he saw “his business efforts fail,” before he went on to transfer patent rights to ATL and create a patent assertion business.
ATL began suing banks and credit unions that were allegedly using Barcelou’s patents in their ATMs. In all, about 200 different companies paid ATL a total of $3 million in licensing fees to avoid litigation—that’s an average of $15,000 per company.
But when they were finally examined by judges, ATL’s patents failed to hold up. The Federal Circuit invalidated several patent claims owned by ATL, and further found that the defendants’ ATMs did not infringe the Barcelou patents.
After that court loss, ATL had a steep drop in licensing revenue. That’s when ATL launched its defamation lawsuit, blaming its critics for its setbacks.
For software developers and small business owners who bear the brunt of patent troll demands and lawsuits, the New Hampshire decision sends a clear message. If you’re upset about the abuses inherent in our current patent system, it’s okay to speak out by using the term “patent troll.” Calling out bad actors in the system is part and parcel of the debate around our patent and innovation policies.
This is my advice on improving the UX of your designs WITHOUT hours of user research sessions, paper prototyping playtime, or any other trendy UX buzzwords.
Developers. You created your own app, but every time someone downloads it, they struggle to use it. And you know if they’re telling you this, then it’s really bad.
Graphic designers. Looking to make the transition into digital, but trying to learn UX by reading articles online is… a very painful way to die ?
PMs. Your job is already like 25% UX designer. Would be nice to level up those skills.
And the hustlers. Anyone working on digital side projects nights/weekends. This one’s for you too ?
If you’re already a UX designer, I don’t expect this article to go over super well with you. I’m basically skipping over entire chunks of our field in favor of focusing entirely on the single most lacking skill in aspiring UX designers (or UX-adjacent folks who find themselves designing screens).
I call it “speaking interface”.
When I started as a professional UX designer, I was shocked how many times my clients would hand me the initial wireframes (or the living, breathing, in-browser MVP) and there’d be completely obvious UX mistakes all over them. I’m not talking about things you need hours of research and A/B testing to discover. I’m talking, like, dead simple mistakes.
For lack of a better example:
Somewhere out there, there’s a team that knows HTML, but doesn’t know the difference between a radio button and a checkbox. pic.twitter.com/VBwk8Jxekd
Now my clients weren’t this bad, but look - you don’t need to be Bret Victor to understand that if you can only select ONE thing from a list, you need RADIO BUTTONS, not checkboxes. To understand that, you just need to be able to speak interface. And that’s the craziest thing to me. Interface fluency is something anyone can achieve. You don’t need college, you don’t need Lambda school, yadda yadda.
Frankly, you just need the presence of mind to (A) pause every single time you’re confused or frustrated by some app, (B) verbalize what about the interface makes you confused/frustrated/etc., and then (C) figure out how you could avoid that specific snafu that in your own designs.
Rinse and repeat that non-stop and you’ll be a pro in no time.
What I want to talk about today is four little rules that will help eliminate these pain points in your own designs. They’re the heuristics that are a level or two deeper than “use radio buttons if the user can only select one thing”. But, if you can remember to obey the things in this checklist, you’ll be that much closer to creating designs that your users can use easily right off the bat, freeing up your time for other, more important things.
(That’s when the other UX designers can lecture you on the newest academic user research methodologies!)
All else being equal, you should put the elements in your interface near where they affect change. This is because, when a user wants to make a change to the system, they will unwittingly glance at where that change will happen.
So, let’s say you have a list of things. Where do you put the “ADD A NEW THING” button?
Q: Well, where does the change happen?
A: At the end of the list.
Great, put the button at the end of the list.
WAIT. You’d think this would be pretty simple. But there’s a temptation.
The temptation is to just put it where we have space for it.
For instance, if you have a menu, maybe you’d think “We have a menu! Why not just put it in the menu!?”
The answer is, of course, because users won’t look for it there.
(And the ultimate answer is that having a place where “we just put things” will ultimately render your app an unusable mess that people will abandon the first chance they see a half-viable alternative)
Don’t think I’m joking. Have you ever noted this interface?
An equally-bad/common alternative is to just take a solution that you’ve seen applied by A Respected Tech Company without any thought as to if it makes sense for you. “We need an ‘Add’ button? I’ve seen one of those. Hold my beer!”
Look. Another button in a place users will never look for it. To compound things, users will suspect this button actually adds a new whatever-is-currently-displayed-on-the-big-blank-white-space. Because that’s where the control is.
Your users want you to follow the Law of Locality.
So, now that we know it, let’s use it.
Bam.
But maybe you’re a born UX designer and you always visualize what happens when there’s 1000 items instead of 5 and you realize: there’s still an issue here. If the user creates a TON of playlists, this button will disappear hundreds of pixels offscreen!
So maybe you could anchor the button near the bottom of the list, but have it always be visible, no matter how many hundreds of playlists the user has created.
For bonus points, (1) use the inline button UNTIL it’s about to go offscreen, and at that point switch to the anchored solution and (2) make it more visible than Spotify’s button, which took me months to notice while I haplessly right-clicked individual songs to add them to my playlists!
Brilliant! And this is what Spotify has done.
Another possibility is to say “Hey, we can’t reliably and consistently show the button at the bottom of the list. Where’s the nearest logical place to put it?”
And the answer is, (I think pretty obviously) the top of the list.
I wish.
Sacrebleu! This is actually just what Spotify-competitor Rdio did, before they were acqui-shut-down by Pandora.
Reconstructed from memory (like all reality, if you think about it)
The lesson here is clear. Never sell your company, and always always obey the Law of Locality.
(There are actually 3 laws of locality, and “Put UI elements where they affect change” is only the first. If you’re interested, read more here)
Next!
2. ABD: Anything but Dropdowns
Any time you feel tempted to use a dropdown, ask yourself if one of these 12 controls is better instead.
One non-obvious lesson of UX design is that dropdowns are pretty much the worst control.
Welcome to hell!
They’re not always bad, but you’re working against the following:
Dropdowns take too many clicks/taps. One to open, a few more to scroll around to the right option (on mobile), another to select the right option, and (on mobile) another to close. (Compare to the single click use-cases of many of the options listed below)
Dropdowns don’t show you the options! You have to click into them to see the possible values, and on mobile, you can often only see a couple at a time.
Long dropdowns are ridiculous to navigate. A country dropdown for an app used worldwide could have 195 countries. At some point, almost any other method of asking a user their country would be quicker than having them scroll through a dropdown (“Smoke signals?” AGCKKHKGH).
This is pretty straightforward, so let’s just cover some examples for the various major cases of dropdown replacement.
If you’re choosing between 2 options…
We already have some fantastic options for allowing users to choose 1 of 2 things, all of which (A) show the options right away and (B) require fewer taps/clicks.
For questions to which there is no “default” answer, and either might be picked with roughly equal frequency, try a segmented button.
If there is a “default state” that corresponds to “Off”, try a checkbox. A checkbox is also good for settings that don’t affect change until the user presses Save or Submit.
Similar to the checkbox is the switch, which is good for changes that should apply immediately.
Checkboxes and switches only make sense when there are two options. However, the following controls make sense for 2 to roughly 5 options, so you might try some of the following instead.
If you’re choosing between 2–5 options…
We covered segmented buttons above (and they apply here too) but it’s worth mentioning that when there are more options, vertical segmented buttons allow even more flexibility of answer length.
Radio buttons are similar, but particularly useful if you need to display a couple sub-elements for each choice.
For detailed displays of just a few choices, cards are where it’s at.
One trick I like is displaying visual options literally.
Tesla likes it too, apparently.
If you’re choosing between many options…
When there are enough options that scrolling through them is annoying, consider a typeahead control. It’s like a search bar that shows top matching results as you type.
If you’re choosing a date…
Picking a date from dropdowns is the worst. If I ever do this, then I’ve really failed as a UX designer.
But what do you use instead? Well, it depends. First question: what type of date are you picking?
Poisson dates. Dates most likely to be in the near future, tapering off as you go farther into the future (or nearer to the present), e.g. date of an appointment you’re scheduling, date of a flight you’re purchasing
High-variability dates. Dates that have a similar probability of being anywhere in a wide range of time, e.g. date of birth, day-and-month of your birthday
For different types of date-picking, you should use different controls.
For Poisson dates, you want to make it DEAD SIMPLE to pick dates in the most common range (e.g. for scheduling an appointment, it might be the next, say, 14 days). It’s perfectly OK if picking dates outside of that range is a little tougher.
A calendar control fits the bill rather well for Poisson dates. If you know the date to-be-picked is most likely in the next 2–4 weeks, you’re golden.
Rather creatively, Google Flightsdefaults to you selecting a flight roughly 2 weeks in the future, which is perhaps an opportunity for confusion (“I didn’t choose this!”), but probably a better date to default to, and closer to the hump in the Poisson curve.
Date text inputs are probably the best option for high-variability dates, where (A) there’s no reason to favor any date over another, meaning (B) all options will be equally difficult to select.
Remember, input[type=date] is your friend… on desktop, at least
If you’re choosing a number…
Numbers come in all kinds of flavors, but you’re most likely to be tempted to use dropdowns when you’re dealing with counts - e.g. the number of tickets, the number of people, the number of rooms, etc.
How often do you need 1 ticket? Plenty.
How often do you need 10 tickets? Not so much.
How often do you need 10,000 tickets? Is this some kind of cruel joke?
For counts of things, you’re also dealing with Poisson distributions, and should use a control that biases towards lower numbers - like a stepper.
For wide-range numbers (like, say, SSNs), you weren’t going to use a dropdown anyways… I hope.
So can I ever use a dropdown?
Sure.
Remember, they work OK when…
Users rarely need to change the default value
There are very few options - e.g. only 3 will be visible on the default iOS control
The user is not on mobile (whereby many of these problems are mitigated)
The particularly observant among you may have noticed that the Google Flights interface I lauded above actually has three prominent dropdowns!
Brilliant detail: on mobile, the ‘Economy’ dropdown is removed.
They actually do a great job with this. The potential usability issues are swiftly mitigated with:
Custom controls that show all options on tap (including on mobile) – and replace 4 dropdowns (for Adults, Children, and Seated Infants and Lap Infants) with 4 steppers in a single dropdown.
Removing the “Economy” dropdown on mobile
Few options and smart defaults for each control
If you want to print this section out and stick it on your wall, I’ve created a printable cheatsheet of dropdown replacements.
Anyhow. Let’s move on.
3. Pass the Squint Test
If you squint your eyes, the Most Important Thing should catch your eye first - and the least important elements should catch your eye last.
Pop quiz: what does a user need to do to use this page?
(NB: I’ve blurred it out so you have to go by gut instinct, but it’s a data entry form, to give you a hint)
My best guess is two things:
Check any applicable checkboxes (??) in the yellow area
Press the blue “Submit” button
Did you guess the same?
Wrong and wrong.
The “checkboxes” are actually very small numerical text inputs. (If you already read Anything But Dropdowns, you know Poisson numbers should be steppers)
The Most Important Thing (“Find Options” – which is a very confusing way to say “Submit”, by the way) is gray and unnoticeable. A much less important thing (“Help”) is immediately next it, but bigger and more visible.
The Squint Test says the Most Important Thing must be the most visible thing. What’s the MIT? The ticket textbox (or stepper ?) controls and “Submit” button.
If you make it past this page, the next page is even worse.
What will you click: gray button the left, or identical gray button on the right?
Hope you chose left!
In rushing through this form, I actually clicked ‘help’ first. Oops. My second time on this page, I clicked ‘Go Back’, having processed there was an ‘Add’ and ‘Go Back’ button, and in the other 99.999% of (left-to-right language) websites, ‘Go Back’ is always on the left.
Again, when I squint my eyes and look at the design, I can’t tell what’s important.
Like the Law of Locality and Anything But Dropdowns, the Squint Test is a fairly simple law to enforce. Here’s like a 30-second wireframey redesign.
In a real redesign, I’d also want to consider allowing the user to specify number of tickets ON THIS PAGE. But that’s another law for another time.
Does it work?
You tell me. Four radios and a button. And a tiny little link below it.
I’m not trying to pick on AlaskaTrain.com. You see this kind of stuff all over.
Here’s the signup screen for my beloved recommendation-based social network, Foursquare (blurred, of course).
How do you actually submit the required data? (i.e. the Most Important Thing)
Hint: it’s hidden in plain text in the upper-right corner.
But Foursquare is just following Apple’s design standards here. Unfortunately, violating the Squint Test is a tradition even among industry leaders.
One way to find the Most Important Thing is to consider what percentage of pageviews will involve a certain action. Here’s flashcard/memorization software Anki analyzed in this way.
For every 100 flashcards I view, I will then go on to…
Show the answer (approx. 95 times)
Navigate back to the list of decks (twice)
Start adding cards (twice)
Use some other feature (very rarely)
This sort of analysis really hints at what kind of interface would work better here.
Emphasize the most-commonly used functionality (at first approximation, “most used” equals “most important”)
Deemphasize, hide, or remove the less commonly used functionality
Now this is just a start (I’d want to see if users understood that the unlabelled plus button added cards, for instance). But with just a couple simple heuristics, we’ve reduced a cluttered, confusing interface of 10 UI elements down to just 5. A reduction of… check my math here… 50%.
For more on the Squint Test, check out my YouTube video redesign of the Timezon.es web app. Or, if you don’t have 10 minutes, here’s a scannable, illustrated blog post with the same step-by-step redesign.
4. Teach by example
If you’re introducing users to new concepts, a few examples can be worth 1000 words - which your users wouldn’t read, anyways.
We have a weird tendency to try and explain things in words when examples would be much clearer.
Consider the new startup Teeming.ai, who recently reached out to me to ask about their homepage design. Headlines on the page read:
“Teeming takes the isolation out of remote work”
“Teeming helps with remote team building” as well as “learning, problem solving, having fun, and motivating each other”
“Teeming and video for synchronous [communication]”
“Works with all your favorite video platforms”
But here’s my question for you. What does Teeming actually do?
It’s tough to tell. I know it has something to do with… good vibes for remote workers? But I have no concrete idea how it would help me, so I wouldn’t otherwise try it, recommend it, etc.
(Sorry Teeming, you know I ❤️ you)
Next, let’s look at IFTTT. Maybe you already know what they do - in which case, pretend you don’t, and try to figure it out from these headlines on their homepage:
Automatically light the way for the pizza delivery guy (Dominoes Hue)
Post your photo anywhere and see it everywhere (Instagram twitter)
Make your voice assistant more personal (Google Assistant iOS Calendar)
You don’t have to list too many examples to paint a decently clear picture: IFTTT hooks apps together to do things they couldn’t do alone.
The crazy part is, if you visit their homepage, they first explain it in text:
IFTTT helps your apps and devices work together in new ways. IFTTT is the free way to get all your apps and devices talking to each other. Not everything on the internet plays nice, so we’re on a mission to build a more connected world.
YAAAAWN.
My question: which gives you a better idea of the app? The examples, or the description? ?
I think it’s the examples. The description only resonates once I see a few examples of how it can help me.
The description of your complex new app/feature only resonates once I see a few examples of how it can help me.
But examples aren’t just for landing pages. Here’s what you see when you first sign into project management tool Basecamp.
Rather than seeing a totally blank page, you see two obviously pre-fabricated example projects that teach you, by example, how the whole app works (and also gives you an idea of what the tool will look and feel like when you’ve been using it a while).
Seriously, I can browse through fake chat logs by fake users discussing fake file uploads and fake to-do items.
There’s even a friendly… mountain?… telling me I can watch a 2-minute explanatory video about this sample project.
And thank you, Mr. Mountain, for the lead-in: providing videos showing usage is another way of teaching by example! Not only does the sample project model teach by example what my projects will look/feel like, but the video teaches by example what it looks like to use the software.
Brilliant.
If your app allows users to create something, a showcase is a great way to teach by example just what’s possible.
The beloved painting app Procreate won an Apple Design Award, the App Store Editor’s Choice, the App Store Essential awards, and John Gruber called it “groundbreaking”, etc. – and yet none of this is as viscerally exciting as seeing what you can create with it.
This ain’t no ordinary painting app.
Whoa.
That’s no MS Paint.
The showcase is a powerful tool for making it clear just what’s possible with your app.
So: if your app does something new and unfamiliar – or relies on new and unfamiliar concepts – you should get acquainted with the ways of teaching by example. The moment you realize that you’re introducing users won’t have seen before, you should start thinking: how can I give an example to make this clearer?
The moment you realize that you’re introducing users won’t have seen before, you should start thinking: how can I give an example to make this clearer?
In review, my favorite ways of doing this:
On any page that tries to get the user to use a feature/app/etc., show examples of what they can do with your tool
Use the “first load” experience to provide sample data, showing by example what the properly-working app will look like
Strategically inject help content (like articles, videos, or tooltips) inline with the feature that show how to use it
Does your app allow users to create something? Include a user-submitted gallery of examples to spur imaginations
Make sense? Let’s call it a day.
Alright, that wraps things up.
There are plenty more rules for “speaking interface” that I cover in my video course Learn UX Design, but these are some of the ones that I’ve used the most over the years. If you like these, check out more of my design writing on the Design Newsletter, where I send occasional, original design writing – as well as updates when Learn UX Design is open for enrollment.
Over 30,000 subscribed. No spam. Unsubscribe anytime.
In the last decade or so, content marketing has gone from the shiny new trend to a well-established mainstay of marketing strategy. From SMB to global enterprise, marketing teams big and small are producing content to help guide prospective customers towards a purchase.
It’s a great time to be a customer – it’s easier than ever to get the information you need to make a buying decision, before you ever encounter a sales rep. For marketers, however, there’s a downside to the prevalence of content available in their space: the competition for that crucial opportunity to educate the buyer just keeps going up. It’s not enough to simply have content any more. You need creative content that doesn’t just deliver information, but delivers it in a way that stands out from the crowd.
So how do you do that, at scale? We’ve written a whole book about this, but today we’re going to look at one key part of the process: rules.
Admittedly, rules aren’t what most people think of, when they think of ways to enable creativity. The more common conception is that rules prevent creativity, putting up barriers that stop artists from working to their full potential. But this isn’t necessarily true (and in fact, research indicates that constraints can actually make you more creative).
The key is having the right rules, for the right parts of the creative process. You want to have rules that set your creatives up to succeed, and help them avoid expensive (and demoralizing!) rework. The best way to do that is to make it clear what’s required, what to stay away from, and where your creative team can let loose. We like to divide these into three types of rules: hard rules, soft rules, and no rules. Let’s examine the two simple ones first.
Hard Rules have a right answer and a wrong answer, with no wiggle room. Think of something like using the right logo, or the right Pantone swatch – it’s either correct, or it’s not. These are actually the easiest rules to follow, because there’s no room for interpretation. Any and all hard rules should be clearly explained, and easy to verify.
No Rules are exactly what they sound like. If something isn’t prohibited in either the hard rules or the soft rules (more on those shortly), then it should be considered fair game for the creatives to explore. Even if not every idea comes to fruition, being allowed space to experiment helps your creatives deliver their best work.
Hard Rules and No Rules are both pretty straightforward: “do exactly this,” and “do whatever you want to.” The last category, Soft Rules, is where things get complicated.
These are rules that are more subjective. A prime example is whether something like an image, a word choice or even a whole topic is appropriate for a brand. While obviously you can issue guidelines, at the end of the day the person creating the content has to make a judgement call on whether or not their work complies.
This is always going to be the hardest part – ask anyone who’s worked at a creative agency for a large client with multiple brand stakeholders, and they can tell you that subjective interpretation of what’s “on brand” can vary wildly even within the same department. With Soft Rules, some potential for error is unavoidable.
What you can do, however, is work out a set of questions to help your team determine if they’re on the right side of the line. Examples:
“Can you imagine this written by anyone else?”
“Are there any buzzwords that should or should not be used?”
“Is this message aimed at one of our key buyers?”
“Does this conflict with the global brand standard?”
Soft Rules are also a good place to get explicit about things that might not be strictly part of the brand, but can still impact the content’s reception or success (i.e. the CEO hates a certain color or photo style).
Rules don’t have to be a buzzkill. With the rules of the road clearly known to your creatives – and with the default being that they have the freedom to do anything that doesn’t cross the lines – then you can actually get more, better work done.
