An Introduction to Developing a Better Web Based User Experience

Presented at SLA 2015

Understanding the user experience on the Web and for mobile apps requires special skills and methodologies. This introductory session taught how to take your information professional skill set one step further, and learn how you can contribute to effective and intuitive user interfaces.

Deck

Resources

Transcript

So, years ago, as I was finishing library school and had no idea what I was going to do with myself, I applied for a fairly prestigious library fellowship with a government organization. I didn’t really expect to get it, but you know, you apply for things. I sent off my application in January, or whenever you do things like that, and while it was off getting reviewed, through a total fluke, I got the chance to start working in UX. All of a sudden, I was working, in a very minor way, on these big enterprise projects and learning an enormous amount. But I was just freelancing and the work was spotty, so when I was asked to go interview for that library fellowship, I leapt at the chance.

It was exciting, I’d never been flown anywhere for a job before, (it has since become much less glamorous), and it ended up being this crazy full-day long thing, which culminated with about nine different people interviewing me at once, taking turns going around and asking questions. Hilariously, the one that really stumped me was when they asked what my hobbies were. I swear I have them, but my mind went absolutely blank. There was one question, though, that I have thought about a lot since. One of the interviewers asked how I would approach designing an outreach program for a certain kind of population. Now, that I was prepared to answer, so I was just off, talking about the user research I would do, the techniques I’d use, you know, all the stuff I’d learned working in UX for the whole three months or whatever I’d been doing it.

And I realized after a minute, that all nine of those people were looking at me totally blankly, until I sort of trailed off and finished with, “And, of course, I’d do a needs assessment.” And then they all nodded and smiled and wrote notes down. I think about that a lot, because none of the ideas or skills I was talking about were really foreign to the people in that room, they were experts, it was just a difference in vocabulary.

I think librarianship and UX are divided by vocabulary and language, and often needlessly so. Even though I haven’t had to do it in a while, we’re going to do some translating today.

“An introduction to developing a better web-based user experience”

You know, I inherited this title, and when I first saw it, I didn’t think anything of it, it seemed like exactly what I should be talking about. But the more I thought about it, the more I think that it actually highlights a lot of what makes doing this work hard, and especially hard to start.

Better – How do you know what better is? That’s way harder than we make it sound, and it doesn’t stay the same across contexts.

Web-based – The interface is sometimes the problem. But it’s rarely the cause of its own problem, and it almost always needs to be part of a larger design process.

User Experience – This almost makes it through without my having attitude about it, but I think there’s a subtle but important distinction to be made here. Your site doesn’t have a user experience. Your users are having experiences that you, your site, catalog, app, whatever, may be part of. But you’re just one small part of their lives. Figuring out that life, those priorities, the concerns and agendas so you can get them content on their terms, that’s how you get them.

Sometimes, I swear half my job is going into companies and telling executives that no one cares about their org structure, or mission statement, or whatever they think is most important about them. A person’s experience with you goes far beyond your website and your content. So maybe you’re not going to get exactly what it says on the tin, but I think we can get back to some first principles.

You and me: Some assumptions

I’m making some assumptions about you in this talk, besides the fact that you’re probably new to this world, since you came to an intro talk.

  • None of my suggestions will be to hire a bunch of expensive consultants. I’m really glad that people do choose to do that, it’s job security for me, but I promise not to suggest it. I’m assuming that you’re more or less using the tools and resources you have.
  • You need some lightweight ideas and techniques that you can integrate into the work you’re already doing, or that is happening around you
  • You don’t identify as a designer, this is just one of the many things that you do. People find drawing oddly intimidating.

The reason why you are the perfect audience for this, though, is that it’s not just that you need to be better versed in UX and IA, it’s that those disciplines need you.

I can’t tell you how many times I’ve been in a meeting where somebody describes the user behavior they’ve been observing, and I get to say, “Oh, berrypicking,” or “Oh, Granovetter’s strength of weak ties,” and it is relatively unusual that anybody else knows what I’m talking about, unless there’s somebody else with library training in the room. That kind of collective memory, that awareness that patterns of user behavior are older, deeper, and more pervasive than a single website, a single experience, are really vital to designing good experiences, and something the field is lacking.

Whether you’re integrating these ideas into your usual work, your being asked to participate in a larger design effort, or some other context, hold on to that rationale, that warrant, that right to be involved and make these ideas and vocabulary your own. You’re needed.

Definitions & Expectations

At its most basic, I think there’s not much of a difference between IA and UX, you could argue that one is a subset of the other, with Taxonomy here. And that’s fine. Turf wars have been fought over these kinds of things for forever. UX, according to the Nielsen-Norman group, “encompasses all aspects of the end-user’s interaction with the company, its services, and its products.”

IA, according to a Wikipedia definition I actually like, is the “art and science of organizing and labeling” in digital environments. I would caveat that it doesn’t have to be digital, but organizing and labeling is what it’s about.

Taxonomy, which we’re probably all more familiar with, is the practice and theory of classification. This isn’t capital-T truth, it’s just one way of looking at it, but find me later if you want to argue, that’s the best part of conferences like this. Really, I think the best thing that more attention to a “better web-based user experience” can give us is a set of tools to think about how to know what to do, how to do it, and, finally, how to talk about it. We’ll also do an exercise, so there will be worksheets coming around as I’m talking.

What we’ll learn today

I’m going to cover a lot, very quickly, and probably not in the depth that you deserve. What I really want to do here is give you some vocabulary, an idea of the kinds of techniques and activities you can do, and a vision going forward. There’s a very comprehensive handout that you can download, as well as the slides, with everything I’m going to say and all the references.

Keeping my promise to spend most of my time pointing you to the best resources I know of, here are a couple of great introductions to UX and IA. If you leave now, please just remember these two.

How to figure out what to do

What would a “good” experience be? What makes something better in your context? What’s worth prioritizing? These are incredibly difficult questions that we’re not going to answer here, but we can start a bit.

Heuristic Evaluations

“A heuristic is just a fancy word for a measurement of something that can’t readily be quantified.” – Smashing Magazine

The best beginner’s tool, I think, is the heuristic evaluation. Basically what that means is you find some guidelines or ideas around and then see if your site, app, or whatever follows them. There are tons of different sets of heuristics around, and I want you to feel empowered to look at them critically. Mix and match for what you think you need, the questions you can answer, and what your organization values.

One of the great pieces on this isn’t explicitly about heuristic evaluations, but it is a great start for evaluating how you’re doing.  Dan does a great job of distilling a lot of really complex ideas about how information should be structured into 8 principles.

Dan Brown’s “8 Principles of Information Architecture.”

  1. The principle of objects – Treat content as a living, breathing thing, with a lifecycle, behaviors and attributes.
  2. The principle of choices – Create pages that offer meaningful choices to users, keeping the range of choices available focused on a particular task.
  3. The principle of disclosure – Show only enough information to help people understand what kinds of information they’ll find as they dig deeper.
  4. The principle of exemplars – Describe the contents of categories by showing examples of the
  5. The principle of front doors – Assume at least half of the website’s visitors will come through some page other than the home page.
  6. The principle of multiple classification – Offer users several different classification schemes to browse the site’s content.
  7. The principle of focused navigation – Don’t mix apples and oranges in your navigation scheme.
  8. The principle of growth – Assume the content you have today is a small fraction of the content you will have tomorrow.

My worksheet for a heuristic analysis. 

This kind of thing is easy, and it does tend to make a website better. There are lots of lists of these, and this is the worksheet that I use when we do heuristic evaluations, which I’m very happy to share with you. It’s a good place to start, because there are a few objective standards.

Other resources:

Some of them are trickier than others, though, and that’s not an accident. It helps you ask the questions you need to ask.

“Links should be differentiated from other interactive functions.” Ok, this just means that you want a link that opens a new page to look somehow different than a link that just performs an action but keeps the user on the same page. Those are subtly different actions, but being taken to a new page when you don’t expect to is pretty disorienting. It’s not especially hard to figure out whether it’s happening or not, though. You can go through your site and take screenshots of the various interactive elements and evaluate whether or not different actions are being coded appropriately.

Some of them, though, are harder, and bit more about making you think. “The system resembles the user’s real world.” How do you effectively make your site, app, or whatever resemble the user’s world? Do you know what the user’s world is? Maybe you do, but maybe it opens up more questions about what that world is, and what it should be like.

Even the most objective standards about a “good” experience, I find, start to get a little slippery once you start engaging with them. “There are a reasonable number of links on a page.” What’s reasonable? It changes. This worksheet deliberately doesn’t give you a number. You need to put yourself in your user’s shoes and decide what reasonable is.

Research

I think lots of people in my position would tell you to do research first, no matter what. Doing user research is the #1 priority in all cases. That isn’t wrong. I think you want to have some context when you get to it, though, and a set of goals, especially when you haven’t yet developed your researcher’s instincts. Combined with something like a heuristic evaluation, though, it can be powerful.

Indi Young’s Mental Models. This book is very in-depth, but very good, and gives you instructions on how to do every step of research, analysis, and modeling for this kind of work, where you’re trying to figure out how your users think and what they need.

Guidelines for Primary Research

1. You can get great information from four people.

You don’t need to talk to many people. Four people, for an hour each, is absolutely great. You can do eight, if you want, You can do a few from different positions or areas in your organization. But you’ll be amazed at how much useful information you’ll get from just a few people.

2. It’s a lot like a reference interview.

User research is a lot like a reference interview, except you have to keep yourself from being helpful. It’s actually a thing you’re trained for, whether you know it or not. Ask them what their difficulties are, what makes their day worse, what’s the last thing they tried to do and couldn’t, and avoid the temptation to show them how they could have managed it. That’s training, not design.

3. Always identify research objectives.

Make sure you have research objectives, even if you record them informally. What do you actually want to find out? This is where a previous heuristic evaluation can be incredibly useful. Maybe you know your site doesn’t reflect the user’s real world, but you don’t know what that would look like. You can do user interviews where you ask your users to show you their manila folders, their OneNotes, or Outlook folders, or however they store their information organically. That’s a different research objective than, say, finding out more about how your users are trying to use your site in their everyday lives. You ask different questions and try to look at different things.

4. Listen for problems, ignore their solutions.

Listen for their problems, but ignore the solutions they propose. They’re not the expert in how information is put together, you are. Take their problems very seriously, even if they’re doing things wrong. Listen nicely when they tell you how to fix it, but don’t do what they say, they’re solving their tiny problem, and you are working at a much higher level.

Taking it further: Decide what “good” really means

I had an entire section on this, but it was basically just recapping Dan Klyn’s really, truly, excellent talk on determining what “good” is via performance continuums. It presents a really lightweight technique to figure out what a “good” experience would be for your organization, based on what your values are. (Slides for Dan’s talk on Performance Continuums are here.)

This is a thing we have to do in library environments all the time. Back in the day, when I worked in a radiology library, one of the things we dealt with was how tailored to radiologists we wanted to be. Was our goal more to present things in the way most tailored to what we knew about radiologists, or to teach them strategies that would work in any medical library? There’s no wrong answer, but deciding on which was more important to us meant that we did everything from how we organized the books on the shelves to how we presented information on the website differently.

How to do it

Translate ideas into plans

If you’ve been doing all this work, you’re probably going to have come up with lots of changes that would be valuable, things people need, and improvements you’ve identified. I’m here to tell you: You absolutely don’t have to be drawing, prototyping, or coding in order to be doing good design. Stay in words for as long as you can, most of us are good with those, and it can be helpful when interacting with business people, programmers, or even other designers.

Page Description Diagrams are one great way to do that. More on PDDs from UX Magazine.

An anecdote: In one enterprise portal project I worked on, we had done a bunch of research and we knew, very clearly, that our users needed to be able to find information by state. That was how they thought about the content, it added meaning as they navigated, and the content was already tagged that way. If you think about design too quickly, though, it’s easy to get caught up by false constraints. In this case, a few people in the room started saying that state might not be the right thing to navigate by, because there are just too many of them, and putting fifty things in a dropdown for navigation is just awful.

And, you know, that’s not wrong. If you want one hard and fast rule from me today, it could be “Don’t you dare put fifty items in a top nav menu,” and they didn’t want to do that, so they started playing around with the idea of region, so the user could navigate first by region and then by state.

The problem was, they didn’t need to navigate by region. That wasn’t a useful concept for them. State was. But we’d forgotten that State was the priority because we were thinking too much about the mechanism, and assuming it was a dropdown. There are plenty of other ways to navigate. We ended up going with a clickable map. It’s not fancy or sexy, or particularly automated, but it was easy for them to use, it facilitated body memory, didn’t take up too much space, and was almost zero work to code.

Working through this stuff in a page description diagram keeps you from getting off track and compromising what you know you need to do when you’re not sure how to do it. All by itself, an exercise like this actually gives you a little template for iteration.

  • What do we have? (Testing and evaluation)
  • What do we need? (Research and Design thinking)
  • How should we do it? (Planning and specification)

As simple as this is, you can give it to a developer or a designer, or even use it to start thinking about making your own changes to your website, app, or whatever interface you’re responsible for. It becomes much easier to make design decisions when you really know what your priorities are. What goes at the top? What should get cut from the page? Those are decisions you can make more easily now.

Taking it further: Plan how to get there

Improving things means change. Think about how you’re going to manage that change, beyond the interface. Who are you going to roll it out to first? How are you going to get people to use it? Do you make a bunch of changes at once, or do them incrementally?

There’s a lot of writing out there about this, but most of it is about organizational change, which is fine, but not all we’re talking about. My favorite resource for this is Switch by Chip & Dan Heath.

The tendency in UX is to just add a feature or refresh the look and feel of a website, and assume that if it’s better, people will like it and use it. An interface change isn’t always the answer, and even if it is, it will probably need to be supported by other efforts.

How to talk about it

Start here: Talk to anyone who will play along. Talking is much more important than you might think, there are entire books about it, and I’ve given multiple talks on it, which is rather meta. The best advice I have is to talk early and often, with everyone who will participate, no matter their familiarity with design or their position in your organization. This kind of socialization is its own evangelism, and a really good way to get people on board with your plans and vision. It’s also a great way to quickly stress test your ideas by exposing them to lots of different questions and examples. This talking can take many forms, it can be informally, just sharing what you’re up to, it can be formal presentations of deliverables, if that’s useful in your industry, or it can even be through testing.

Testing has its own, other, extremely valid reasons to be an important part of your process. It validates what you do, it provides benchmarks, and metrics. For our purposes here, though, it also gives you a framework to use to talk to your users and stakeholders about what is happening and why.

There are tons of ways to test your work, all of which I’m not going to go into here, but there are some very good resources that do roundups of the various things you can look into:

The primary piece of advice I have about testing is a lot like my advice about research. Don’t underestimate the power and usefulness of thoughtful conversations with a small number of participants. Whenever possible, do some qualitative research, where you moderate your tests, ask people what they’re thinking, why they made the choices they made, and what questions they have. Otherwise you get card sorts where people put things into “Stuff I use” and “Stuff I don’t use” piles.

Once again: Resist the temptation to be helpful. If they have trouble with something or don’t understand it, it’s not a chance to explain, it’s a finding.

Bonus resource: Getting to Yes by Roger Fisher & William Ury. My favorite book on negotiation, whether you’re arguing with your SO or getting to peace in Gaza. 

Taking it further: Look for stories, not just data

Expand into looking for stories. Stories are powerful, easy to remember, and good to test your ideas and plans against. One of the most useful techniques I learned in when I first started consulting was to use our first days with the client to look for a story that really encapsulated the problem we were there to fix. People often don’t offer these up right away, but you’ll develop a sense for recognizing them, and they’ll get you further than any number of appeals to best practices will.

In one enterprise portal project I worked on, I was doing user interviews when the participant mentioned that it took 18 months for a new employee to get up to speed. That seemed like a lot to me, so I asked whether that was time to learn all the procedures and regulations they had, or whether it was something else. “Oh no,” she told me, “That only takes six weeks or so. It just takes so long to build up your personal library of resources.” Documents on the portal they had were so hard to find, that everybody saved each thing they found, and it took over a year to build up a good enough collection. All of that was theoretically accessible, just had terrible IA.

In an e-commerce project I worked on, we actually gave them the embarrassing story. They knew they needed to standardize product information across their various channels, but they didn’t realize just how much of a problem it was until we showed them that the same product had completely different product names in the mailers, the catalog, the website, the in-store signage, and the actual product packaging. Grown men blushed in that meeting.

These stories are ones that people remember. Look for them in your work.

In conclusion

I’ve given you a lot of information here, and I apologize if it was too much crammed into too small a time, but I couldn’t help myself. I really see this as an opportunity for me, not to bring UX and IA to the library world, but to bring all of you to UX and IA a bit, I want more people with your sense of history, your theoretical rigor, and your ability to look beyond the website to bring your perspectives to the conversation about the field. It needs it, and you.