Baruch Sachs makes some good points in Part 1 of a series called Practicing Great UX Consulting:

You are not there to educate people. You are there to advise your client and guide the creation of an amazing user experience. You are the expert; that’s why they brought you in. Collaboration and openness are key here. People need to feel invested, not put upon.

I agree that collaboration is key — the problem comes when collaboration gets confused with consensus. Consensus cultures often produce watered down, unexciting products. Products where endless rounds of give-and-take have worn down the original idea to a shadow of what it once was. Consensus cultures also wear down the teams working on the product, because no one really gets what they want, they just get some of it.

Collaboration is different. In collaboration cultures people understand that even though everyone gets a voice, not everyone gets to decide. People are able to voice their opinions, argue passionately for how they believe things should be done, and try to negotiate compromises. But it certainly doesn’t mean that everyone has to agree with every decision. And that’s why the client/agency trust relationship is so crucial.

One great collaboration technique that works well with clients is called Design Studio. Jared Spool has a great write-up of how to conduct a Design Studio worskhop, and it’s also worth reading Paul Boag’s thoughts in Never wireframe alone.

Luke Wroblewski explains why those overlay introductory “tour” screens you often see in apps is such a bad idea in Designing for real world mobile use:

These issues stem from the fact that introductory tours show up before you ever get a chance to use an application. Most people are eager to jump right in and as a result, they skip reading the manual. The ones that do read haven’t seen the interface yet so they don’t have any sense of where and how the tips they’re learning will apply.

I completely agree, and have written about this before in Best practices for user onboarding on mobile touchscreen applications, where I give three guidelines for app onboarding:

• Make sure that users have familiarized themselves enough with your app to have the correct mental model before you start teaching them how to use it.
• Show users only the information they need to take the immediate next step(s) for using the application.
• Make sure users have a clear link between the information you give them and how to access/use that information in their everyday use of the app.

Within a week, two articles came out about resisting the urge to add new features quickly after a product is launched. First, Julie Zhuo makes the case for slow, small launches with clear “sunset” criteria in The tax of new, because of the inherent cost of maintaining and improving new features:

The tax that comes with introducing any new feature into your product is high. I cannot stress this enough. Sure, maybe the new feature isn’t hard to build, maybe it only takes a couple days and a handful of people, maybe it can be shipped and delivered by next week. And maybe the additional cognitive load for a user isn’t high — it’s just an extra icon here, after all, or an extra slot in a menu there. But once your new feature is out there, it’s out there. A real thing used by real people.

Jared Spool then wrote Experience Rot, focusing more on the UX and technical debt issues introduced by new features:

The moment a new feature is added — one that wasn’t considered in the initial design — the rot starts to take hold. It’s at this moment that a rethinking of the design has to happen and the seeds of complexity are laid.

If that new feature is close in style and function to the original set of features, the experience rot may not be visible. Yet, because it needs to be retrofit into the original design, it starts down the inevitable road.

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.

It’s interesting to hear the same conclusion drawn from different perspective, so it’s worth reading both articles.

Fracture prints your photos in vivid color directly on glass. It’s picture, frame & mount, all in one.

It’s a modern, elegant and affordable way to print and display your favorite memories. Your print comes with everything you need to display your photo, right in the durable packaging.

Fractures come in a variety of sizes and prices, starting at just $12, with free shipping on orders of $100 or more.

Fracture prints make great Father’s Day gifts and are the perfect way to fill up empty walls in your new home or apartment. Check it out.

Sponsorship by The Syndicate.

John Pavlus wrote a great piece about the phrase “intuitive interfaces”, and comes to the following conclusion in I’m Boycotting “Intuitive” Interfaces:

I think what we all want from technology are interfaces and interactions that feel familiar, legible, and evident. They should teach us in ways we would like to learn, and speak to us in a way we can understand. This doesn’t mean that technology ought never to surprise or challenge us. But desperately seeking “intuitive” feels, to me, like a kind of techno-animism. Interfaces aren’t magic, and we don’t really want them to be. To borrow from Timo Arnall: interfaces are culture. And like any pieces of culture, what they ought to do is simple: they ought to connect.

Lucas Rocha talks about the importance of designers and developers working closely together in Mind the Gap:

Iterative design processes that engage designers and engineers very early tend to result in higher UI quality because it provides the necessary flexibility and agility to steer ideas as they are implemented. Sounds obvious but this is much easier said than done. Just see how rare is to find products with outstanding user interfaces.

This is very true, and the power of small, collaborative teams have been proven time and again. But it’s important to take this further. It’s not just about collaboration, it’s also about empathy. If designers and developers collaborate but they don’t understand each other, you’ll still get nowhere.

The main issue is that designers and developers approach their respective crafts from very different perspectives. Design is about composition — how to put things together so that the whole makes sense. Development is about deconstruction — how to break down the whole into pieces that can be implemented effectively. That creates a disconnect that is difficult to overcome if their isn’t empathy between the two groups.

Thomas Petersen describes the ideal situation really well in Developers are from Mars, Designers from Venus:

They are the developers who can design enough to appreciate what good design can do for their product even if it sometimes means having to deviate from the framework and put a little extra effort into customizing certain functionality. […]

And they are the designers who learn how to think like a programmer when they design and develop an aesthetic that is better suited for deconstruction rather than composition.

So, it’s not just about meeting more often. It’s also about meeting in the middle to accomplish a common goal together.

PS. All of this reminds me of this matrix on how designers, developers, and project managers see themselves and each other in most organizations:

Image source: Les développeurs, graphistes et chefs de projets

Liat Ben-Zur wrote a great post for AllThingsD called Connecting Things to the Internet Does Not an Internet of Things Make. His main issue with the current crop of connected devices is lack of cross-platform integration:

Each specific device seems to connect to its particular cloud service. There isn’t really one cloud. Every manufacturer has their own cloud service, and often these clouds are closed, proprietary environments. Devices that live in their own siloed cloud cannot speak to one another, meaning they cannot benefit from the data, context or control of nearby IoT devices. That is why we currently need a separate app to control — and interface with — each connected thing we buy. This may be acceptable in the near term, but it cannot scale.

This made me think of Ian Bach’s article Designing Connected Products:

What’s more, when it comes to creating a smooth connected experience, focusing on the ‘things’ from the start can actually be somewhat of a decoy. Spend some time with any service or product that relies on data jumping from place to place and you’ll quickly realise it’s in the ‘gaps’ between things that design really matters. Problem is, gaps are easy to overlook, incredibly tough to design for and much less sexy than the ‘things’.

Image source: Ian Bach

Ian comes from a different angle, but I think these points are related. Cloud services connect the ‘gaps’ between things, but it’s incredibly hard to fill the gaps well, so most companies keep their solutions proprietary since they see it as a competitive advantage. And that’s why we’re in the situation we’re in: great physical products with reasonably ok cloud services, but because the services don’t talk to each other the products aren’t nearly as useful as they could be.

(First link via @kbaxter)

Mad Mimi is a design-oriented email newsletter service founded in 2008. Developed to provide a mobile-app-like feel, and with a drag-and-drop email composer, Mad Mimi offers a simple, elegant user experience that helps customers create, send, and track beautiful html email campaigns.

Mad Mimi also offers robust APIs, integrations, and add-on features. This makes it a perfect fit for today’s visionaries, artists, and entrepreneurs, including great digital brands like Fancy and StumbleUpon, who use Mad Mimi to communicate with their customers.

Best yet, Mad Mimi is free for up to 2,500 contacts. We hope you’ll give us a try or email us with questions.

Sponsorship by The Syndicate.

Granted, the skeuomorphism vs. flat design debate (a false dichotomy anyway) is getting a bit old. But it’s worth reading Matt Gemmell’s take in Tail wagging, because he makes some great points about what makes for good interface design. Like this one:

Our tastes, and capabilities, have moved a bit beyond screamingly-obvious knobs and dials. We don’t need drop-shadows to encourage us to poke at something. All we need is an invitation, in the form of icons or labels or animations which imply functionality, and a consistency of presentation which allows us to make a good guess about what we can interact with.

After all these years, proper affordance remains the bedrock of good design.

About a year ago Cennydd Bowles wrote a very good article called A changing tide, in which he thought out loud about the trend of high-profile agency designers joining internal product teams. One of his hypotheses was this:

A great agency is still a strong asset to the industry and its clients, just as a bad agency is still harmful – and there are undoubtedly counter-examples to my evidence. However, one thing is clear: the design industry’s focus is no longer on agencies. It is on products.

He goes further to conclude:

A lot’s been written about the alleged decline of client services, and plenty of people are now rushing to its defence. As always, “it depends” is the only reliable answer; context is the key factor in deciding whether to work for, or hire, external consultants. But I do wonder how the agency world will respond to this shifting community focus. How will they manage to stay an attractive option for designers and organisations who are increasingly internally-focused?

My reason for bringing this up is not to re-ignite the debate over the value of client services. I’ve worked on both sides of the fence. I’m currently on the agency side, but I don’t think I’ll do that for the rest of my career. I think agency-side and product-side design roles stretch one’s skills in different ways, so there’s huge value in both. There are also big downsides to each, of course (for example, product-side can become monotonous, while agency-side can become frustrating when work doesn’t go live).

What I’d like to talk about, instead, is why it suddenly feels like some product-side designers look down on agency designers, as if we’re the body boarders to their cool surfer personas. Here’s David Cole in The Rise of Product Design:

Increasingly the best designers of our time are not working for agencies, but for in-house teams at startups and tech companies. I think this is an important shift, not just for where the work is done, but how the work is done.

Looking back at the ideas espoused by the UX community, I find their relevance to my work winnowing by the year. Many of the practices seem forged in the fires of consultancy.

And here’s Tuhin Kumar in What kind of a designer are you?:

It is not the biggest surprise that some of the finest designers of products happen to work at tech companies and startups. I would argue that a startup or a larger tech company that cares deeply about design (I can definitely attest for Facebook being one) is a better place to bootstrap your career in design than any traditional design agency. There are lot of reasons for this but the biggest and most obvious ones in my head are the breadth of projects and the quick learning curve.

That last sentence is a head-scratcher. I don’t see how one can argue that a designer at an agency doesn’t get much variety. I come from an e-commerce background, but through my agency work I’ve had the privilege of gaining experience in financial services, mobile technologies, and a wide range of consumer products. Plenty of breadth there.

But again, that’s a side note. What I’m confused about is the tone. The subtext that agency designers are not the “best” or “finest” designers. I keep coming back to Cennydd’s article from a year ago, because I think he’s right: there’s been a shift from agency to products. That’s fine (I’ll say it again: I love the product-side and will probably end up there again some day). But we need to be careful about downplaying the role of agencies, and how agencies work.

The other subtext in all these recent posts is that deliverables are for amateurs — real designers create prototypes and ship products. That is absolutely true, and if you’ve found a company like that, more power to you. But it is simply not how the world works for everyone. I’ve said this before, but to make a blanket statement that deliverables are unnecessary ignores the mountain of organizational challenges that need to be overcome in some companies to build useful, usable products. And sure, I’m defending the agency side forcefully here, but I guarantee you that without real deliverables, we wouldn’t get anywhere in some organizations.

Does it make our role less desirable that we have to spend a bit of extra time on “non-design” activities? To those who have found their homes in design-centered companies, yes, definitely. But does it make us second-class citizens in the industry? Yeah, I don’t think so. I’m going to throw it out there that without agencies, we wouldn’t have been in a situation where tons of companies now get the value of design, and therefore fork out tons of cash to make sure they have kick-ass internal design teams. And it’s a pretty awesome feeling when you see that shift happening in an organization, knowing that you’ve had some small hand in it.

So all I’m saying is let’s recognize the inherent value in both sides of the industry, because we all have the same goal: to create great products that delight users and make businesses successful. We’re all in this together.