I’m excited to be part of Industry Web Conference in April this year, alongside some people I’ve admired for a long time. I’m going to be talking about a thing that’s fallen out of fashion a little bit over the past year or so: Deliverables. Yep — the business we’re supposed to be getting out of. So I’m a bit nervous about the talk, but I hope people will give it a chance.

The talk is called Getting back into the (right) deliverables business, and here’s a little more about it:

I feel a little bad for the static wireframe. It’s had a bad year. In fact, UX deliverables in general have had a bad couple of years. There’s a growing skepticism about the value of Personas and other traditional UX artefacts, as well as an onslaught of “get out of the deliverables business” refrains from Lean methodologies.

All of this led me to lots of introspection about deliverables, and if it’s actually possible to create deliverables that are useful to help create better products.

In this talk I’ll tell our story. How we stripped down all our deliverables to almost nothing, and then started building it all up again slowly by asking ourselves, “What is absolutely necessary for us to do a great job?” I’ll discuss some of the deliverables we’ve since created (such as Expanded Journey Maps and Content Slice Diagrams), how they’re useful to us, and how you might be able to use them in your design process as well.

We’ve come to realise that not all UX deliverables are bad. Only bad deliverables are bad.

I’m going all in on this — the day before the conference I’m also doing a full-day workshop called Using Customer Journey Maps for Effective Content-First Design. This will be a very practical day on what has become an essential deliverable for us:

More than just a journey with touchpoints, emotions, takeaways, etc., it’s also a representation of the Information Architecture and the content plan, with Personas (needs, goals, scenarios) serving as the starting point for everything — sort of like the glue that ties it all together.

You can think of this as the UX Strategy document. It incorporates Persona-based user needs and business goals with site structure and content planning in a way that really works. It also places content at the centre of the design process, which makes it easier to follow mobile first and responsive design strategies.

In this workshop we’ll discuss the value of this document and then go through a practical exercise to create an Expanded Customer User Map so you can apply it in your roles immediately.

So anyway, I’m really looking forward to it. And here’s the special bit. If you use the discount code rian, you can get conference tickets and/or workshop tickets for £40 off. That’s a pretty substantial discount. You can read more about the conference here, and register here. I hope to see you in Newcastle upon Tyne in April!

Jeffrey Zeldman in a strong defense of web standards:

While many of us prefer to concentrate on design, content, and experience, it continues to be necessary to remind our work comrades (or inform younguns) about web standards, accessibility, and progressive enhancement. When a site like Facebook stops functioning when a script forgets to load, that is a failure of education and understanding, and all of us have a stake in reaching out to our fellow developers to make sure that, in addition to the new fancy tricks they’ve mastered, they also learn the basics of web standards, without which our whole shared system implodes.

I’ll add this to the ever-growing case for progressive enhancement.

Sean Madden makes some interesting points in American-Centric UI Is Leveling Tech Culture — and Design Diversity:

Just as user-centered design transformed technology in the 1990s and early 2000s, cultural fluency needs to transform it today: user experience (UX) design that’s familiar enough with a user’s cultural background to meet him or her halfway.

Cultural fluency demands abandoning the idea that functionality is a universal language, and that “good UX” is culturally agnostic.

He goes on to give some examples of this cultural bias:

Consider the use of gestural interfaces in a world where gestures mean very different things in different cultures. Or using scrolling for timelines when time horizons (among other culturally sensitive dimensions) represent different values to different societies. Even the idea of touching our screens is a culturally sensitive UX action.

We see this not just in how people use products differently, but also how we interact with them during the user-centered design process. Last year I started working on a talk called The challenges and opportunities of user-centered design in developing nations. Somewhere along the line I ran out of steam with it, but I still think it’s an important topic. For example, a usability lab in an office full of Macs and giant screens can be quite intimidating to users if you’re doing research on low-end phone usage, so that’s something you have to account for. Even our user-centered design methods need to be user-centered, but it’s unfortunately something we tend not to pay much attention to.

In Snow Fail: Do Readers Really Prefer Parallax Web Design? Eric Jaffe reports on a recent study done at Purdue University by graduate student Dede Frederick:

“I’ve read from many blogs how people say it’s going to attract users and create so much of a better user experience,” Frederick tells Co.Design. “I thought it was going to be superior to a typical website in every aspect.”

As it happens, the parallax site was only superior in one sense — fun. None of the other survey measures indicated a significant difference in user experience between the two sites. Parallax didn’t even edge the standard site in questions about visual appeal (although participants did think it looked slightly more “professional”). Frederick also discovered one critical disadvantage of parallax: test participants who suffered from motion sickness found the style disorienting.

This doesn’t mean parallax scrolling can’t be used well, just that we shouldn’t jump on every new design fad without understanding its usability impacts first.

I’m a big fan of the recent move away from user stories to job stories to design better products. Alan Klement provides a good overview in Designing Features Using Job Stories. That said, I’m worried that personas are on the verge of extinction as collateral damage of this evolution. We can’t let that happen. Alan explains his issue with personas as follows:

The biggest and most pertinent problem with Personas is this: Personas are imaginary customers defined by attributes that don’t acknowledge causality.

These attributes, generally in the form of demographics, do not bring a team closer to understanding a customer’s consumption, or non-consumption, of a product. The characteristics of a Persona (someone’s age, sex, race, and weekend habits) does not explain why they ate that Snickers bar; having 30 seconds to buy and eat something which will stave off hunger for 30 minutes does explain why.

The problem with this argument is that it refers to marketing personas, which are generally not very useful for design. Marketing personas are usually based on segmentation data, and ends up being mostly about demographics that cluster similar groups of users together.

But we shouldn’t confuse marketing personas with design personas, which are specifically created to guide the development of product features. How are they different? Well, first and foremost, design personas are based on needs, goals, and dimensions that have a direct impact on their interaction with the product. In other words, they incorporate causality, which takes care of Alan’s gripe.

For example, below is a design persona for a short-term loan company. There are a few things to note:

• There’s very little demographic detail — just enough to help us get to know this persona. Most of the persona is focused on their goals and needs, and what they want to accomplish.
• Note how causality is all over the story and the goals — Monde needs a loan now for an urgent need. This is very different from someone who just wants some money for a new TV.
• The key to these types of personas are the dimensions, or in this particular case, the loan drivers. Note that for Monde, the monthly instalment is not important. What’s important is that she gets the amount she needs to pay for her travel. For the persona that just wants a TV or some new shoes, this is different. For that persona the amount is less important — what’s most important is whether or not they can afford the monthly instalment.

My point isn’t that job stories aren’t necessary. On the contrary, I think job stories are much better than user stories for product design. But job stories are a valuable augmentation to design personas, not a replacement for them. There is still a huge amount of value in personas. They have names and faces, so the whole team can picture them. As opposed to a mythical “average” user, they are solid people we can imagine using our product to achieve their goals. This is helpful because by focusing on individuals that are closer to the edges of the experience, instead of the average, we’re able to cater design for a larger portion of the user base.

In the documentary Objectified, Dan Formosa from Smart Design says, “What we need to do to design is to look at the extremes. The middle will take care of itself.” As an example, he talks about how they once designed garden shears specifically to cater for people with arthritis. They knew that if the shears worked for that “user”, it would work well for everyone. That’s the power of personas.

I understand and agree with the concern that personas can sometimes be oversimplified caricatures of users that don’t take specific situations and actions in consideration. Without proper research personas also tend to be be shallow and not very useful. But those are dangers that are easy to avoid. Remember that personas aren’t prescriptive, they’re descriptive. You can’t identify a persona and then try to predict people’s behavior off it. But with solid research and analysis you can use personas effectively to help focus development efforts on target users, and help define what features should be included in (and just as importantly, excluded from) the product.

As a side note, in addition to the job story format I also sometimes like to use what I call problem stories. These are like user stories, except that they incorporate “triggers”, which takes causality into consideration. The format I use for problem stories are:

User has problem when trigger.

For example, a Product Manager on a financial services product might have a problem story that states, “Investors are not able to submit supporting documents online when they need to make changes to client portfolios.” That becomes a statement of the problem that needs to be solved through product improvements, and a good way to develop features by focusing on user needs.

All this to say that job stories (and problem stories!) are great ways to guide product and feature development. But if we use them to replace design personas, we’ll be throwing tons of useful context and understanding out along with it.

The VCSO team did a great interview with designer and illustrator Kyle Steed about his recent trip to Israel. I love Kyle’s view that what makes VSCO Cam great is all the ways it’s decidedly not Instagram:

It’s like this, you can’t just slap a b&w filter on a crappy photograph and suddenly it’s Ansel Adams, that’s foolish thinking. But this is where the majority lives I believe, in this make believe world that if they add enough filters and effects to their photo, then they’ll make the “pop” page. Note: Please don’t get me started on the popular page.

And yet another reason why I love the VSCO Grid, there are no likes, comments or other superfluous information that only adds hot air to a photographers headspace. Jerry Maguire said it best: “Fewer clients. Less money.” which could be translated in this case as: “Fewer followers. Less comments.”

Khoi Vinh wrote a great essay exploring What Streaming Music Can Be. He starts by describing some of the things that made buying CDs and albums a meaningful experience:

This is all trivia, to be sure, but it’s the kind of stuff that used to be such a meaningful part of owning music — and that makes one a fan for life. Having a record in your collection meant that you could spend time poring over its liner notes: familiarizing yourself with the names of musicians, producers, engineers, and managers; memorizing lyrics; and studying photos of musicians’ faces, stances and attire. These were the intangible qualities that made music more than just a service, but something to be collected.

But Khoi doesn’t just want streaming music services like Spotify and Rdio to copy the days of physical liner notes. Instead, he makes some suggestions on how these services can use metadata in fascinating ways to add meaning to digital music.

I’ve been a happy Spotify customer for a few months now, but everything Khoi says in his post makes sense to me. I’ve discovered some great music — and some great albums — but I tend to listen to those albums a lot less than when I used to buy CDs. The turnover is just too fast — there’s always something new to discover. And I’m hungry for it, incapable of resisting the lure of the next great song.

Apart from the missing metadata, there is something else that bugs me about streaming services (and digital music in general). Janko Jovanovic discusses this in the context of eBooks in his post Digital and physical, but it’s just as applicable to digital music:

When I buy a physical book, it starts to live a life of its own. After reading it for days or weeks, the book changes. It’s not brand new anymore. Edges of papers lose their sharpness. The cover becomes slightly bent and you can tell it was read just by looking at it. When I put a book on a shelf it becomes a part of the space I live in and it continues to change over time. This transience and decay of things around me remind me that I should use every moment of my life since I will go through the same lifecycle as that book. […]

All digital goods, be it ebooks, software, documents or images give me a sense of permanency and immutability. They are sterile. And that sterility prevents me from getting in touch with transience and gives me a sense of timelessness. Which is just an illusion.

I’m not going to end my Spotify subscription, but I do miss glancing over my CDs, observing the wear and tear of albums that have gone through so much with me. Those CD covers become more than the music they contain. They become reminders of a life well lived. And I do fear that I’m losing that now that I mainly listen to my (admittedly awesome) Spotify playlists.

My thanks to Webydo for sponsoring Elezea’s RSS feed this week.

Webydo enables professional web and graphic designers to create, publish, and manage websites without having to write a single line of code, and provides them with the freedom of creativity to focus on what’s important — the DESIGN.

Webydo is made by designers, for designers and is the only solution for website creation with a built in CMS (content management system) and DMS (design management system). Webydo also gives you the option to directly bill your clients, brand Webydo as your own, and provide full cross-browser capabilities. What’s more, with Webydo, you can efficiently create a responsive website with complete cross-browser capabilities as well.

Experience the freedom of creativity with Webydo’s professional online design software today for free.

Sponsorship by The Syndicate.

Alex Maughan gives some great front-end design and development tips in his article Mobile-first, semantic, and modular front-end design. If any part of your work touches front-end development, I highly recommend this piece. In addition to walking through the tools he uses (and his reasoning), Alex also makes a strong case for progressive enhancement:

Designs should be approached with a content-first and mobile-first mindset. Following this, CSS breakpoints should always be mobile-first. All JavaScript should be progressively enhanced and should be used at a conscientious minimum where possible. Therefore, the concept of progressive enhancement happens from all aspects, from design to development and back again.

All of this translates into websites that are much more future-friendly within a disruptive device and browser marketplace. It also has the added benefit of improving performance and guarding against fatal runtime errors that stop pages from working.

I haven’t yet linked to many pieces on progressive enhancement. As I went through my Pinboard links just now I realized that 2013 has been a big year for this topic. These are all the articles I know about that came out this year in strong defense of progressive enhancement:

• Progressive enhancement is still important
• Progressive Enhancement: Still Not Dead
• Progressive Enhancement. Still Alive & Kickin’
• Progressive enhancement is faster
• A plea for progressive enhancement
• Progressive Enhancement: It’s About the Content

I don’t know, it sounds like it’s not dead yet…

Finally, I have a legitimate excuse for my obsession with sci-fi and post-apocalyptic literature. Apparently it’s going to make me a better designer. I’ll take it! Rebecca J. Rosen explains Why Today’s Inventors Need to Read More Science Fiction:

Once any sort of technology has users, it becomes extremely difficult to change it — even if you know it should or must be changed. […] How is that affecting our social structure and values? How is that changing the way we view ourselves and even the way we understand our own mental functioning? […]

Reading science fiction is like an ethics class for inventors, and engineers and designers should be trying to think like science fiction authors when they approach their own work. […] I feel with great urgency that we need to very thoughtfully consider what we build as well as encourage that same thoughtfulness out in the world.