Menu

Posts tagged “user experience”

Why some people prefer physical books over ebooks

I’m a little hesitant to believe these kinds of stats without seeing the actual research (and you have to pay for this report, which makes it even harder to verify), but Voxburner claims that 62% of 16-24s prefer books as physical products. That’s interesting in itself, but even more interesting is the reasons they cite:

There is less affection towards electronic versions of books. Whereas age is shown in the spine of each book — and commitment by the size of one’s bookshelf — digital files have no distinguishing characteristic. Most books adhere to the same fonts, as defined by the standards of ebook readers, and e-ink displays are void of any images besides the cover due to the lack of colour.

One of the things we sometimes miss in the ebook vs. physical book debate is that some of the inherent benefits of physical books have nothing to do with the act of reading. The experience of reading an ebook might be very similar to reading a physical book, but your Kindle doesn’t give you bragging rights. No one can walk into your house and see what kind of person you are just by looking at your Kindle — but they can learn a great deal by walking past bookshelves filled with the words that represent how you want the world to perceive you.

We often forget that physical products speak to a predisposition that digital products simply cannot counter: our own vanity.

Design agency life

Tim Caynes’ on exposure is an honest and accurate depiction of what it’s like to work at a design agency:

if there’s one thing that really hits home in your first 3 months of transition, it’s the change in pace. and it’s not that the change in pace is a bad thing. it’s just that it feels like you don’t have enough time to think. which means you don’t have enough time to design. which is stressful and surprising and difficult and awkward. because you might not actually be able to do it. you might fail. and everyone will be able to say they told you so. and you’ll be exposed.

And this:

be under no illusion, when you work for an agency, your constraint is time. but your reputation is all about quality. so quality is, and should be, ruthlessly monitored, evaluated, and understood. and that’s why the integrity of design and design thinking is the first thing that you will get caught out on. well, apart from the pace thing. but it’s not personal. even though that’s what it feels like the first few times someone like me sits down with you, looks at your designs and pulls that horrible squinty patronising-but-really-caring face that tells you there’s something not quite right.

This post hit home for me in so many ways.

How user experiences affects the bottom line

As I saw the tweets about Jared Spool’s talk at Warm Gun fly by, I hoped that someone would do a write-up because it sounded really interesting. I didn’t expect Forbes to come to the rescue, but hey, hell froze over! Anthony Kosner does of good job of distilling Jared’s main points in How Design And User Experience Translates To The Bottom Line:

In UX Strategy Means Business, Spool clued a room full of designers and developers into the five business priorities that they must consider as the ultimate goals of their efforts. Yes, as a designer you must be the strong voice for aesthetics and some of the more subtle aspects of user experience, but your bosses need something more concrete to respond to.

And yes, you’ll have to click through (and dismiss the ad, ugh) to see those five business priorities.

Resistance and digital design

The fifth and final Build Conf looks like it was, once again, a fantastic conference for web designers. The talks are still coming out, but so far there are two that really stood out for me. The first is Paul Soulellis’s Resistance — a fantastic essay on what an act of resistance looks like in design culture today:

I worry that this tendency to dismiss on the fly — as well as accumulating approval — might push us to make things for their ability to go viral. Designing for the showcase and rewarding smooth, easily digestible stories has become a kind of professional “code,” and I think this is where it gets dangerous.

Because some see it as permission to favor the quick fix of image-making over complex problem-solving. How many times have you been asked to build the site in a week. To design the logo in two days. To send files, right now. Somehow, we’re becoming a culture that values performance and instant product over presence.

Frank Chimero’s What Screens Want is another absolute must-read — one of the best essays of 2013. Frank goes on a journey to find the essence of digital design:

A designer’s work is not only about how the things look, but also their behaviors in response to interaction, and the adjustments they make between their fixed states. In fact, designing the way elements adapt and morph in the in-between moments is half of your work as a designer. You’re crafting the interstitials.

Both of these essays not only contain thought-provoking ideas, they’re also beautifully designed. Do yourself a favor and spend some time reading through both.

Content modules for Responsive Web Design

Responsive gif

By now it’s been well drilled into our heads that web design starts with content, not with graphics. However, in practice, getting real content before the design process starts is challenging at the best of times, and it’s made even more difficult by the fact that we have to try to get to content parity across all types of devices.

So to deal with this complexity we come up with more pragmatic guidelines. Mark Boulton’s “Structure First. Content Always.” is certainly a more realistic approach:

You can create good experiences without knowing the content. What you can’t do is create good experiences without knowing your content structure. What is your content made from, not what your content is. An important distinction.

So you have to start with the structure not the words. […] How do we design around the fluidity? Well, we define structure; of our content, and the templates that content inhabits. We define the rules of the system to display the content in different ways (if we can) to help the reader understand the content better.

The problem with all these approaches has always been the same for me: It sounds awesome in theory, but I don’t know how to make it part of our workflow when we’re in the weeds with client work. So we tend to try to make physical things that help us get there1. First we created expanded customer journey maps to define a content plan based on user needs and personas.

That helped a lot, but on the next project we got stuck on content structure again — how do we create different page templates with different types of content, without getting into interaction design too soon? So we came up with the idea of Content Modules: diagrams that show the relative importance and length of different types of content, in a Mobile First context. Here’s an example:

Content Modules

This document has a few key components:

  • Each block outline represent a distinct content chunk that can be used on any other page.
  • The primary call to action is highlighted (in orange in the example above) so that we can easily check for consistency and impact across different pages.
  • Some pages will have optional modules — those are also highlighted (in yellow in the example above).
  • A gap in a column doesn’t mean there’s going to be empty space on the page. This is not a layout diagram. It just shows the relative importance of each chunk. It also allows one to easily compare which page templates have which types of content on the page. This lets you easily spot if there’s some missing content (or unneccesary duplication).
  • Each page template looks like a mobile view. That’s by design. It helps us to move straight into designing mobile views first, using the content hierarchy defined in the document, and then scale that up to larger views.

Creating content modules was the missing step we needed to bridge the gap between the content plan in our expanded customer journey maps, and starting the interaction design / prototyping phase. I was constantly worried that we’d start projects with content at the centre, but then gradually backslide into old ways as the project progresses. This document helps us to move seamlessly from content planning to interaction design, confident that we’re designing on the right content-led foundation.


  1. I’m really trying to avoid the word “deliverables”, but I’m struggling. 

Some open questions on the Techrunch redesign

Brad Frost’s article on the Techcrunch redesign is a great case study of a modern responsive design process. A few things stood out for me, and remain open questions that I wish I could ask Brad about.

First, there is no mention of user research. There was a kick-off meeting, with some Design Studio work, but how did they identify user needs, and why was there no user testing on their prototypes? That’s a bit perplexing.

Second, it’s really nice to see Brad take a more nuanced stance on the whole Post-PSD Era thing, and admit that comps can be useful under the right circumstances:

Believe it or not, we did indeed create a few full comps. Gasp! Horror!

But the difference between this and all the other projects I’ve ever worked on is that we didn’t lead with the comps. By the time Dan made some comps (for the homepage and featured article page), we had established many of our key molecules and organisms, and had an understanding of the systematic nature of our design.

That’s how we do it in our agency as well, so I’m glad to find out that we’re not completely insane.

And lastly, it would’ve been great to get a little more detail on how much backend developers were involved through the process. Brad mentions it briefly:

From the design end of things, Dan went through and created an incredibly detailed list of minor design tweaks that tightened things up and got things ready for final delivery to be implemented into their WordPress backend by the fine folks at 10up (who by the way were involved throughout the course of this process).

“Final delivery” and “were involved throughout” are two phrases that don’t sit very well together, so I wonder how that worked practically.

Don’t get me wrong — this is a great process, and they obviously got some impressive results. These are just some things I wondered about as I read through the case study.

Demanding slower development cycles for apps

Now!

Daniel Jalkut discusses the rate of software/app updates in Stagnation Or Stability?:

As an onlooker, it’s easy to associate dramatic change and motion with competence, and quiet refinement with laziness. We must draw on our own experiences attempting to build great things to appreciate how much work takes place in stillness, to have faith that even though things may appear stagnant, a benefit of frictionlessness is resulting. An app at rest may be in that long, arduous phase of becoming finely crafted.

Daniel’s post is a response to the recent Michael Lopp article R.I.P. Things, in which he explains that he’s dropping Things as his productivity app mainly because of its lack of updates. I’ve been thinking about this a lot. How our expectations about app pricing and rate of change is placing unfair (and damaging) pressure on developers to release new versions of their apps constantly — even if it’s just change for the sake of change.

The other unintended consequence of this never-ending update cycle is that we’re starting to see evidence of what Chris Bowler calls App Fatigue:

I must admit, I’ve felt a bit of what I term app fatigue in the past year. What is this? Simply the lack of desire to either a) pay for another version of an app I already own or b) go through the steps required to update this app and become accustomed to the changes.

My own feelings about this remain wildly erratic at the moment. Sometimes I’m on Michael’s side. Like most people I was champing at the bit for Tweetbot 3, and as much as I appreciated the “It’ll be ready when it’s ready” line, my impatience got the better of me. Yesterday Apple “finally” updated their last built-in app for iOS 7. But we’re still stuck with an ugly WhatsApp, orphaned versions of OmniFocus, Tweetbot and Instapaper for iPad, and a Foursquare that hasn’t been updated in weeks — weeks, I tell you. What up with that? I turned off automatic app updates because I love going to the App Store and checking what wonderful new things I’m going to get today.

And then, at other times, I’m with Chris Bowler. OmniFocus runs my life, so I shouldn’t complain about paying $20 for the gorgeous new iPhone version, but it ended up being quite the grudge purchase. Same with Fantastical 2. And I know that my insatiable hunger for new features every day is probably doing more damage than good. Because Daniel is right: “An app at rest may be in that long, arduous phase of becoming finely crafted.” But if we show up at developers’ doors with pitchforks every couple of weeks, demanding our new features, there is no time for the app to be at rest. Eventually, Experience Rot will set in, and it will be our fault:

As more features are added, it becomes harder to make the overall design coherent and sensical. Soon features are crammed into corners that don’t make sense.

I guess I’m preaching to myself here. I’m hoping to convince myself to be a bit more patient with app developers, and give them the time they need to slow down and refine.

The positive side of skeuomorphism

From Jared Sinclair’s excellent “Form Follows Function” Is More Complicated Than iOS 7 Thinks, in which he explains why some of the skeuomorphic elements of iOS 1-6 were actually useful:

On iOS, putting function before form is not as simple as paring down icons to a strict grid and color palette. There are functions beyond literal communication that iOS designers must balance. Making icons warm and inviting serves many deeper purposes. It builds your confidence in the device. It makes you feel in control. It sets your mind and thumbs at ease. It communicates through feeling and memory, and when done well, resonates with human experience in a way that PCs never could.

There have been a few other defences of appropriate skeuomorphic elements recently. From Kevin Suttle’s Frame of Reference:

There has been quite a bit of confusion over what skeuomorphism is. Many define it as “creating digital products or interfaces that resemble their physical counterparts”. The goal of skeuomorphic style was to leverage our pre-existing affordances and lend a healthy amount of familiarity and confidence to digital interfaces.

And from Dan Wineman’s must-read Look, and Feel:

Affordances are the baby to skeuomorphism’s bathwater. When they engage our instincts just right, they create an emotional bond, and the unfamiliar becomes inviting. Without them, it’s just pictures under glass. It makes no difference how flat, how deep, how minimal, or how ornate the look-and-feel is if it can’t show us, when we look, how to feel.

So, as it turns out, good design is (still) all about affordance.

Twitter and the design constraints of the advertising revenue model

Dan Frommer weighs in with a positive view of Twitter’s more visual timeline in The Best Part Of Twitter’s New Design Is That It’s Experimenting In Public:

Love or hate Twitter’s new design features — I like the in-line photo and video previews, but the reply/fav/retweet icons under every tweet feel a little too noisy — they say one great thing about Twitter: That it’s not afraid to experiment boldly in public. […]

Remember: Twitter’s goal is to maintain its independence, and soon become a large, profitable, public media company. If Twitter can try new things — in public — that make its service easier to understand, easier to use, easier to monetize, and easier to grow, that’s a big victory for the company and its users.

The key point in Frommer’s analysis is what Twitter has become: a media company that makes money through advertising. This means that there needs to be a way to show ads more prominently, so that they can charge more for those ads. That places very specific constraints on how the product can be designed. If ads need more clicks, ads need more prominence. One way to give ads more prominence is to make them take over a larger part of the screen. So Twitter is testing one way of accomplishing that with their “more visual timeline”.

Of course, brands figured out pretty quickly that they can take up more of the screen if they add a photo to their links:

Twitter ads

Contrast that with Tweetbot’s view of the same Co.Design tweet (and others):

Twitter ads

I think what we’re forgetting is that Twitter has chosen their path. Sorry for repeating myself, but they’ve become a media company that makes money through advertising. For the foreseeable future, all product decisions will reflect that. This is where I disagree with Frommer. I don’t think this change makes the service easier to understand and easier to use. It does, however, make it easier to monetize, and easier to grow.

The bottom line is this. Don’t think for a minute that Twitter doesn’t realize that inline images hurt the user experience by reducing the scanability of tweets. Of course they know. But they don’t have a choice. They are now operating within the design constraints of the company they have chosen to become. If you don’t like it, buy Tweetbot before they hit their API limit.

Comment on Google+

Twitter as an Argument Machine

Derek Powazek makes the case that Twitter is an Argument Machine:

I’m not saying that Twitter was designed to create arguments. I’m just saying that, if you set out to create an Argument Machine, it’d come out looking a lot like Twitter.

He also makes some interesting suggestions for how Twitter could be designed differently to prevent arguments from getting out of control. This does remind me of something I observed a while ago after getting mauled by the Argument Machine…

I’m pretty sure no one emerges at the other side of a Twitter debate going, “Man, I’m really glad I did that.”

— Rian van der Merwe (@RianVDM) February 7, 2013