UX deliverables had a rocky year so far. I feel particularly bad for the humble wireframe, which took some serious knocks over the past few months. There’s also a growing skepticism about the value of Personas. The Persona thing made me particularly uneasy because I’ve always been a huge fan, and we still start most of our projects with a workshop to define Personas and User Journeys.

That unease led me to introspection, which is a good thing, because it made me step back and revisit why we use Personas, and how we use them on a very practical level to design better products. The problem is, I came up short… I realized that though Personas are extremely useful to help clients figure out who their target market is, and understand those users better, they’re often not very useful once we go into the Interaction Design phase of the project1.

In contrast, the User Journey map that we create at the beginning of every project remains open in a tab until everything is done and dusted. I cannot overstate the usefulness of user journey mapping as a UX method. And then there’s the content plan — another essential part of the puzzle that we always create before the design phase starts. Once we’ve done a version of the Information Architecture, the content plan maps what kind of content needs to go on each page. But these are all separate documents, and you can only reference so many PDFs on any given day before it gets terribly distracting.

I realized that one of the problems with Personas is that it takes extra work to turn those user insights into artefacts that are useful for design. And that led me to the realization that there is probably a better way to group all these disparate UX deliverables together to help us create better products.

I decided to test my theory, so on a project we recently started, our User Journey map became more than just a journey with touchpoints, emotions, takeaways, etc. It also became a representation of the Information Architecture and the content plan, with our Personas (needs, goals, scenarios) serving as the starting point for everything — sort of like the glue that ties it all together.

The project is still very much in progress, so I can’t show the full end result yet, but here’s a slightly blurry snapshot of one section of the journey:

This document is a summary of everything we need to know to design the best possible product for users. It has the following elements:

• Unique selling points to keep us focused on what the site needs to communicate at all times. This comes straight from the Persona needs and goals.
• Journey stages and model to remind us how the product fit into people’s lives, and what the primary calls to action need to be throughout the site.
• Questions that our target Personas are likely to ask in each phase of the journey, to focus the type of content we serve on each page. In an e-commerce context, these are questions like, “Can I trust this retailer?” or “When will my stuff arrive?”
• Takeaways and key principles to summarise the above sections (which primarily act as problem definitions/requirements) and document how that translates into the design decisions and solutions we need to keep in mind throughout the design process.
• Content plan that maps each phase of the journey with the questions our Personas will ask during that phase, and what it means for the specific content that needs to go on each page. We get very specific here — nothing gets on the page unless it’s in the content plan. And if we can’t identify a Persona that would find the content useful, it just doesn’t go on the list.

Even though the Personas aren’t explicitly referenced on this document, we extract the key points from each and turn those into information that is actually useful for design — namely the content they are most likely to be interested in. The Persona step is essential to help us get to this point, so we can’t skip it, but we don’t need to show faces and names and stories on the User Journey map to make that information useful.

So, in the spirit of “getting out of the deliverables business”, this expanded User Journey map becomes the only document we use to guide us throughout the design process. 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 for us. It also places content at the centre of the design process, which makes it easier to follow mobile first and responsive design strategies.

I’m sure it’s not perfect, but so far this has been an extremely useful artefact for us.

---

1. Des Traynor wrote a good article about this. ↩

Joshua Tanenbaum, Audrey Desjardins, and Karen Tanenbaum take an in-depth look at Steampunk sub-culture, and specifically what it means for the future of Interaction Design, in their article Steampunking interaction design. It’s a dense piece, but really interesting. They discuss design fiction as a form of envisioning the future, and how Interaction Design could adjust to that possible future:

Steampunks have imagined a whimsical neo-Victorian fiction to frame their design practice: an optimistic lost age of adventure where invention, individuality, and innovation reign supreme. This fictional world reflects a set of values and relationships with technology, but that is not the most interesting or relevant thing that Steampunk has to offer the HCI (Human-Computer Interaction) community. Instead, it is in the practices of Steampunk makers that we can observe a possible future for interaction design: a future in which design is driven by aesthetics, grounded in a sustainable ethos, and aimed at serving the needs and preferences of distributed communities of engaged expert users.

Also see How steampunk culture offers clues to building a better future for another interesting viewpoint on this movement.

John Pavlus in Your Body Does Not Want to Be an Interface:

The assumption driving these kinds of design speculations is that if you embed the interface — the control surface for a technology — into our own bodily envelope, that interface will “disappear”: the technology will cease to be a separate “thing” and simply become part of that envelope.

The trouble is that unlike technology, your body isn’t something you “interface” with in the first place. You’re not a little homunculus “in” your body, “driving” it around, looking out Terminator-style “through” your eyes. Your body isn’t a tool for delivering your experience: it is your experience. Merging the body with a technological control surface doesn’t magically transform the act of manipulating that surface into bodily experience. I’m not a cyborg (yet) so I can’t be sure, but I suspect the effect is more the opposite: alienating you from the direct bodily experiences you already have by turning them into technological interfaces to be manipulated. 

It’s an excellent essay. I especially like the distinction between Ready-at-hand and Present-at-hand technologies, and how our bodies shouldn’t become marionettes to technology.

Matt Alexander wrote a guest post on 512pixels while Stephen Hackett is away on vacation with his family. It’s called Community, and it really hit home for me:

Perhaps we’re brought together by a foundational love of design or genuinely good products — often embodied by Apple — but I believe we remain, regardless of evolving opinions, because of a visceral sense of community.

I encourage you to read the whole post, as well as Stephen’s letter to his son, which Matt links to at the beginning.

I’ve had a bit of a rough month that gave me a lot of doubts about remaining active in the design industry. But Matt’s post reminded me again that for every bad experience, there are ten examples of people in our community being generous and supporting each other. And maybe it’s time for us to talk about that a bit more, even on our tech-centric sites.

Cap Watkins did it recently, and so did Anil Dash. We need those constant reminders of what Frank Chimero sums up so well in Issue #1 of The Manual:

The web is a technology, but more importantly, it is people all the way down. People constitute and maintain the network. It is widespread and distributed, but it is very delicate. Like a real web, it needs constant maintenance to keep from tearing.

In a recent interview with Intercom, Joshua Porter expands on his “Wireframes are dead, dead, dead!” tweet from a while ago:

I think you can capture almost everything you need to capture in a pretty detailed sketch. Not a high fidelity sketch by any means. Not the ones where you use five different kinds of markers and you shade everything or whatever. The purpose of sketching is to communicate the major ideas, like, “What’s going to be on the page? What are the objects on the page? What are the things you can do to those objects?” […]

On the other hand if you want to actually test something, you need a prototype that someone can test. So, I would actually say that the role of the product designer is working with stakeholders to come up with those sketches, and then going right from that sketch all the way through to prototyping. That usually means high fidelity mockups that can be clickable or lightweight HTML prototypes that are clickable and usable.

This is the workflow we’ve adopted at Flow as well. We sketch different interface ideas (variation), and then move to prototyping in Axure when it’s time to test and improve a specific idea (iteration). There’s not much room for static wireframes in that workflow. But it is an ideal workflow, and not every project is ideal. As I’ve mentioned before:

Lacking budget, flat wireframes for quick iteration is better than doing no iteration at all. We can’t be so idealistic that we’re not willing to scale down our processes when we need to.

So as long as we’re willing to admit that one size doesn’t fit all, I’m all for advocating an ideal approach that degrades gracefully under non-ideal circumstances.

Also see Wireframes: A good communication tool, a poor design tool by Dan Ritzenthaler.

I always enjoy the interviews on The Great Discontent, and this one with designer Matthew Smith is no exception. Here he describes how he turned his hobby into a business:

At the time, my wife was pregnant, we had a one year old, and we were all living on about $26,000 a year—I knew I had to think bigger, so I went for it. I got the first $8,000 job and then another. Then people started asking me to build more things, like customer databases. I would nod in agreement as if to say, “Of course I can do that,” and then I’d get off the phone, crap my pants, and go do research on Google, ask questions on forums, and figure it out in order to deliver a product to a client and make them happy with the results. Done!

I can certainly relate to the get off the phone → crap pants → figure it out workflow. I also like Matthew’s critical take on the concept of endless feeds on the Internet:

Who came up with the idea of endless content constantly streaming toward us? There’s this unlimitedness that concerns me because it is so unlike the rest of the human experience and I think it confuses the human mind and puts us into a space where we aren’t at our best. I want to make sure that no matter the project or company I’m involved with, I’m always asking if it’s serving the human best and helping us be at our best.

That last part reminds me of something Alex Griendling said recently:

Our work does not exist in a vacuum; it is given context and meaning and power by the places it appears and the people that benefit from its usage. When clients hire us, they’re doing so because they believe it will benefit them. With this in mind, it’s important to ask yourself the question “Is this client worth helping?”. If great work is made for those that exhibit repugnant practices, how does this benefit anyone other than the individual client?

Words to live by…

This post provides background and additional resources for my talk on Responsive Web Design in Africa. Last update: May 23, 2013.

I’ve seen a surprising amount of pushback on responsive design within the South African web community recently. The skepticism is mostly based on issues such as low smartphone share and high data costs in Africa, along with assumptions about “the mobile context” and how people supposedly have vastly different needs on mobile phones than they have on their desktops.

So, the purpose of this talk is to summarize the case for Responsive Web Design, and to argue that the reasons against using this approach in Africa don’t hold up. Smartphones and data access are exploding in Africa, so if we want to be Future Friendly, we don’t have a choice. We have to adapt.

The slides for the talk are below, although of course, some context gets lost without the voiceover. There are also embedded gifs and videos that obviously don’t play within Slideshare, so you’ll have to use your imagination on those…

View on Slideshare: Responsive Web Design in Africa - why it’s time to adapt

---

Resources

I cite the source for each quote, example, and data point on the applicable slide, but I thought it would be helpful to provide a brief list of Responsive Web Design resources here for easy reference.

For those who want to dig a little deeper on the data in Africa, here’s a list of the reports and presentations I found most useful:

• GSMA’s Mobile Observatory Series, particularly the report African Mobile Observatory 2011 (PDF link)
• Insights into Mobile Telecoms in Africa by Jon Hoehler and Andrew McHenry
• The Smartphone Snapshot Showdown by Jon Hoehler and Andrew McHenry
• Key findings from the Mobile Africa 2012 report (thanks to Ethan Marcotte for this link)
• Insights into the mobile-only generation

Here’s an incomplete list of introductory articles to get you started on responsive design. These articles mainly touch on topics I bring up in the talk, like the reasons for adopting responsive design, performance issues, and RESS:

• Define :: Responsive (a demo to show people how it works)
• Responsive Web Design: What It Is and How To Use It
• Reasons for Responsive Design
• Responsive web design: the war has not yet been won (More reasons)
• Content Parity (Relates to the “Mobile is Less” myth)
• Impact of Responsive Designs (Some good data on the benefits of responsive design)
• Where to Start (How to start adjusting workflows)
• Prioritizing Performance in Responsive Design
• Conditional Loading for Responsive Designs (On progressive enhancement)
• Getting started with RESS (Server-side components to deal with lower end phones)
• Responsive Deliverables (What you can expect from your design team or agency)

If you’re looking for responsive patterns, start here:

• Brad Frost’s collection of patterns and modules for responsive designs
• Responsive navigation plugin (without library dependencies and with fast touch screen support)
• Some more patterns for dealing with navigation
• Responsive Multi-Level Menu Demos
• Alternative ways to optimize navigation across touch devices (Luke Wroblewski and Jason Weaver)

And here are some ideas for dealing with responsive images:

• Adaptive Images in HTML
• Responsible Responsive Images by Mat Marquis
• ReSRC.it (Responsive images on demand, directly from the cloud)
• A small set of CSS classnames to help keep images cropped on the focal point
• A quick intro to Icon Fonts

For more great resources on responsive design, see Jeremy Keith’s extensive list.

---

The point

My goal with this talk was not to say anything groundbreakingly new about Responsive Web Design. The goal was to urge designers and developers who work in developing regions to take responsive design seriously, and at the very least consider the approach for their next projects.

If you have any questions or comments (or are interested in having me come present this talk somewhere), please get in touch.

I liked Meng To’s Simplifying For The Wrong Reasons, but there’s one part that perpetuates one of the most enduring myths in user experience design:

The best user experience reduces the amount of clicks to as few as possible.

No one’s going to argue that we should add superfluous clicks in interfaces. But making “as few clicks as possible” an optimization goal is how interfaces become bloated and crammed with cruft. As Lukas Mathis points out in his explanation of the psychological behavior called “satisficing”:

A great user interface is not one where each goal can be reached with the smallest number of clicks possible, or where the user has to pick from only a small number of choices at each step, but one where each individual click is as obvious as possible. […] As long as users feel that they are getting closer to their goal with each step, they don’t mind drilling down into a deep hierarchy.

Josh Clark also addresses the myth that extra taps and clicks are evil in an interview with Forbes:

In mobile, tap quality is far more important than tap quantity. As long as each tap delivers satisfaction, extra taps are good. Taps invite conversation—give and take—that you can get at and explore. Building meaningful click sequences are a form of progressive disclosure that helps you uncomplicate complexity.

So, let’s get away from this idea that we should optimize for the fewest number of clicks and taps. Instead, we should optimize for an information architecture and visual hierarchy that makes the next step as obvious as possible. Joshua Porter summarizes this approach nicely:

Almost every screen we design can be improved by really focusing on the steps and sequences of steps a user goes through. In our haste we often speed up the process too much, get steps out of order, fail to present an appropriate next step, or otherwise break the sequence. By re-assessing your app or site in light of these potential errors, you can discover the sequence and timing that your users need to successfully make it to the next step.

Chris Ferdinandi wrote a good summary of the responsive site vs. separate mobile site debate in Content Parity on the Web:

The gentleman I was chatting with mentioned that for mobile users, he intended to share about 50 percent less content and reduce the steps in their checkout process to make it more efficient. I think that’s a great idea, but I don’t think it should be limited to the mobile site.

If 50 percent less information is the right amount of information people need to complete their tasks, then you should only provide that 50 percent on all devices. And if visitors on laptops could use that additional information, why wouldn’t someone on a smaller screen want access to it, too?

Whenever I chat to people about Responsive Web Design, there are always arguments about how users want different information on mobile devices than on desktops. This usually plays into the myth of mobile context, but in some cases, there are legitimately different use cases. In those cases I press on to argue that separate use cases are not proof that you need a separate mobile site, but proof that your Information Architecture needs some additional work to make the right information easily accessible regardless of the device being used.

But we’re still figuring this out, of course — no one has all the answers. Just reading through some of Luke Wroblewski’s notes from BD Conf got my head spinning again. So anyway, if you’re in Cape Town next Thursday and want to argue with me about this stuff in person, I’m doing a talk called Responsive Web Design in Africa — Why it’s time to adapt at the next SPIN gathering. It should be fun.

I’ve long been fascinated by the links between coffee, craft, and product design. Peter Baskerville’s answer on Quora to the question How do you compete with Starbucks in the coffee industry? is another great example of that. His answer can very easily be applied to building an online product (my emphasis added):

I concluded very quickly that Starbucks was good for tourists and those folk looking for brand association, but their appeal to the quality espresso seeking locals was limited to just one curious trial. I also saw that they were in fact following the age-old successful chain formula of adequate product + brilliant marketing rather than the other way around. So they were not actually targeting my niche unique coffee/service market, which is where I believe the independents fit in.

This is so true for the current state of software development. We used to swim in a sea of adequate products that employed brilliant marketing to convince us they’re better than they really are. Now, the products and services we gravitate towards are increasingly brilliant niche products that don’t have to rely on an overdose of traditional marketing to gain traction. From Dropbox to Clear to Instapaper, people are flocking to quality products after their “one curious trial” of the do-it-all marketing-driven alternative doesn’t quite meet their needs.

Peter goes on to list 8 specific strategies that Australian coffee shops have used to beat Starbucks. With advice like “Quality above all” and “Let your customers own you”, his answer gives product designers plenty to think about.

Some of my previous posts on this topic include Coffee, design, and the nature of craft, and How to get buy-in on your design process.