Winter always inspires a lot of work-related reading and reflection from me. Perhaps it’s the association of cold and darkness with school and long nights in the library.

This winter I’ve been reading mostly about mobile UX, responsive design and content strategy. I’ve also been doing a lot of walking with our new dog. Which has meant a lot of listening to podcasts — at least half of them interviews by Jared Spool, the master of spotting UX talent and trends.

With all of this stuff going into my head, I thought it’d be helpful to capture my biggest takeaways on paper and have some things to focus on for the rest of 2014.

I ended up with 6 UX priorities. Before I get to those, here are 2 themes that run throughout …

Mobile is a catalyst

Creating a great user experience is hard work. It’s especially hard for sites bloated with fluff content and useless features.

The good news is that mobile has the attention of executives, many of whom realize that it will take some fundamental restructuring to do it right. So while a lot of problems on the list below aren’t specific to mobile, mobile is often the best way to position the solution.

Responsive is not enough

Responsive design is a great approach for helping your site work well on mobile. But strictly defined, it’s just a set of techniques — fluid grids, fluid images and media queries. If your site has big UX or workflow problems, you can’t wave the responsive wand and make them go away.

Yes, mobile can be a catalyst to fix those problems. And if it helps sell things internally to frame these changes as part of “the responsive project,” go for it. But the people actually leading the work need to realize that fundamental decisions need to happen before responsive is implemented. Otherwise those decisions are unfairly left to developers.

Now onto the 6 priorities …

1. Content first (or, stop content last)

Anyone who’s watched a web usability test knows that the words on the screen are critical to a user’s experience. As screens get smaller, the importance of each word on that screen grows.

Yet when starting on a new project, most companies and agencies treat content — headlines, paragraphs, calls to action, microcopy and the strategy around them — as an afterthought.

We’ve made this mistake plenty of times. Visual design and technology get all our attention and go through many discussions and iterations — and maybe some user testing — all with “text goes here” placeholders.

By the time we have writers go to work, it’s too late to change the design even if their content would work better with a different IA, layout, flow or visual design — which we realize is often the case once we watch real users interact with real words.

The fix: Involve a content strategist at the start of all projects. Identify the core messages and content elements before you start designing. And get your writers talking to your designers throughout the process. Usability test wireframes and prototypes with representative content as much as possible. And don’t be afraid to run some tests with just simple text docs; you’ll be surprised how much you can learn.

2. Complete experience on mobile (or, stop mobile “lite”)

Like many other companies, we’ve often assumed that users only want to do a small set of tasks on mobile — on-the-go tasks like checking flight status or time-killing tasks like checking Facebook. This has led us to create mobile sites that are “lite” versions of the desktop site.

Site analytics data and Google search data say this is a mistake. For just about any task people do on a desktop site — from buying products to booking travel to reading support articles — people are increasingly doing it on small screens. Forcing users to “visit the full site” and pinch and zoom their way through “non-essential” tasks is a recipe for frustrated users and site abandonment.

The fix: If you have a bloated site, by all means follow the spirit of “mobile first” and use your responsive project as an opportunity to prune. Do this because it’s the right thing to do for all users.

But for the pieces that are worth keeping for the large screen, include them on the small screen versions of your site as well. You’ll want to show many of them differently, but the core experience should be equally good.

3. Structured content (or, stop the blob)

Think of a typical web page with content, let’s say a customer case study. For the user, different chunks of content show differently: a headline in large font, a summary or teaser sentence in italics, a pullout quote in bold, “related articles” links at the bottom, and so on. But for many of the sites we work on, in the CMS where this page is pulled from, the writer enters this content as more or less a single blob of text. She then adds form to it within a WYSIWYG editor.

You can survive using this “single blob of text” approach if you have a simple site and only care about the desktop version. But it’s severely limiting once you start trying to repurpose your content for multiple parts of your site, multiple channels (web, social, email), and multiple screen sizes — all of which are an increasingly important part of a sound content strategy.

The fix: Make your content more flexible and reusable by adding structure to it. Identify your relevant content chunks and break them out within your CMS: headline, teaser, author, dates, product name, pullout quote, customer reviews, related links, etc. Add meta data around this content to allow non-humans to make sense of it. Maintain a single overall version of your content for all platforms, and add alternate versions of different components (e.g. short and long headlines) where appropriate.

4. Layered web design

Just as responsive design doesn’t fix bad content, it also doesn’t fix fundamental problems with your front-end code or your design workflow.

I’m not much of a coder, but with the help of UIE, I’ve been reading and listening to everything I can from developers who get the importance of UX and mobile. People like Aaron Gustafson, Brad Frost, Tim Kadlec, Jason Grigsby and Stephen Hay.

The most interesting thread I’ve heard is the importance of starting with the core and layering on complexity as you build a site. This is the idea behind Progressive Enhancement, which has been around for over 10 years: provide a core experience with just HTML, and then a richer experience with HTML + CSS, and finally a truly interactive experience with HTML + CSS + JavaScript. If a user can’t access the full experience — due to browser, screen size, or other constraints — they still have a *good* experience, rather than no experience at all.

This approach seems obvious enough and gets lots of nods from developers, but has generally been ignored in the race to build things that are flashy and cool.

Aaron Gustafson has helped restate this philosophy for a world of mobile, HTML5 and CSS3 — and has relabeled it “adaptive web design.” Brad Frost talks about a layered approach that borrows concepts from chemistry: “atomic web design.” Stephen Hay makes a great case for a new, responsive-friendly workflow that starts designing “from the content out.” And Luke W captures a lot of the same themes with “mobile first.”

There are differences in each approach, but the big takeaway for me is the same: start with core content and build up from there.

5. Collaborative design and UX generalists (or, stop the handoff)

I don’t like to admit it — since we call ourselves a Lean shop — but we’ve generally used a classic waterfall approach to building or redesigning sites and apps. As the UXer, I create the IA and wireframes, then hand them off to a visual designer to make them look pretty, who then hands Photoshop comps off to a developer. Yes we talk during the hand offs and a little before and after, but it’s still largely a handoff.

This approach has been comfortable for me. I love going away for a few days to work on wireframes and prototypes in isolation. Others on our team are the same way for their pieces. But this way of working has led to a lot of misunderstandings — and missed opportunities — that cause rework, delays and a worse product.

The simplest example is when I hear a developer say how long a particular piece of functionality took him to build, and I find myself saying “I wish I’d talked to him earlier … I would have told him to just drop it.”

So we’re working on moving from rigid workflows based on detailed specs/wireframes/comps to more fluid workflows based on collaboration and shared understanding.

We’re also moving away from a focus on rigid, specialized roles — information architect (IA), copywriter, interaction designer, visual designer, user researcher, SEO guy, web analyst, coder, etc.

In the past I’ve been inspired by the idea of bringing together lots of highly specialized people. Need to redo the navigation? Bring in a contractor who specializes in IA. But recently I’ve had more success when I stretch our existing team to take on more skills — and this will be a big push for us this year. More of us watching and talking to users. More of us designing. More of us looking at analytics data. And so on.

And when we need to bring on a new team member … we’ll go after a generalist or hybrid who loves learning.

6. Design in the browser (or, stop static wireframes and comps)

This last priority flows directly from #5 but is worth a separate mention.

It’s another one that really pushes my comfort level, because boy do I love getting lost in Axure, Balsamiq and other prototyping tools. I especially love building highly interactive prototypes to the point where we can run realistic user tests — and then boasting to the client that “we did all of this without a single line of code.” But that’s a lie; there was plenty of code, it just wasn’t HTML, CSS, JavaScript or PHP.

A couple months ago, as I started learning how to create responsive views in the latest version of Axure, I found myself wondering if it wouldn’t be just as easy to learn responsive design via CSS. Around the same time, I started hearing more and more people making the case for UX and visual designers to “prototype in code.”

One of the best arguments for it will sound familiar: this was worth doing before mobile; but mobile — with its fluid, messy, and unpredictable screens — makes it a requirement. Among other things, you have to know the constraints of all of the screens you’re designing for; and there’s no way to know this if you’re not designing in the browser.

So after 5+ years away from it, I’m excited to jump back into coding.

A final point: don’t forget the basics

The risk with focusing on trends and hot topics is that you neglect the UX basics that have been true for a long time and should be a focus every year. Things like a deep understanding of customers, useful and readable content, and usable design.

So I like to think of the priorities above as ways to reinforce and resurface enduring UX principles, not replace them.

Learn more

Here are some of the sources for the ideas above.

Some books:
Karen McGrane, Content Strategy for Mobile
Aaron Gustafson, Adaptive Web Design
Stephen Hay, Responsive Design Workflow
Sara Wachter-Boettcher, Content Everywhere
Luke Wroblewski, Mobile First

Some articles:
Karen McGrane, Responsive Design Won’t Fix Your Content Problem
Brad Frost, Atomic Design
Lou Rosenfeld, Seeing the Elephant: Defragmenting User Research
Jared Spool, The Redesign of the Design Process
Jared Spool, Perspectives Over Power: Habits of Collaborative Team Meetings
Jared Spool, Building a Cohesive Design Team
Stephen Hay, Designing for Breakpoints
Aaron Gustafson, Progressive Enhancement and the Content-out Approach

Some podcasts:
Jason Grigsby and Jared Spool, Responsive Web Design with Mobile in Mind
Nate Schutta and Jared Spool, Coding Mobile Prototypes
Ben Callahan and Jared Spool, Structuring Your Workflow for Responsive Design
Karen McGrane and Jared Spool, Adapting Your Content for Mobile
Nathan Curtis and Jared Spool, Prototyping with HTML and CSS
Aaron Gustafson and Jared Spool, Adapting Your Designs with Progressive Enhancement
Sara Wachter-Boettcher and Jonathan Kahn: Future-ready Content

And a video:
Luke Wroblewski, Mobile to the Future (presentation at Google)