A Brief Note on Analysis

I’ve written before about how the deliverable isn’t the work (although it is work) – getting to understanding is the work. So context is essential as we work through analysis.

So, uh. How do we do that?

For me getting there starts with inputs. What are all the things we need to take into account? Stakeholder thoughts, goals, feelings… sure. Our own lived experiences and professional experiences. Research on customers. Capabilities of the team we’re working with. The broader market and economy and trends. Analytics on site flows, click paths, and performance. Known, existing research on interactions and designs and flows and behaviors. We need to pull all of this together, as a team. That's a first step.

Critically, it is not the last step.

For example, “80% of people from March through May dropped off on this page” is not information – it is data. What makes this interesting? Is this number good? Is it bad? Who the hell knows? Sharing this directly, as is, in any kind of a final context is – from my perspective – incomplete. It is the job of the team to not only absorb this type of input but, critically, state what it means and provide enough detail for someone to take action on it.

That’s where the analysis comes in – inputs and context are essential to doing quality work. Chasing down “why” is foundational to understanding, and when conducting analysis, it’s something I implore my colleagues and teams to do.

In brief, I view analysis as taking data and turning it into usable information.

What a DAM Mess

“Hey, Paul, you and your team know information architecture. Ever work with Adobe Assets?”

That’s how it started, humbly and simply, with a question from a business development lead at my agency. He had been working on a few deals that included Adobe Assets, one of the popular Digital Asset Managers – or DAMs – out in the market. I answered to that colleague, simply, “Not yet, but I’ll look into it.”

Digital Asset Management – also DAM – holds the promise of centralizing all of an organization’s assets… things such as images, content, PDFs, working files, and so forth. It was something that I had a basic familiarity with at the time, but once I learned more, I recognized how powerful a centralized set of assets would be for just about any organization.

While standalone DAMs exist, integration with a broader Content Management System (CMS) or Digital Experience Platform (DXP) is where the real power comes into play. An example of that promise is: I can have an asset that is on a content maintenance cycle, well-tagged, in a folder and place that makes sense in a DAM… that can then be associated with a particular component or template in a CMS… that can be measured for performance in a test-and-learn personalization program, and adjusted accordingly. It’s the end-to-end “Hey, how is this doing?” question that any marketer worth their salt has.

Many DAMs offer significant integration points beyond that (extending this into broader organization workflow management, and existing creative tools) but that’s the gist of it. Organize your stuff, maintain it, and you’re setting yourself up for a bright future of serving up totally personalized experiences to customers on their phones, tablets, computers, watches… you name it.

Well. Maybe.

Where do we put our DAM stuff?

I started working with my team to understand how information architecture (IA) could or should play a role in the DAM work we were selling.

The start of untangling any mess – as information architecture (IA) expert Abby Covert might suggest – is understanding what you’ve got. An inventory and audit, addressing both qualitative and quantitative aspects of content, is the start of so so much work. And in working with DAMs, by delightful coincidence, starting with an inventory and audit makes a ton of sense.

This is where organizations start to get wide-eyed and realize how much of a challenge moving to a new DAM (or simply organizing their assets) can be. When I worked with a large-scale retailer several years ago, we opened a discovery by talking about where they stored their assets today. Great news: they had a shared creative server, internally!

But the creative team also regularly dropped things on their local computers – desktops were full of icons. They also had another shared server for some production assets. And a SharePoint instance where some things lived. And they also used Box for a few things. One marketing team had a totally different process. Yet another department had designed a full lifecycle process built around catalog production that worked well for them, but isolated all of their work from everyone else.

Inefficient? Don’t be so sure. These teams all still produced displays, catalogs, digital ads, 4 websites in 2 languages, and more on a seasonal basis. That’s not trivial work and they got it done, every time.

But they recognized that having a centralized library of all of their work could lead to efficiencies, both in organization and processes around content and asset production. Did they need to have an asset from a photo shoot in 24 different places? No. Did they need to manually create contact sheets in PDFs for approval by creative directors? Also no. Did they need to manually create variations of an asset for display ads, the website, and the mobile website? No!

This is all to say that the way most organizations handle assets today is likely very, very inefficient from a broader enterprise perspective, even when everything happens on deadline and on time.

Enter the IA

That brings me back to the question posed by my colleague. Organizing a DAM is all about figuring out where to put things, how to name things, how to not name things, how to account for modalities, how to support various users’ needs, and almost everything else in a space I typically define as information architecture.

What I’d seen anecdotally at that agency and elsewhere was that developers would handle everything about assets because it was seen as a development task. And while developers absolutely incorporated a degree of IA in their work, it was usually the “best practices” that had been used elsewhere. Anything else around deeply investigating relationships between these pieces of information was left to the client. It felt like a real opportunity.

This isn’t where I’ll say an IA came in and was a superhero and resolved it all. But it’s important to note that with a dedicated information architect involved in the process early on, the shape of the work got a little different.

We started to apply information architecture principles and heuristics to DAMs. In the work my team does now, once we complete the audit, we review it fully with the client in a workshop setting. We talk through how things are organized, any peculiarities, and definitely add in a lot of “nice job on this!” too.

From there we start to analyze their organizational structure and workflows to inform the folder structure. In my experience a DAM is one place where an organization’s structure internally (teams, departments) can make sense for where to put things. But even talking through and reviewing how work gets done in a collaborative, workshop setting is essential.

And while workflows lead into a richer, more governance-related bent of this work, I’ve found that many organizations haven’t taken the time to simply write down, step-by-step, how they do things. These aren’t small companies, either. These are monsters. Big ones. And them seeing things like, “Oh, wow, this gets approvals from 8 people in email” and “Huh, this department puts their stuff here but it really should be there, maybe” is revelatory.

And yes, the development team is naturally involved in this work. They're getting a front row seat to the blueprint for a migration and setup of a DAM.

Ultimately we deliver a full set of recommendations on folder structure, taxonomy, tags, metadata, and naming conventions. We typically include workflow analysis and recommendations too. This culminates in a framework for these teams to take and run with as they look to reorganize, migrate, and implement a new organizational system. Not small work, but important work.

The DAM of the DAM

There’s a slight cautionary tone in my words here, because one other risk I typically see is assigning ownership of the DAM to an already-busy marketing team, an IT team, or a creative team.

I’m not here to tell you if you should reorganize your team but I will say: you absolutely, positively, 100% need to make it someone’s job to be the Digital Asset Manager (DAM) of the DAM. They may be an Asset Librarian, a DesignOps expert, an Information Architect, whatever. Critically that person needs to have knowledge in information architecture. They may “live” in an IT team or marketing team, but having knowledge – at least from a business perspective – of the particular DAM being used is immensely helpful.

The cover of Murmur. DAM kudzu.

When I’ve worked with clients who have internal DAM owners, things are different. The discussion becomes more about how they can scale and grow a system for a team, and how they can enforce standards. The discussion includes not just the immediate work but what’s around the corner: governance, ownership, and maintenance, critical parts of digital work.

Without DAM owners? Well, you know the cover of R.E.M.’s 1983 Murmur, right? The kudzu? That’s what happens to the DAM. One department organizes things one way, another doesn’t tag anything, and soon you’re back in the same place you started. Not having a person in charge of DAM governance is a pretty bad idea.

Change is DAM Hard

Centralizing your assets is all about change. The way things worked may stay the same, but how things are set up is going to be new. And change is hard. I’m starting to say this more and more: all of this will lead to people being pissed off, upset, or discouraged.

Some people get very attached to their way of working and don’t want to change it. This isn’t something that shows up on a DAM feature scorecard, but you have to honestly and openly evaluate how ready your team is to change. It is absolutely a factor in moving to a different DAM, or any DAM, and absolutely should be considered. I’ve joked that workshops are like therapy but, sometimes, they end up leaning hard in that direction for just this reason. Don’t forget the emotional work, either.

IA is Essential

That simple question that came my way years ago led to a lot of good work with people and teams to figure out how they should better organize their stuff. So when you’re evaluating your DAM – either a current one or shopping for a new one – do not overlook the importance of information architecture. It’s DAM important.

Affordances are dead

I miss affordances.

Affordances in computing UIs… are nothing new! When we put words on a screen, we collectively needed to visually convey what one could do with those words. Menus? Buttons? Dropdowns? All of the fundamental UI elements we’ve had for 30+ years started with deliberate design decisions – good or bad – that became standards, or de facto standards.

And as the web and touch interfaces have matured, designers have collectively thrown them out the window. I blame removing underlines on links.

Let me explain, without getting nostalgic.

In the old days of the web, links were underlined and in blue (versus black and no underline for text). It was the standard. Over time, the ability to remove underlines was introduced – so links could be any color and not have an underline. But… how does one convey it’s a link? Some links sprouted icons. Some remained in a different color. Some grew on hover, or showed a background on hover, or did something only when tinkered with.

Even there, the ability to scan a digital thing and convey intent was lost.

But, as with changes, people adapted. We started to click and poke at more things on pages, even things that looked as ordinary as anything else, in the hopes – the hopes – that maybe this thing would make a page or an app do the thing we wanted it to do.

Touch interfaces escalated this change. When using a touch interface, more than ever, the only way to know what one can interact with is through experience. It is less and less conveyed by the UI itself. Thus, it’s shifting the mental burden of figuring out “how do I work this” to the user – fully. Now, it may not be a significant burden! But, a burden nonetheless. The UI no longer says, “This is clickable” or “This is a thing you can interact with” consistently. Sometimes yes, sometimes no. I’ll note: we’ve collectively gotten used to this.

Big Unsure

Like any UI snob, this came home to roost for me when I upgraded my family Mac to Big Sur, the latest macOS. This version has a UI shift that, when rifling through reviews, seems to be noted as significant but manageable. I disagree. Any change will be tough for people including myself, but the other side of that change appears to be… kinda crappy.

Probably the biggest shift is that everything in the OS is button-esque now. Menus are button-y things that open up boxes below them, without a strong visual attachment. Buttons? Are just icons now with no clear indication that they can be clicked, other than the fact that they’re icons. Look at this screenshot from Safari.

Icons? Or buttons? Who the hell knows? (These are… toolbar buttons in Safari.) [Image description: five icons in a row, with no background or border or indicator, from Safari]

I talk a big game about context. The above is out of context but this area in Safari is accurate. Five icons, in a row. No borders. No indicators of what they do. The colors? I believe they’re from third-party extensions, but who knows? And they’re blue because… Reasons, I guess.

There is a ton of guessing one needs to make to understand this. The only thing that helps is prior experience with Safari. There is almost nothing here, plainly, that indicates these are buttons. Who’s to stop a developer from just… putting icons there? That aren’t clickable? And just provide information? Right.

This is just one example, but it’s emblematic of Apple’s continued decision (that kicked off with iOS 7 and Jony Ive’s takeover of the OS… which I also liked at the time) to prioritize visual cleanness over usability.

A menu in Big Sur. Everything is just rounded rectangle buttons now. [Image description: a screen shot of the Finder menu in Big Sur, showing ‘About Finder’ selected with a blue rounded rectangle around it.]

Everything is Button, Button is Everything

Here’s a menu from Big Sur, from Finder specifically. Aesthetically? Not terribly different from prior macOS versions. But the button-itis of macOS extends here too: all of these text items are just buttons. The panel itself? Also looks like a big button now. Even the hover in the menu bar… makes it a button. Seriously, Apple, you get rid of buttons on devices and put them all on screen? Is that the deal?

Anyway. Why would you need to buttonize a menu? If you wanted to transplant an iOS interface into a menu, basically – and that’s what Control Center is. A UI train wreck.

Control Center suffers from a crappy visual hierarchy and a design for touch interface that doesn’t translate cleanly to a mouse-based interface. Here, have a look.

Control Center in macOS Big Sur. Someone approved this. [Image description: a screenshot of Control Center in Big Sur, showing multiple rounded rectangle items and controls.]

Since day one, Control Center – even on iOS – has been problematic. The great news is that now those problems are on macOS. This makes sense if one has limited space to convey information – then it becomes a real design challenge. But take a moment and look at this. Not everything can be interacted with in the same way. All of these controls, when hovered or clicked on, act differently. So they look somewhat consistent but don’t act that way. How do they work? What do they do? No one knows until they’re clicked on. Some morph into menus. Some are visual panels.

Again, here, the lack of clear affordances means this is a hodgepodge of controls that – honestly? – would be better served by a menu! Nice one, Apple, nice one.

Beyond that? The redesigned dock icons and app icons… are also buttons. No joke. Those shapes you memorized and used to differentiate apps are gone now, with everything surrounded by a rounded rectangle.

The future is dimmer

This is a rant, no doubt. And OSes change – they have forever. But the push that Apple has put in place with Big Sur is wildly unimaginative and short-sighted. How we use computers and computing devices has changed, of course, in the past 40 years! It’s a big difference. But in Big Sur, Apple’s thrown out so much of the UI standardization it helped usher in to computing. Our interfaces today are making us do more work, more figuring things out, and throwing away consistency and adaptability.

iOS 13: every interaction is heavy

It’s funny, but I’ve been feeling a tiny sense of dread in more of my interactions with my iPhone lately. Upon reflecting on it it boils down to this: every little interaction now has more weight on it.

The best example is contextual menus - evoked with a long press or a press and hold, taking the place of the old 3D touch. The long and short of it is that Apple has driven to consistency with a similar “share sheet” across the OS… but each share sheet takes up more than the height of the screen, is fully customizable, and has a lot of options that make zero sense in context. Like: would I ever want to add a song from Apple Music to Deliveries, the app that tracks UPS/FedEx deliveries for me? Of course not. But I can, because that option is available system-wide.

This makes every interaction I have with Apple Music now carry extra weight. I need to actively search for what’s relevant, and I’m presented with a list of options that simply don’t apply. It’s, in a word, crummy.

What to do with The IA Institute?

So. Here we are. The IA Institute, the only notable professional organization devoted to information architecture, is on the brink of collapse due to a lawsuit. Recently, members were asked if the whole thing should die or what.

I definitely go back and forth on this, but as of this morning I’m more like: let the IAI as it stands, die.

Make something new. (Also not easy.)

If I were in charge – and I am not, please don’t @ me – I would say that any new org has to acknowledge the reality of IA in 2019. Let’s drop the whole “saving the world” act and stop whining about how “UX won”. And, acknowledge that IA remains critically vital to the work of many people – but also acknowledge that as an independent discipline, it’s trending down.

How would an organization, if there were one, pull together those two disparate attitudes? That the work we do is super important but is critically undervalued? Without falling into a malaise of navel gazing?

How can IA be made relatable to the person just starting their career “making screens”? What about the database admin who’s quietly been doing similar work forever? Or the person who does SEO audits for a living? Maybe the problem is that efforts to make IA relatable aren’t working at scale, and ideally there would be an organization pushing that forward.

The new IAI leadership could absolutely take this on. I’m unsure if the current structure truly allows it. (I really don’t know.)

And what if the people doing vital IA work today aren’t IAs, by trade? I would almost wager that’s the case. And they’re out there, thinking that stuff is part and parcel with some other job they do. That’s great. That means, in a small way, IA has “won”.

Critically and finally: are the people who are leading impromptu discussions on Twitter the people who should be leading this charge? Are they the traditional gatekeepers? Are they really people who would be members of an IA organization? Are they the right “users” to design against? And if the answer is no, as my hunch says it is, who are the right users, and why are they not centered in these discussions?

The IA Institute's Letter, in a Parallel Universe

You may have recently read or heard about… things… in the IA community involving how to handle bad actors, amongst about 80 other things. In part due to Lynn Boyden’s open letter, the IA Institute sent its members a letter on next steps. What follows is not that letter. What follows is the letter that the IA Institute, say… in a parallel universe, may have sent.

To the IA Community:

We are grateful for your patience and consideration as we’ve worked through some important and sensitive problems over the past few weeks. We are happy to share an update on our progress with you.

First, let us be clear. There is no place for harassers or abusers at any IA Institute-led event including the IA Conference and World IA Day. We, as an organization, strive for empathy with all people; that’s why it’s more important than ever that we center our actions on the people who have been impacted by events that happened, and not the people perpetuating them.

While we want to talk about the future, we must address the past. We apologize fully for the pain and trauma that victims may have been dealing with as we worked behind the scenes on this important work.

Anyone who has been banned by the IA Conference or its predecessor conference will continue to be banned from all IAI-led events.

Our goal as an organization is to do our very best to ensure all our events are safe and inclusive. By the 2020 IA Conference, we plan to have a complete safety system in place that addresses complaint handling, processes and procedures, a revised code of conduct, and full safety training for our volunteers and board.

Immediately, we are soliciting bids on anonymous reporting systems we can use at our events, and the aforementioned safety training. We expect to make a decision on these important parts of infrastructure by March.

Going forward, our Events Director will provide monthly updates to all IAI members on the progress of each of our initiatives. This includes not only the safety-related strategies above, but also includes our work on improving the diversity and inclusion at our events. We’ll discuss that in more detail soon.

Finally, please remember our overall mission: to promote awareness, provide resources for learning, practicing, and teaching information architecture and to support and expand opportunity for practitioners. We know that none of that can happen without a safe, inclusive environment, and we are making that our top priority from this day on.

Thank you once again for your patience. If you have any questions or comments, please contact any of the board members via our website.

Sincerely,

The IAI Board of Directors

On Paying Conference Speakers

This week’s UX topic carousel is, apparently, “Should conferences pay their speakers?” (The answer is yes, of course, by the way, but I guess that’s being debated.)

Anyway, Patrick Neeman put together an argument about everything that goes into running a conference. The bottom line is: it’s expensive and it’s hard. This, ideally, is no surprise to you, dear reader. Conferences are hard! And conferences are a lot of work. And they’re expensive. All true. I don’t disagree.

What bothers me, amongst other things, is this closing point.

Getting a speaker honorarium is an honor, not a privilege. Unless they are offer money in the initial email, there’s a good chance you’re not getting paid. Most conferences choose their keynotes before they open up for submissions, and just to be even considered is a big deal unless you’re part of the speaker circuit. Some speakers toil for years without getting paid. They spent years building their brand through networking and promotion. Don’t desecrate their hard work.

First up, no. Getting paid at a conference that is charging admission and taking in money, even if it is a small amount, is not an honor. As always, getting paid in exposure doesn’t pay the rent, nor the water bill, nor get food on the table.

But what really got me – what really got me good – was the closing couple lines.

“Some speakers toil for years without getting paid. They spent years building their brand through networking and promotion. Don’t desecrate their hard work.”

In short? That’s really too bad. Those speakers chose to speak for no money. There is no reason for that to continue. There is hard work there, yes. But only speakers with an enormous amount of privilege can afford to do that very thing. This to me read very, very much as a defensive, “Well, they got theirs! Too bad!” argument. It’s ultimately not fair to those speakers either, but they also made the choice to do it for zero dollars. That doesn’t mean up-and-coming folks, or people who want to get fairly paid for this, aren’t entitled to it. (Yes, entitled.) People should get paid for their work. Conference speaking is work.

The problem isn’t that people are asking to be paid. The problem is that the current setup only favors and supports people who can afford not to be paid.

to a new way forward.

It’s time for UX, as a practice and as a community, to let go to the things that are holding us back. It’s time for us to rethink what we want to be and who we want to be. It’s time for us to grow and mature. It’s time for us to welcome people who aren’t cis white males into the community and support them and promote them. It’s time for us to center our work on people of color, queer people, women, disabled people, neurologically diverse people.

It’s time to accept and promote that our work is not neutral, never has been, and never will be. It’s time for us to create accessible designs without excuses about time or money or effort. It’s time for us to be respectful of how people work and help them find new ways without impacting their day to day lives. It’s time for us to actively question and challenge the people we call leaders in our space. It’s time for new people to lead.

It’s time to assume that unchecked technology might not move us forward, not by itself. It’s time to thoroughly examine how the things we create may be used for nefarious, malicious, or outright evil purposes. It’s time to have diverse teams instead of continually talking about it.

It’s time to call out people for being sexist or racist. It’s time to throw out assumptions around designers and developers and product managers and everyone. It’s time to respect everyone’s identities and lift people up. It’s time to reject systemic bias, racism, sizism, homophobia, transphobia, and sexism.

It’s time to stop worrying about the tools we use and start worrying about the systems we create. It’s time. It’s time.

How Not to Ask for Gender During Signup

I admit, it wasn't my best idea. I was lured in by an app called Fishbowl that promised me conversations amongst people at my company and industry. And lured is the correct term, pun notwithstanding: Fishbowl had a painful signup process that required use of my Contacts, Notifications, and needed my birthday. At no point during this was the privacy policy prominent, and most screens had no way out.

Then I got to this screen.

This screen is a textbook lesson in how not to do this. Here is why.

1. I have no idea, as a user, what the app or company will do with this information. Nothing is set here. Is this for demographics? Is this for customizing an experience? Both? Neither? No clue. 
2. It reinforces the gender binary. The most obvious and blatant problem here is that it reinforces that there are two genders, which isn't the case.
3. It reinforces the idea that presentation = identity. There is nothing inherently gender-related shown here. These icons have the same head shape (so, kudos there I guess?); otherwise, they have different haircuts, and are wearing different tops. The male icon also has way broader shoulders, which does reinforce that stereotype.
4. There is no other gender option. It's like going to a building that lacks all gender restrooms: it's not right for people who don't align with these genders.
5. There's no way out. This was required as a part of the flow, as I mentioned, and there was no way to skip it. No way to come back later. At all.
6. The icons reinforce white beauty standards. Abigail Plumb-Larrick correctly pointed out on Twitter that, on top of all of this, the icons align with white beauty standards.

This experience, overall, was intrusive and hostile. Asking for gender and reinforcing a binary on top of that is straight up harmful.

For this app, I chose “female” in part to see what would happen. It may have been coincidental (but... let's be honest here) but some of the communities it recommended to me right away were about weight loss and fashion. So... yeah.

Don't be like Fishbowl. Don't do this.

Things I Wish I Knew When Starting in UX

For context: I started out as a developer who moved to the web, who later moved to focusing on UI code, who later moved into UX. My experience may not be typical, and I do not intend for this list to be a definitive "THIS IS FOR EVERYONE!" thing. Rather, they're things I wish I could have known when I started to make the move away from coding.

• There isn't a defined career path. Extraordinarily few people know how to progress in this field, and companies don't agree on it anyway. There's a ton of "just figure it out" or, to be more precise, "do it yourself".
• Get out from behind the screen. This is who I was. While one doesn't need to be an extrovert, one needs to be able to work with people well. It's a requirement.
• The people who you think are leaders in the field are probably not leaders. They're people with their own biases, flaws, and opinions – and they share their work extensively. A lot of them are leaders because they promote themselves extensively, and that's all. Their work may be fine, but they might not be doing the most interesting or useful work.
• It's easier to change a UI than it is to change a culture. So much UX work ends up falling into the UI bucket because the processes, people, and plans around them are way harder to change. Some people are inherently resistant to change, and some people are lazy. These aren't bad things; rather, they're limitations you need to work with.
• The tools will always be lacking. No one tool does everything well, so stop looking for it.
• Some people debate the same shit over and over (like "is UX real?"), and that doesn't stop. Rise above it. Joke at it, poke at it, but move on. It's a waste of time.
• UX is generally not in a position of power. In part due to the above, it's misunderstood and will continue to be. That's okay. Figure out how to make it work, instead. (That means understanding the business, understanding what IT wants, understanding what people need.)
• Agile is a fucking mess. You know Agile already. Doing UX in Agile can be good, and can definitely work, but in many cases it's purely execution-focused. You instinctively think Agile is wrong for UX. Go with that.
• This isn't art. You can make beautiful things, things that solve problems.
• You won't have to code anymore. I know you're relieved to hear this.
• No one agrees on where UX sits in an organization. They probably won't, ever. So you'll be in IT, you'll be in marketing, you'll be in design.
• The community is filled with good people trying their best. You'll form friendships with many of them. Very few of the people in UX are assholes.
• It's fun. Ultimately, there's something exciting about talking with people, understanding what they're saying, and helping create something that does what they need. That's the good stuff! Don't lose that.