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)

Jason Fried, co-founder of 37signals, in an interview with The Great Discontent:

People should consider the value of a long-term investment in something. Can you make your idea your life’s work instead of your life’s work being 30 ideas?

I’m more of a fan of constant, steady growth because it feels more sustainable over a long period of time. Creating things that are lasting is what great cultures do. […] What are we creating today that’s going to last for 20, 50, or 100 years? I like to think about that and I’d love to have more people think that way rather than thinking about what they can do for two years until they get bought out.

This is such a good point. We just don’t think about building things that last any more, because that takes time, and we’re not exactly known for our patience. Tangentially related, the recent Radiolab episode called “Speed” is absolutely brilliant — you have to listen to it.

Also see: The elusive goal of lasting beauty in web design.

Nick Bilton in Disruptions: Even the Tech Elites Leave Gadgets Behind, an article on the growing (not just hipster any more?) trend to step away from technology every once in a while:

As every aspect of our daily lives has become hyperconnected, some people on the cutting edge of tech are trying their best to push it back a few feet. Keeping their phone in their pocket. Turning off their home Wi-Fi at night or on weekends. And reading books on paper, rather than pixels.

The “phone stack” is becoming increasingly popular as a way to force people to talk to each other over dinner. Sad, but necessary.

Photo credit: Roo Reynolds on Flickr

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.

In Where the Happy Talk About Corporate Culture Is Wrong Cliff Oxford makes the case that there is big difference between Human Resources Happy and High Performance Happy in organizations:

Here’s how I define H.R. Happy: Bosses are at least superficially nice and periodically pretend to be interested in employees as people. These employees can count on birthday-cake celebrations and shallow conversations about what their hobbies are outside of work. This approach allows H.R. people to do the job they love — compliance and regulations — instead of the job they should be doing — finding and recruiting the best available talent.

And the flipside:

High Performance Happy is an attitude with a skill set that says we are on a mission that is bigger than any one of us. We find our happiness in being on a world class team that is making a difference.

I don’t agree with all of Cliff’s advice on how to foster cultures of High Performance Happiness, but the distinction is certainly spot-on. As for how to get to a culture like that, I still think Jocelyn Glei has one of the best summaries in her article What Motivates Us To Do Great Work?:

For creative thinkers, [author Daniel Pink] identifies three key motivators: autonomy (self-directed work), mastery (getting better at stuff), and purpose (serving a greater vision). […]

As creative thinkers, we want to make progress, and we want to move big ideas forward. So, it’s no surprise that the best motivator is being empowered to take action. […] In short, give your team members what they need to thrive, and then get out of the way.

(link via Marcelo Somers)

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.

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 project¹.

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.