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.

Jordan Moore wrote a very level-headed post about giving users the ability to switch off the breakpoints of a responsive design to show the “desktop” site1 instead. From Claustrophobia:

This is my overriding concern — there’s no way out. There’s no way out of a bad design, an incompatible plugin, a browser bug, missing content, the endless list of potential issues someone could potentially encounter with a website whether it is responsive or not.

That’s an excellent point, and providing a “way out” echoes one of Nielsen’s 10 Heuristics for User Interface Design, written in 1995:

User control and freedom. Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.

Jordan argues that giving users that control and freedom on a responsive site might feel like a cop-out, but it could be necessary:

The last thing I want is to lead users into a mass exodus from a responsive design I have put so much thought and effort into. I just think if it helps the odd user out in doing something they happen to find more comfortable in a pinch and zoom environment for whatever reason then we should probably do it rather than prevent them from doing it.

That’s a very sane, user-centered approach. It’s also worth noting that if the mass exodus does occur, it’s a clear sign that something is wrong with the responsive site. That’s valuable data.

But it all comes down to execution, of course. Users shouldn’t be asked to choose between entering the building or going straight for the emergency exit the minute they arrive at the site. It’s ok to make the exit visible, but forcing a deliberate, upfront choice between the mobile/responsive site and the desktop site puts an unnecessary burden on users.

In short, this kind of placement is ok (although the “Full Site” language is problematic):

This is not ok:

---

1. Whatever that means these days… ↩

Flipboard 2.0 was just released for iOS, and with it came a feature called Flipboard Magazines. From the blog post announcing the new version:

For the first time, you can collect and save articles, photos, audio and video by organizing them into beautiful magazines. These can be private, or if you want to connect with like-minded enthusiasts, you can make them public and share them on Flipboard and beyond. Now everyone can be a reader and an editor.

I’ve been playing around with this feature a bit, and I like it so far. It’s definitely an early release, so there are a few things missing. For example, you can’t edit the title of an article you’re adding to a Magazine, and you also can’t move articles around to be in a different order. But I’m sure those features will come. For now, it’s a great way to organize1 content — and the timing is particularly good with the impending demise of Google Reader.

I’ve created two magazines so far, which you’re welcome to follow on Flipboard. UX Design is all about design and related disciplines. Technology and us desperately needs a less cheesy name, but it’s a collection of articles about the various ways technology impacts our lives.

Enjoy!

---

1. We’re all so desperately trying to avoid using the word “curate” since Matt and Marco spoke out about it, but that’s really what this is. Anyway, I’ll stick with “organize” so as not to offend anyone’s Internet sensibilities. ↩

In The Next Big UI Idea: Gadgets That Adapt To Your Skill Philip Battin applies some existing ideas around progressive disclosure and Flow to tech gadgets:

User experiences are subjective and dynamic, but by and large, interactive products are not designed to take people’s changing capacity and experience into account. But they could. Here, I present a model for how designers can use the fundamentals of video games and the psychological principles of flow to design enhanced user experiences.

Philip proceeds with an example of how such a model could work for a Samsung E8005 SmartTV. We’ve applied these principles in traditional software design for a long time, but it’s interesting to think about how it could be used to improve the design of physical gadgets.

Our beloved industry is pretty wary of buzz words. And by “our industry” I mean User Experience Designers — although we can’t even agree on what to call ourselves, so that’s another problem, I guess. Anyway. Debates over terms like skeuomorphism, flat design, and “No UI” have given us a strong skepticism for fancy words. That’s mostly refreshing, but it can also be a handicap if we end up dismissing valuable ideas because we don’t like the terms that describe those ideas.

I would argue that the term Lean UX fits into this last category. It’s easy to dismiss as just another bandwagon fad, but now that I’ve read through Jeff Gothelf and Josh Seiden’s Lean UX: Applying Lean Principles to Improve User Experience I believe that it’s a valuable framework to help us understand where the UX industry is headed — and how to do our jobs better.

Whether you want to call the theory and techniques discussed in this book “Lean” or just “How we work” doesn’t matter as much, in my opinion. What is important is that we understand the benefits of moving towards a more iterative, outcomes-based design approach, while letting go of some our reliance on classic design deliverables. In the introduction to the book, the authors sum up the main reason for this proposed change in design approach:

But the fault is not with the designers, or the engineers, or even the executives. The problem is the systems we use to build companies. We are still building linear organizations in a world that demands constant change. We are still building silos in a world that demands thorough collaboration. And we are still investing in analysis, arguing over specifications, and efficiently producing deliverables in a world that demands continuous experimentation in order to achieve continuous innovation.

The book then describes how to build better products through real collaboration. I say real because Jeff and Josh don’t just say, “you should work together!” They detail a number of practical techniques for working together better, as well as case studies to show how it works in real-world situations. And underlying all of this are the three principles of what they define as Lean UX:

• Removing waste from the design process to move away from heavily documented handoffs to a process that creates only the design artifacts needed to move the team’s learning forward.
• Improving the efficiency of the “system” of designers, developers, product managers, quality assurance engineers, marketers, and others in a transparent, cross-functional collaboration that brings nondesigners into the design process.
• Shifting mindsets away from relying on “hero designers” to divine the best solution from a single point of view, in favor of using rapid experimentation and measurement to learn quickly how well (or not) ideas meet the company’s goals.

Some UX designers will read this book and say that this is how they’ve always worked. That might be true — it’s true for our agency as well, to some extent. But I still found it extremely helpful to have a concrete framework for the work we do, combined with solid reasoning about the benefits of this approach. I also picked up some great execution ideas for techniques we use already — like persona templates and design studio facilitation.

The only part of the book that might be a bit controversial is the discussion of how Lean UX fits into Agile development. Jeff and Josh argue that the long-accepted idea of Sprint 0 or Staggered Sprints (making sure that design is always a sprint ahead of development) doesn’t work long-term:

However, this model works best as a transition. It is not where you want your team to end up. Here’s why: it becomes very easy to create a situation in which the entire team is never working on the same thing at the same time. You never realize the benefits of cross-functional collaboration because the different disciplines are focused on different things. Without that collaboration, you don’t build shared understanding, so you end up relying heavily on documentation and handoffs for communication.

They propose a very interesting alternative that makes a lot of sense (I won’t spoil it for you), but some of the concerns I’ve raised before about Agile UX remains. I’m not sure if any Agile UX techniques allow for enough leeway to test/research different variations of a product idea, or if it just streamlines the iteration process to get you to a local maximum faster.

In summary, Lean UX is a great overview of what an effective UX process should look like. There’s a good balance between theory, practical advice, and case studies. This makes it a valuable resource for those new to the field, but it also gives experienced UX practitioners a framework to structure and communicate the work they do every day. Highly recommended.

Buy Lean UX on Amazon.

Mark Boulton wrote a forceful counter-argument to the common mantra that collaboration results in better design. From Quietly working:

I see plenty of banner waving for collaborative working. Co-designing, pair programming, brainstorming, collaborative workshops. The overwhelming message is that these tools are better for reaching consensus, sharing work, and, ultimately, lead to better work. Well, I’m not so sure that’s the truth. Given my introverted nature, sometimes these activities can rush the process too much. They allow no time for me to think. […]

Personally speaking, a lot of the time, I’d rather listen to what you have to say and go and have a good think.

Mark makes some very good points, and as an introvert myself, his message really resonates with me. But I don’t think it’s an either/or situation. It’s not that we either collaborate, or work alone. Collaboration that doesn’t allow time and space for working alone is ineffective collaboration.

There are two illustrations about the collaboration process that summarize this idea well. The first is from Trent Walton’s Being Prepared To Contribute:

An idea, followed by discussion, often results in better ideas. But the “Better idea” step doesn’t happen in a meeting room — it happens at the designer’s desk, when they have time to reflect and focus on the problem without interruption.

The second illustration is from Stefan Klocek’s excellent post Better together; the practice of successful creative collaboration:

It shows how collaboration doesn’t mean that everyone should do everything together. Important decisions are made together, but the production details (the “better ideas”) happen while working alone.

So I’m definitely with Mark on his call for having more time to think and work alone. But that isn’t an alternative to collaborative working. It’s just a necessary — and too often ignored — part of the collaboration process.

(link via @ChrisFerdinandi)

Jared Spool looks at different redesign strategies in Extraordinarily Radical Redesign Strategies. Whenever time and budget allow it, I believe the “realign” strategy — what Jared calls “The Glacial-Speed Approach” — works best. This strategy relies on continuous, incremental change to reach your site goals:

The beauty of making small changes means that you never have high risk. A menu item here, a new form field there. Slowly the interface morphs, and if you make a mistake, well, you change it back.

But here’s the kicker — the reality that makes most product teams opt for a different strategy:

This type of redesign takes patience. It also takes humility, especially from those organizations who think people want to hear that they’ve made it better. Unfortunately, to most people, those proclamations sound like the web equivalent of “Our menus have changed so please listen carefully.”

To pull this off, the team needs a solid vision of where the design should eventually go. Then, one small change at a time, they start. Make the change and watch what happens, proceeding slowly to the next. The team will know it’s succeeded when they hear a user insist that a new addition has been in the design all along.

Patience isn’t a word most people would use to describe their leadership teams when it comes to site redesigns. But the reality is that most other strategies involve much higher risks than the internal frustration of waiting a few extra months using the realignment approach. Risks like losing the majority of your customer base to a competitor (as Digg found out the hard way).

Read Jared’s article for a good overview of the pros and cons of different redesign strategies.

Frank Chimero talks about the misuse of the word “timeless” as it relates to design in Let’s talk about timeless design. Here’s one of his complaints:

Why is timeless design always the goal? What’s wrong with making something look like it was made when it was made? Why do designers all of a sudden want to exist outside of time, like Scott Bakula in Quantum Leap? […]

Other people: can you help me understand what is happening in this world of ours? I want to know what technology is doing to my brain. How do I stay human in a digital world? I want to understand what all this technology does to my expectations of myself, other people, and the world. None of this is timeless. These problems are right now.

I agree with Frank on this point (and the others), so it’s a little embarrassing to admit that I wrote in favour of timeless design about a year ago in The elusive goal of lasting beauty in web design. But having just read that post again, and in keeping with Frank’s point that words matter, I think it’s important to make a distinction between design that is timeless and design that lasts. I concluded my piece with the following:

I wonder what would happen if we felt the weight of responsibility a little more when we’re designing. What if we go into each project as if the design will be around for 100 years or more? Would we make it fit into the web environment better, aim to give it a timeless aesthetic, and spend more time considering the consequences of our design decisions? Would we try to design something that “makes life worth living”?

Sure, I use the word “timeless” there (probably incorrectly), but the point I’m trying to make is slightly different. I’m trying to say that the ephemeral and fickle nature of digital products shouldn’t be used as an excuse to put out unconsidered, throwaway work. Our designs don’t have to be timeless — and they should solve the problems we have now — but we should go into each project with the care and attention needed to make things last for a long time.

In A More Flexible Workflow Dennis Kardys describes an all-too-familiar design process problem in agencies:

In theory the design assembly line made us extremely efficient. Design documents were handed off like batons from one team member to the next as projects moved through stages. The reality however, is that projects would often get held up as clients mulled over wireframes or fought for consensus within their organization. […] In a nutshell, there was too much talking and too little testing.

Dennis goes on to describe how they’ve successfully changed their workflow to incorporate interactive prototypes and frequent customer feedback. These aren’t new ideas, of course, but it’s great to see it from an agency perspective, where these flexible workflows can be much harder to implement.

Sticking with the design process theme, Tuhin Kumar wrote a good post about matching the type of critique a project requires to the design phase that project is currently in. From Feedback & Fidelity in Design:

Momentum is one of the best things for any product design process. It helps you from straying around the wrong path, or losing your core vision, or trying to solve too many things in the first release. […] Asking the wrong questions at the wrong fidelity or giving the wrong feedback kills momentum like nothing else.

Tuhin defines some different phases of the design process, and recommends the right questions to ask during each. Both these articles give some great tips to improve your design workflow.

Frank Chimero has a great follow-up to Tino Arnall’s excellent post No to NoUI. In The Cloud is Heavy and Design Isn’t Invisible Frank explores what’s appropriate (and what’s not) about using “The Cloud” as a metaphor, and then he makes a great point about the Invisible Design trend:

Sometimes I wonder if the desire to obfuscate production and make the resulting design invisible or seamless to users diminishes their appreciation for the craft of building systems. I think there’s a strong likelihood that metaphors like “The Cloud” and sayings like “It Just Works™” reduce a user’s appreciation of the software/hardware they are using. “Magic” is a great word for selling product, but it also can cheapen all the sweat it takes to get there. If the seams have been covered, you can’t admire how things connect.

I completely agree with Frank on this. As I’ve mentioned before, I think our goal shouldn’t be NoUI (or YesUI or AlwaysUI or whatever we want to label the other extreme). Our goal should be appropriate visibility.