SEO and Usability

At first glance, search engine optimization (SEO) and usability seem to be quite distinct topics:

  • SEO is about attracting people to your site in the first place by making sure it shows up in search queries.
  • Usability is about people’s behavior after they arrive on your site, with the main goal being to increase the conversion rate.

Basically, SEO happens before the first click, and usability takes over from there. Both need to be good for a website to succeed. Having great SEO but lousy usability means that you’ll get lots of traffic, but the visitors won’t turn into customers. Conversely, a site with great usability but lousy SEO simply won’t get many visitors, so it doesn’t really matter how good it is.

Although they focus on different phases of the lead-generation funnel, there are many ways in which SEO and usability support each other and a few ways in which they conflict .

Keep reading
Gamasutra: Laralyn McWilliams's Blog - She's Not Playing It Wrong

When the conversation turns to women working in game development, as it has frequently for the past few years and intensely for the past few months, you often hear the same points raised. I’ll use one of them as an example: booth babes at E3. There have been efforts to reduce or eliminate the presence of booth babes at industry events for years. They’ve been eliminated at some events like GDC, but not at others–and E3 is usually the event that comes up along with this topic.

In those discussions, there are several points that frequently take center stage. First, that a product showcase with scantily-clad women as hostesses sends a strong message that “this is for men, not women.”

Second, that the presence of so many women as sexy hostesses at an industry event sets a climate for women developers working the show that a woman’s “place” at E3 is as an object and not as a developer. There are many blog posts and interviews with women talking about specific ways the tone of E3–largely set by the use of booth babes–made their time working at the show more difficult, more awkward, and much more uncomfortable.

When we talk about these issues, though, the conversation generally dissolves into statements like these, from both men and women:

  • “I like booth babes, personally.”

  • “It doesn’t send a ‘this is for men’ message to me.”

  • “The games are being marketed to men, so it’s appropriate.”

  • “Sex sells, right?”

Or, in other words, “My game is fine and they’re playing it wrong.”

If we want to encourage more women to apply to our companies and work in game development, we need to treat it like a usability problem.

On “playing it wrong.”





さて、記事の日付を確認する習慣があるとして、その習慣は一定の手間を要します。記事のどこに日付が書いてあるかは、記事によって(サイトによって)マチマチです。この手間がもったいないと思います。これは機械にやらせるべき仕事です。ブラウザがウェブページの日付を一定の場所に表示してくれたらラクだと思います。「一定の場所」とは、どんなウェブページを開いても変わらない場所のことですから、ウェブページ表示領域の外側になります。例えばアドレスバーの中に 2014-06-242年前 のような日付表記があると便利かもしれないと思います。


  • 実現するためのアーキテクチャの議論は省略します。HTTPレスポンスのタイムスタンプが正しくない値を示すことが多いために云々。ただ、ブラウザにこのような機能が実装されれば、ウェブ制作者もHTTPレスポンスのタイムスタンプを適切に設定するようになるかもしれません(エコシステムの共進化)。

  • 必ずしも「ブラウザの仕様を変更せよ」という主張ではありません。アドオンのような解決策もありえるでしょう。まだそこまで検討していません。

  • 「アドレスバーの中に日付を入れる」というデザイン案を具体的に検討したわけではありません。まだ初期構想段階です。


2014年11月13日にGoogle Chrome拡張機能 “Oldness” のソースコードをGitHubで公開しました。Wayback Machine APIの有効性を技術的に検証するための試作品です。しばらく使ってみて分かったのですが、Wayback Machineで情報を取得できないウェブページも多いです。


情報建築家 石橋秀仁

How to Become a User Experience Designer

Klint Finley

Susan Farrell wrote a report based on a survey of nearly 1,000 user experience designers, including what they actually do, and their backgrounds and educations. It’s worth a look if you’ve ever thought about a career in usability.

From the summary:

When asked what characterizes good user experience professionals, one of our respondents said, “If you are a ‘lifelong learner’, in other words, if you are paying attention, you will be able to take previous experiences and apply lessons learned from them to your new situation. That is more important to me than specific skills you might learn in school.”

While most knowledge workers probably benefit from being lifelong learners, the point that this is more importantthan a specific education is rare and one of the defining characteristics of the user experience field.

Even though continual on-the-job learning is the most important, 90% of respondents had obtained a university degree. There’s no single degree to define the field: design, psychology, and communication were the most common major areas, sharply pursued by English and computer science. All of these fields make some sense as a partial educational background for UX professionals, but together those five disciplines accounted for only 45% of bachelor’s degrees. The majority of UX professionals hold degrees from an immense range of other disciplines, from history to chemistry, most of which don’t have a direct bearing on UX work.

The most common educational level was a master’s degree: 52% had at least one master’s degree (some had two, which seems like overkill). Only 6% of respondents were PhDs. Most of the remaining respondents with university diplomas held bachelor’s degrees and 1% had associate’s degrees.

Summary: Nielsen Norman Group: User Experience Career Advice.

Or: Download the full report.

Why Autoplay Music is Bad (And Other Issues)

Okay, first I should say this. Your Tumblr blog (or other website) is your Tumblr blog. And while the things below are universally bad practice across the web, nobody can really stop you from doing them. There’s no Internet Police or Accessibility Militia that’s going to come deactivate your website and throw you in prison for doing these things. (Exceptions may apply, some hosting providers may actually have their own Usability Security Forces).

That being said, if you want your blog to be something anyone can enjoy, you should consider the following issues and why they’re a problem.

I’m a Web professional in my day job and as part of that job I’ve made a point to study Web accessibility and apply it in my work to the best of my ability.

Keep reading



Content Objects: My Formula for Information Architecture

When you’re designing a new feature, app, or site, the information architecture can seem overwhelming. This is my technique for thinking about anything you want to design, from scratch. I call it:

Content Objects.

Content Objects are a fairly easy concept, but they can be a little abstract sometimes.

It might sound technical, but there is no code involved… it’s just a technique that helps me simplify complicated designs in my head.

Like card counting, for UX.

After you have decided what your goals are, break down your general plan into the “building blocks” of content that you need.

If this were a Lego® Church of Christ or Kennedy Space Center — and it’s not, because our job will never be that awesome — you’d be making the first page of instructions that shows you the pieces you will need.

We’re not talking about pages or buttons here, baby… I’m talking about conceptual “things” that can be created, shared, edited, and so on.


Let’s look at an example:

Imagine you have been told to redesign Twitter. Big task? Not really. Just deconstruct it into Content Objects:

Twitter has registered users. 

Users make Tweets.

Users can be saved in Lists.

So Users, Tweets, and Lists are the Content Objects.

And that’s pretty much it. Three! Twitter, fundamentally, is built on three Content Objects for typical users. And lists aren’t even a core function (you can use Twitter just fine without them), so it’s actually only two if you just want basic features.


Another example:

An online store. Let’s say it's your store, and you don’t save user data when they buy, and you only sell your own products. You might only have one Content Object: the products!


Ok, one more example:

Pinterest. A super-popular site with tons of content. But it is really simple from the point of view of Content Objects.

Registered users.





ProTip: Every time you add a Content Object, you significantly increase the complexity of your design, so keep it very, very simple.


Now at this stage, you might be thinking “Joel, this is stupid. Those sites can do way more than that!” You’re absolutely right, and I am glad we’re on a first-name basis. But I haven’t explained the second half of this technique, so hold your horses, muchacho.


Relationships, Types & Actions:

You should have very few Content Objects when you’re done. You need as many as you need, but if you have more than 3 or 4, your idea is getting complicated. Facebook only has about 6 or 7 Content Objects for normal users and Pages, just to give you a reference.

Once you have your Objects, you need to look at how they are related to each other.

Relationships create Types: Look at every combination of the Content Objects on your list and ask yourself what relationships could or should exist between individual Objects (a group of Content Objects is often a Content Object of its own).

For example, what relationship can a User have with another User on Twitter? They can follow. They can be followed. And that’s basically it. So there are three types of users: 1) people who follow a user, 2) people the user follows, and 3) everybody else.

A User and a Tweet is a little more interesting. It could be yours. It could be someone else’s. It could be someone else’s that you shared. It could mention you. It could be an old white man with a young Asian girl as his profile pic who is suddenly complimenting you for no reason and sending you links to his personal site.

Those are all Types of tweets. Can you think of more?

Types create Actions: Some types might exist by default, but usually somebody has to do something to create or change the type of a Content Object. For example, I don’t follow anyone by default, so in order to follow someone, I have to do something. Obviously, I have to click the “follow” button.

Following is an action.

My tweets have different actions (reply, favorite, retweet, etc.) than everyone’s else’s tweets because they are different types of the Tweet Content Object.

For each type, ask yourself how that type happens. Then design a good way to do that action or work with that type (depending on what it is).


This Content Object technique packages a lot of complex information into relatively few boxes. 

And those boxes are pretty easy to talk about in a meeting, so it’s useful for more than just you.

It let’s you ask yourself stuff like:

  • Where do I go in the app to find this Content Object?
  • How is this relationship between Content Objects useful?
  • Do users need this Type? How could they use it?
  • What are the priorities of these actions?

And since types and actions are related to a specific Content Object, you will never be confused about which features are needed in which places. They are naturally in “sets” that go together.

And that’s it!

Work through this little step-by-step guide, and you will have planned the information architecture for any app/site, large or small: 

Step 1) What are the main Content Objects?

Step 2) What Relationships can they have with each other?

Step 3) What Types do those relationships create?

Step 4) What Actions do I need to create or work with those types?


If this all seems a bit difficult, let me know on Twitter!

For Your Reading & Viewing Pleasure

11 African American Inventors Changed the World - mental floss

How Libraries Save Lives - brainpickings (Includes video)

How a Pop-Up Book Works - Gizmodo (Includes video)

If You Think Libraries Are Redundant, Read This - Zócalo Square

Mapping the Imaginary - Library of Congress Blog

Studies in the News – a weekly compilation of policy-tested articles and reports produced by the California Research Bureau

Usability and Desirability| The User Experience - Library Journal


Code for Kanazawaが開発した5374.jpというウェブアプリケーションを見たところ、非常に「もったいない」設計でしたので、改善のアイデアを出しておきます。






アプリの動線設計 を開くと、下図の画面になります:


アクセシビリティ のHTMLソースには価値あるコンテンツが書かれていません。





情報建築家 石橋秀仁