Another Word For It Patrick Durusau on Topic Maps and Semantic Diversity

John E. Karlin, Who Led the Way to All-Digit Dialing, Dies at 94

The New York Time obituary for John E. Karlin, the father of the arrangement of numbers on push button phones and a host of other inventions is deeply moving.

Karlin did not have a series of lucky guesses but researched the capabilities and limitations of people to arrive at product design decisions.

Read the article to learn why one person said Karlin was “…the most hated man in America.”

I first saw this at Human Factors by Ed Lazowska.

4 Reasons Your UX Investment Isn’t Paying Off by Hilary Little.

You can imagine why this caught my eye.

From the post:

“Every dollar spent on UX brings in between $2 and $100 dollars in return.”

We all know the business case for doing user experience work: investing upfront in making products easy to use really pays off. It reduces project risk, cost, and time while improving, efficiency, effectiveness, and end user satisfaction.

(Don’t know the business case? Read this or this. Or this.) But what if you’re investing in UX and not getting results?

There can be many factors behind an under-performing user experience effort. Anything from a lack of tools to the zombie apocalypse can wreak havoc on your teams. Addressing either of those factors are outside my area of expertise.

Here’s where I do know what I’m talking about. First, rule out the obvious: your UX folks are jerks, they don’t communicate well, they don’t understand business, they aren’t team players, they have such terrible body odor people stay 10 feet away …

Next, look at your organization. I’ve based the following list on observations accumulated over my years as a UX professional. These are some common organizational “behavior” patterns that can make even the best UX efforts ineffective.

Let that first line soak in for a bit: “Every dollar spent on UX brings in between $2 and $100 dollars in return.”

Then go read the rest of the post for the four organizational patterns to watch for.

Assuming you have invested in professional UX work at all.

I haven’t and my ability to communicate topic maps to the average user is poorer as a result.

Not that I expect average users to “get” that identifications exist in fabrics of identifiers and any identified subject is at the intersection of multiple fabrics of identifiers, whether represented or not.

But to use and appreciate topic maps, that isn’t necessary.

Any more than I have to understand thermodynamics to drive an automobile.

And yes, yes I am working on an automobile level explanation of why topic maps are important.

Or better yet, simply presenting a new automobile and being real quiet about why it works so well. 😉

Sharpening Your Competitive Edge with UX Research by Rebecca Flavin.

From the post:

It’s part of our daily work. We can’t imagine creating a product or an application without doing it: understanding the user.

Most of the clients we work with at EffectiveUI already have a good understanding of their customers from a market point of view. They know their target demographics and often have an solid sense of psychographics: their customers’ interests, media habits, and lifestyles.

This is all great information that is critical to a company’s success, but what about learning more about a customer than his or her age, gender, interests, and market segment? What about understanding the customer from a UX perspective?

Not all companies take the time to thoroughly understand exactly why, how, when, and where their customers interact with their brand’s, products and digital properties, as well as those of competing products and services. What are the influences, distractions, desires, and emotions that affect users as they try to purchase or engage with your product or interact with your service?

At EffectiveUI, we’ve seen that user research can be a powerful and invaluable tool for aiding strategic business decisions, identifying market opportunities, and ultimately driving better organizational results. When we’re talking to customers about a digital experience, we frequently uncover opportunities for their business as a whole to shift its strategic direction. Sometimes we even find out that the company has completely missed an opportunity with their customers.

As part of the holistic UX process, user research helps us learn more about customers’ pain points, needs, desires, and goals in order to inform digital design or product direction. The methods we generally employ include:

Great post that merits your attention!

What I continue to puzzle over is how to develop user testing for topic map interfaces?

The broad strokes of user testing are fairly well known, but how to implement those for topic map interfaces isn’t clear.

On one hand, a topic map could present its content much as any other web interface.

On the other hand, a topic map could present a “topicmappish” flavor interface.

And there are all the cases in between.

If it doesn’t involve trade secrets, can anyone comment on how they have tested topic map interfaces?

Why you should try UserTesting.com by Pete Warden.

From the post:

If you’re building a website or app you need to be using UserTesting.com, a service that crowd-sources QA. I don’t say that about many services, and I have no connection with the company (a co-worker actually discovered them) but they’ve transformed how we do testing. We used to have to stalk coffee shops and pester friends-of-friends to find people who’d never seen Jetpac before and were willing to spend half an hour of their life being recorded while they checked it out. It meant the whole process took a lot of valuable time, so we’d only do it a few times a month. This made life tough for the engineering team as the app grew more complex. We have unit tests, automated Selenium tests, and QA internally, but because we’re so dependent on data caching and crunching, a lot of things only go wrong when a completely new user first logs into the system.

Another approach to user testing of your website or interface design.

Re-Introducing Page Description Diagrams by Colin Butler and Andrew Wirtanen.

From the post:

There’s no such thing as a “standard” client or project in a typical agency setting, because every business has its own specific goals—not to mention the goals of its users. Because of this, we’re constantly seeking ways to improve our processes and better meet the needs of our clients, regardless of their unique characteristics.

Recently, we discovered the page description diagram (PDD), a method for documenting components without specifying layout. At first, it seemed limited, even simplistic, relative to our needs. But with some consideration, we began to understand the value. We started looking at whether or not PDDs could help us improve our process.

As it turns out, these things have been around for quite a while. Dan Brown devised them way back in 1999 as a way to communicate information architecture to a client in a way that addressed some of his primary issues with wireframes. Those issues were that, looking at wireframes, clients would form expectations prematurely and that designers would be limited in their innovation by a prescribed layout. Brown’s approach was to remove layout entirely, providing priority instead. Each component of a page would be described in terms of the needs it met and how it met those needs, arranged into three priority columns with wireframe-like examples when necessary. …

Because of its UI context, I originally read this post as a means of planning interfaces.

But on reflection, the same questions of “needs to meet” and “how to meet those needs” applies equally to topics, associations and occurrences.

Users should be encouraged to talk through their expectations for what information comes together, in what order and how they will use it.

As opposed to focusing too soon on questions of how a topic map architecture will support those capabilities.

Interesting technical questions but no nearly as interesting, for users at any rate, as their information needs.

The post also cites a great primer on Page Description Diagrams.

Treat Your Users Like Children by Jamal Jackson.

From the post:

Do you have kids of your own? How about young nieces, nephews, or nephews? Do you spend time around your friends’ children? Is there that one neighbor who has youngsters who makes it a point to disturb you any chance they get? If you’ve answered yes to any of these questions, then you understand that caring for kids is difficult! Many people would argue that my use of the word “difficult” is a strong understatement. They’d be right!

Young minds are almost impossible to predict and equally hard to control. A parent, or any other adult, can plan out an assortment of ideal procedures for a kid to follow to accomplish something, but it will likely feel like wasted time. This is because kids have no intention of following any form of procedures, no matter how beneficial to them.

Speaking of people with no intention of following any form of procedures, no matter how beneficial those procedures may be, I can’t help but wonder why dealing with children reminds me of the life of a UX professional.

How many hours have you spent toiling away in front of your monitor and notepad, hoping the end result will be to the user’s benefit? If they even bother to proceed as you predicted, that is. In the end, the majority of users end up navigating your site in a way that leaves head-scratching as the only suitable reaction. This is why web users should be treated like kids.

The post is worth reading if only for the images!

But having said that, it gives good advice on changing your perspective on design, to that of a user.

Designing for ourselves is a lot easier, at least for us.

Unfortunately, that isn’t the same a designing an interface users will find helpful or intuitive.

I “prefer” an interface that most users find intuitive.

An audience/market of < 10 can be pretty lonely, not to mention unprofitable.

Mark Needham in Restricting your own learning, references: Practical Guide to Controlled Experiments on the Web: Listen to Your Customers not to the HiPPO by Ron Kohavi, Randal M. Henne and Dan Sommerfield.

HiPPO = “…the Highest Paid Person’s Opinion (HiPPO).”

Abstract:

The web provides an unprecedented opportunity to evaluate ideas quickly using controlled experiments, also called randomized experiments (single-factor or factorial designs), A/B tests (and their generalizations), split tests, Control/Treatment tests, and parallel flights. Controlled experiments embody the best scientific design for establishing a causal relationship between changes and their influence on user-observable behavior. We provide a practical guide to conducting online experiments, where end-users can help guide the development of features. Our experience indicates that significant learning and return-oninvestment (ROI) are seen when development teams listen to their customers, not to the Highest Paid Person’s Opinion (HiPPO). We provide several examples of controlled experiments with surprising results. We review the important ingredients of running controlled experiments, and discuss their limitations (both technical and organizational). We focus on several areas that are critical to experimentation, including statistical power, sample size, and techniques for variance reduction. We describe common architectures for experimentation systems and analyze their advantages and disadvantages. We evaluate randomization and hashing techniques, which we show are not as simple in practice as is often assumed. Controlled experiments typically generate large amounts of data, which can be analyzed using data mining techniques to gain deeper understanding of the factors influencing the outcome of interest, leading to new hypotheses and creating a virtuous cycle of improvements. Organizations that embrace controlled experiments with clear evaluation criteria can evolve their systems with automated optimizations and real-time analyses. Based on our extensive practical experience with multiple systems and organizations, we share key lessons that will help practitioners in running trustworthy controlled experiments.

Not recent (2007) but a real delight and as relevant today as when it was published.

The ACM Digital Library reports 37 citing publications.

Definitely worth a close read and consideration as you design your next topic map interface.

Dueling and Design : How fencing and UX are quite alike by Ben Self.

From the post:

The other day I was leaving the office and mentally switching gears from the design work I had been doing all day to the fencing class I was about to teach that night. During my commute, I thought to myself, “It’s time to stop thinking like the end user and start thinking like a fencer.”

Suddenly realizing the similarities between my job and my hobby, I found myself pondering the connections between fencing and UX Design further over the next few weeks. I discovered more parallels than I had expected, although the first thought I had was that the goals are almost completely opposite.

When I am fencing, I want to frustrate my opponent and keep him from accomplishing his goals. When I am designing an interface, I want to encourage the user and help them accomplish their goals. It occurred to me, however, that while the final results are polar opposites, many of the methods used for assessing how best to achieve those opposite ends are actually very similar.

All these years I thought interfaces were designed to prevent me from accomplishing my goals. An even closer parallel to fencing. 😉

Ben does an excellent job of drawing parallels but I am particularly fond of his suggestion that you know your opponent/users. It’s hard work, which is probably why you don’t see it very often in practice.

What other activity do you have that illustrates principles for an interface, communication with others, or other semantic type activities?