John Saito, on Medium, has 7 tips for designing words. The best is the final one:
7. Write in mocks, not docs
Have you ever written something that looked good on paper, but ended up looking too long when it went live? That’s what happens when you do your writing in Google Docs, Dropbox Paper, or any other writing app.
When you write words for an interface, seeing the full context is so crucial. You need to know how your words are going to look next to everything else around it.
That’s why I prefer to write in Sketch mocks, not in docs. I find that writing in mocks helps inform my writing decisions, because I can see how my words will look in context.
Christine Hawthorne has a great post about microcopy on the GatherContent blog.
User experience design aims to make things feel intuitive for the person using your app or platform. Microcopy needs to act in the same way.
Just a few, carefully chosen words can go a long way in apps and can stop users struggling or dropping out of the process altogether.
Microcopy shouldn’t explain the design. It should enhance the user experience, working within context and to answer the question a user might have. For example, the copy on a button shouldn’t tell users to click it. It should say where they will go next, or what will happen when they press it, i.e, it saves the information.
Ellen de Vries, for the Clearleft blog:
- Gather up a set of magazines, some of which you feel have affinity with your brand, some of which are total wild cards.
- Establish a question that you’re hoping to answer with this exercise.
- Allow your team to spend time ripping out anything and everything that sparks their imagination, from the profound to the downright silly.
- Ask the team to group the images according to relevance. Do it out loud.
- Harvest their language as you go.
As they spoke about their choices, wild and wonderful language emerged, almost by accident. This language serves as an authentic starting point for the tone of voice.
Creating a tone of voice is something I’m asked about a lot, and this is an interesting approach.
John Saito on the relative merits of title case and sentence case in UX:
Much like the word “gravitas,” title case gives your words a feeling of formality and importance. Sites like The New York Times and USA.gov primarily use title case. It’s Professional. Serious. Established.
Using title case is like dressing your words up in a suit. For certain brands, you might want your words to look like they mean business. If you’re in the business of security, for example, title case is more likely to feel professional and trustworthy compared to sentence case.
Just as title case looks more formal and serious, sentence case looks more casual and friendly. I’m a writer at Dropbox, and we intentionally write in sentence case because we want our brand to feel natural and approachable. We think our product’s voice sets us apart from our competitors, and using sentence case is one way for us to maintain that voice.
I greatly prefer sentence case, for the reasons John outlines and more. I get irrationally bothered when people unnecessarily (in my eyes) capitalise words—particularly long strings of them—in an attempt to make things sound more ‘important’.
However, the title case example he presents does make some sense. His final thoughts are sensible advice for all writers and interface designers:
Title case and sentence case both have their advantages. Whichever direction you decide to go, just make sure you make an informed decision that makes sense for your brand. The worst thing you can do is to not have any standards at all, which eventually leads to inconsistencies that’ll be a pain to fix later.
Once your users start noticing inconsistencies, that’s when they start losing trust in your brand.
Today I gave an informal presentation to colleagues about monitoring, investigating and improving the bounce rate of our website, OpenLearn.
We all have different levels of understanding and experience of using Google Analytics, so this was a reminder for some and an introduction for others.
Below you can see the slides—they’re very minimal. You can see the slides with accompanying notes here.
Underneath there are some Google Analytics dashboards and custom reports you can use. Log into GA and click on a link. Choose a profile to apply the dashboard or report to it. It will then be your local copy, so you can rename it or modify it for your own needs.
I’ve collected some of these resources from various places and not noted where from. If any of them are your work, let me know and I’ll give you credit and a link.
I know the following embedded thing breaks the column it’s in—sadly I can’t resize Haiku Deck embeds to make them smaller.
Created with Haiku Deck, the free presentation app for iPad
(Remember, you need to be logged in to GA for these links to work)
Google Analytics dashboards
- Brand monitoring. A dashboard that focuses on how people found you by searching for you. Change any mentions of ‘openlearn’ to your brand name.
- No-bullshit. A summary of important data in plain English. This is especially useful if you’re not used to the terminology of Google Analytics.
- Site usage/quality. Browsers, devices, top content and bounce/exit rates.
- Visitors technology. Summary of devices, browsers, resolution, Flash capability, etc.
Google Analytics custom reports
- Search performance. Apply this report and use advanced segments to explore paid and non-paid search traffic.
- Browser version. How your traffic copes with different browsers.
- Mobile performance. All about mobile.
- Keyword analysis. Click the ‘engagement’ tab then look for troublesome pages. Click on the page title. Are there any keywords that are irrelevant? Solve with SEO.
- Link analysis. Which sources are helping your goals?
- PPC. How are your ads doing?
- Social media. Judge the success of your social media campaigns.