In what still feels like a dream that I’ll someday wake up from, I’ve been extremely privileged to become a contributor to Smashing Magazine. I haven’t written about it here before because I’m not really a fan of meta posts, and like I said, I’m still waiting to wake up and discover that it’s not real. But I do want to express a few thoughts on the experience so far, and acknowledge some of the people who make the magazine happen behind the scenes.

The opportunity to write for Smashing Magazine fell in my lap out of nowhere. One of my favorite designers and writers, Francisco Inchauste, contacted me out of the blue after reading some of my articles here on Elezea, and asked if I’d be interested in contributing to a new UX area on Smashing that he was starting up. I tried to play it cool, but really, how is that even a question? Of course I jumped on the opportunity, and so far it’s been a fantastic learning experience.

I am extremely impressed by the editing process at Smashing Magazine. It not only results in great content on the site, but it provides extremely valuable feedback to writers to help us get better at it. The first step is usually a discussion between Francisco and I about the idea for the article, followed by 2-3 drafts that he gives feedback on. Once Francisco is happy with the draft, each article goes through two blind reviews by people in the industry who are usually experts in the topic you’re writing about.

The feedback that comes from Francisco and the team of reviewers is always smart and constructive, and results in better articles across the board. To be honest, I feel like I get more out of the process than Smashing does. I get to hone my writing skills - all they’re getting is an article! But hey, as long as they’re ok with that deal, I’ll take it.

So, on to a brief summary of what I’ve written about so far, and some of the things I’ve been thinking about for the future. In my first two articles (part 1, part 2) I talked about the organizational challenges of doing user experience in large organizations, and how we can work better together. In The Data-Pixel Approach To Improving User Experience I shifted gears and applied some of Edward Tufte’s data visualization principles to web design.

I am currently very interested in the connection between architecture and web design. I’m trying to read up on architecture as much as I can, and I continue to be struck by the similarities between the history of architecture and the current arc of web design. In Designer Myopia: How To Stop Designing For Ourselves I tried to scratch the surface of that, but there’s still so much more to be said. I really believe that the history of architecture can tell us a lot about the future of web design, and I hope to explore some of that in upcoming articles.

My next article cued for publishing is also the first one inspired by my 2-year old daughter, so I’m particularly excited about seeing that one come out. I want to thank Francisco, Vitaly, and the entire Smashing Magazine team for giving me the opportunity to write for such a great publication, and making me feel part of the Design community that sustains me every day.

I can only imagine the miles and miles of chaotic complexity that designers and developers had to wade through to arrive at the simplicity of Clear - a new To Do list app for the iPhone. As I started playing with the app, Rebekah Cox’s definition of design kept popping into my head:

Design is a set of decisions about a product. It’s not an interface or an aesthetic, it’s not a brand or a color. Design is the actual decisions.

And the decisions that Clear made are as close to perfect as I’ve ever seen. I can picture the endless, difficult meetings and arguments that must have happened to decide what features to include in the app. Should we have Projects and Contexts? No. How about Due Dates and Filters? Nope. Well, why not!? Because Clear is a prioritized list of tasks that is fast and easy to edit. That’s it. Nothing less, nothing more.

It reminds me of the Quora thread on why Dropbox became so popular:

“But,” you may ask, “so much more you could do! What about task management, calendaring, customized dashboards, virtual white boarding. More than just folders and files!”

No, shut up. People don’t use that crap. They just want a folder. A folder that syncs.

But let me stop gushing for a minute and step back a bit. Clear (which is getting quite a bit of attention) is absolutely fantastic as a way to view and prioritize a simple list of tasks, but it’s not a replacement for hardcore task management systems. Omnifocus will remain the application I use for all my work projects, and it’s always open on my Mac and iPad during the work day. But Omnifocus is hopeless overkill for simple tasks like “Make a car appointment” or “Get coffee at the store”. And that is the gap that Clear fills so effectively.

Clear is focused on two things that make it vastly superior to other similar apps:

• Speed. It’s really fast. When it starts up you can instantly start typing. This is crucial to quickly capture that all-important thing you don’t want to forget. I still die a little bit inside every time I see the “Optimizing database” message while I wait for Omnifocus to start up.
• Effortless editing. It’s completely gesture-based - no chrome, no fluff, no fancy visual design. You tap, you type, you swipe, you close. These gestures are easy to learn and intuitive:

Francisco Inchauste calls Clear “an app for the future”, and I completely agree. It feels different, but it feels right. And despite its (appropriate) lack of visual extravagance, it has an attention to detail that reminds of the meticulous design of Path. For example, when you create a new list and there are no to do items in it yet, you get a random quote about getting things done:

I’m trying hard to find something negative to say about Clear, because every app has room for improvement. But at the moment my judgment is slightly clouded by how impressed I am with this team. It’s so hard to resist the temptation to build an app that tries to solve every problem for every person in the world. These guys walked through that fire and emerged on the other side probably bruised and battered, but also with a flawless app for listing tasks and editing them quickly. Want more in your To Do list app? Shut up and go buy Omnifocus.

I flew up to Joburg this weekend to speak at one of the World IA Day events that were happening in 14 cities around the world. The bulk of the talk was about Customer Journey Maps, and specifically how we used the technique to help us prioritize our roadmap at kalahari.com. In this summary post I want to focus primarily on the topic I started the talk with. It’s about a particular gap I see in current UX work, and how Information Architecture is uniquely positioned to bridge this gap.

In 1955 David Ogilvey wrote a letter about his copywriting habits, and among other things, said the following about campaign work:

I write out a definition of the problem and a statement of the purpose which I wish the campaign to achieve. Then I go no further until the statement and its principles have been accepted by the client.

It seems that ther’s unfortunately plenty of UX work out there that jumps straight into wireframes without first understanding the design problem, as well as the purpose of the solution. Purpose - the reason for which something is done or created - often appears to be missing (*cough* Color.com *cough*). And this is where I believe Information Architecture can come to the rescue.

There are plenty of definitions of IA to choose from, but I like this one in particular by Peter Morville:

I’m an information architect. I map paths and places across physical, digital, and cognitive spaces. #ias10 #iasw

”” Peter Morville (@morville) April 15, 2010

I like it because it brings into focus the idea that at its core, Information Architecture is about a unique way of seeing the world. A way that is essential to build successful user experiences.

I love the example Dan Klyn’s uses in Information Architecture is a Way of Seeing. You have to read the whole thing to appreciate it fully, but in short, he tells a story about having to deal with some pretty severe back pain recently. After visiting an MD who only gave him a prescription for Vicodin and some exercises that didn’t help at all, he ended up at a Chiropractor who was able to sort out the problem in just a few days (after taking an X-ray to help diagnose the problem). When asked why the MD didn’t originally take an X-ray to get to the root of the problem, the Chiropractor replied that it wouldn’t have mattered if she did:

Even if the MD had taken an X-Ray, she would not have seen what I saw. Show us each the same image and we see different stuff.

It’s this different way of seeing that makes the IA profession so crucial right now. IAs specialize in looking at a vast amount of information and making sense of it in a way that is credible, consumable, and relevant to users (and the business). Where most of us only see Navigation, they know that part is just the tip of the iceberg. Underneath it lie activities like Information organization, Information relationships, and IA research that all work together to give IAs their unique view of the world.

Within this large toolset that IAs have to choose from to do their work, Customer Journey Maps stand out as the one technique that can be most effective to bring purpose back to our UX work. As UX Matters defines it:

Customer journey maps are documents that visually illustrate an individual customer’s needs, the series of interactions that are necessary to fulfill those needs, and the resulting emotional states a customer experiences throughout the process.

These maps are important as a way to find UX purpose because it accomplishes the following goals:

• It provides a common understanding within an organization about customer needs, product strategy, and business goals - i.e., the product’s reason to exist.
• It’s an excellent product prioritization tool.
• It’s a guiding light for design, always bringing the project and the process back to the customer journey and the purpose of the product.

There are many different ways to approach these maps, but I find the Adaptive Path way the most effective. It places a strong focus on user research, and forces you to think about the implications of the journey map, and how it can integrate with and guide the design process.

So, that was my story at the conference. Thanks to everyone who came out! Here are the slides from my talk:

Mark Boulton wrote a fantastic piece called Structure First. Content Always. He makes a strong case that it’s unrealistic (and just plain wrong) to require content to be written before design happens:

Let’s be really clear about this. It is unrealistic to write your content ”“ or ask your client to write the content ”“ before you design it. Most of the time. Content needs to be structured and structuring alters your content, designing alters content. It’s not “˜content then design’, or “˜content or design’. It’s “˜content and design’.

I often utter the phrase “you cannot design without content”, but in practice I still fall back on old habits when push comes to shove and content simply isn’t available. Mark provides a great solution in his post as he explains what content structure is all about, and how it fits into the design process.

Tucked away among the usual arguments for and against designers being able to code, Mandy Brown makes an interesting observation in Specialist or Generalist?, a roundtable discussion on the issue:

You do not need to be proficient in practices other than your own; but you ought to be curious. Curious enough to ask questions, to read about things, to get your hands dirty. It’s lack of curiosity about other disciplines that is deadly, not lack of skill.

This is a statement worth digging into, because curiosity is one of the most important characteristics of a good designer (well, of anyone, really). Sara Wachter-Boettcher explains the reason really well in her piece On Content and Curiosity:

Curiosity keeps us hungry. It leads us to tackle new challenges when the easy questions have all been answered. It makes us wonder how things could be better””even when they are, if w’d just pause to admit it, pretty damn good already.

There is a very legitimate counter-argument to being incurably curious, though. We might gain such shallow knowledge about so many different things that we end up unable to form or articulate opinions on anything because we just don’t know enough about a specific topic.

This is the core of the “specialist” argument, and it’s articulated very well in Stop Trying To Be Diverse, an interesting post about photographers on the Musea blog. The author tells the story of a particular photographer who spent his entire life shooting black-and-white portraits of people against a white or grey background. Boring, right? Well…

We don’t want to restrict ourselves to something like that because we feel that we will get bored. However, boredom is a great thing! What actually occurs is, boredom forces us to be more creative if we can push through it. Our work will improve if we find different ways to solve the same problem over and over, instead of switching between 10 independent problems. Avedon forced himself to come up with something new every time his subject stepped in front of his white seamless background. He had to find something unique about each individual, otherwise he would fail. The difference in his work came from what his subjects brought to the image, not by some new Photoshop filter or fancy off-camera lighting technique he used.

I’ll illustrate this with a story about my own online behavior. The other night I went online to do something (who knows what it was), and an hour later I found myself reading an article about a guy who feels that Louis C.K. was stupid because he made “only” $1 million from his standup comedy experiment. The person claimed that he could have helped Louis C.K. make $5 MILLION!!! I got to end of the article and all I could think was, “Why do I read this crap?” Well, I read it because my curiosity sometimes overcomes my importance filter. And getting that balance right is what we all need to make this curiosity thing work for good, not evil.

So, how do we arrive at (and maintain) this balance? How do we remain curious, and still manage to temper our gluttonous, Internet-fed thirst for All Things, All The Time? The core of the solution lies in learning what to cull from our lives, and what to surrender instead. In The Sad, Beautiful Fact That We’re All Going To Miss Almost Everything, Linda Holmes describes the two concepts as follows:

Culling is the choosing you do for yourself. It’s the sorting of what’s worth your time and what’s not worth your time. It’s saying, “I deem Keeping Up With The Kardashians a poor use of my time, and therefore, I choose not to watch it.” It’s saying, “I read the last Jonathan Franzen book and fell asleep six times, so I’m not going to read this one.”

Surrender, on the other hand, is the realization that you do not have time for everything that would be worth the time you invested in it if you had the time. Surrender is the moment when you say, “I bet every single one of those 1,000 books I’m supposed to read before I die is very, very good, but I cannot read them all, and they will have to go on the list of things I didn’t get to.”

We constantly need to learn how to make better decisions about culling and surrendering. For example, I should have culled that Louis C.K. article. And at some point I need to choose to surrender all the UX articles in my Instapaper queue and just freakin’ fire up Balsamiq.

Should designers learn to code? It depends entirely on each designer’s ability to decide if it’s a skill that should be learned or surrendered in the bigger picture of meeting his or her ultimate life/career goals. Put another way, there is no right answer, as long as the designer is at the very least curious enough to know how development works, and at best has made a conscious decision either to surrender the skill or dive in and learn it.

Yesterday saw the Beta launch of a new Mint.com-type startup in South Africa called 22seven. They’re essentially aiming to give people better insight into the money they spend, and help them make better decisions about that. Or to put it in their own words:

We use smart information-gathering technology so our users can see all their financial stuff in one place. W’ve applied insights from behavioural economics so our users can better understand the way they think. And by employing principles of play, our users become more engaged, and more willingly engaged, with their money.

It didn’t take long for the banks to start freaking out about the security implications of giving your banking credentials to a third party, but there have also been some defenses of the safety of the service. Instead of rehashing those arguments, I’d like to make three quick comments about the new service.

An observation

I’ve been watching this unfold with fascination over the last 24 hours. Everyone who attended the launch event in Johannesburg seemed really impressed, but it didn’t take long for some (legitimate) concerns to arise as people started trying out the service:

My mom told me never to accept sweets from strangers and to give out my pin number… So… Yeah… Sorry 22seven…

”” Cathryn Reece (@CathrynR) January 26, 2012

That’s a sentiment I agree with, but things started to go downhill a bit from there as the tweets became more and more negative. We’re a finicky bunch of complainers, aren’t we! But as I caught myself just in time before getting sucked into the negativity vortex, a phrase jumped into my head: Schlep Blindess. As in - these guys don’t have it. In Paul Graham’s excellent essay he describes schlep blindness as the inability to identify hard problems to solve:

The most dangerous thing about our dislike of schleps is that much of it is unconscious. Your unconscious won’t even let you see ideas that involve painful schleps. That’s schlep blindness.

He ends his essay by explaining how to avoid schlep blindness:

Some ideas so obviously entail alarming schleps that anyone can see them. How do you see ideas like that? The trick I recommend is to take yourself out of the picture. Instead of asking “what problem should I solve?” ask “what problem do I wish someone else would solve for me?”

And that’s why I admire the creators of 22seven. They’re working on a problem we all want solved, but most of us are too scared to work on. And for doing that, they deserve enormous credit.

A complaint

Speaking of finicky complainers, can I be one of those for a minute? Ok, cool. Obviously my first instinct was to scrutinize the design of the site, and even though there’s a lot to like about it, I have to mention a couple of things that I believe are not implemented correctly from a UX Design perspective.

First, forcing someone to wait for a Flash (!!) animation/introduction to load when they click “Register” is just not a good thing. Users don’t have patience for that stuff. If I ask for a registration form, my expectation is to see a registration form immediately. But my main beef is with the registration form itself:

Here are some of the issues:

• The text has very low contrast with the background which makes it difficult to read. Come on, everyone - join the contrast rebellion!
• We know that it’s bad to use multi-column layouts in forms.
• Speaking of contrast, what stands out are the phrases “About you”, “terms of service”, and “privacy policy”, while the primary call to action (“Yes, I do”) is a grey button on a dark grey background.
• While I’m nitpicking, if the button says “Yes, I do”, shouldn’t the title be “About me”?

We just don’t have to re-invent forms any more. The hard work has been done for us - we know how forms should be designed. And I don’t want to get into the Flash debate again, but why build this thing on a waning technology when you can build a responsive HTML web app that works on all devices?

A suggestion

Lastly, I’d like to offer a suggestion. If it is indeed true that 22seven has not met with South African banks yet, that’s a situation that should be rectified soon. In fact, my suggestion is that 22seven meets with one bank and work with them on an API solution that will allow them to access users’ banking information without having to store their credentials at a 3rd party. That’s what OAuth is for. And based on everything we know about Michael Jordaan (the CEO of FNB), wouldn’t FNB be the perfect bank to partner with on this? Once they’re on board, and FNB’s handsome and smart clients start using the service, the other banks are sure to follow.

I’d like to end where I began - on a positive note. I’m truly grateful that 22seven is tackling the banking/money management problem in South Africa in a very real and committed way. I think they vastly underestimated the backlash they would get from users when they’re suddenly asked for their online banking credentials (otherwise the web site would have been littered with trust-building explanations and images). But that’s a fixable problem, and so is my UX nitpicking - they’re not difficult issues to address.

So despite my complaining, I’m extremely excited about 22seven, and I’m rooting for them to succeed. I hope you’ll join me.

In 1955 David Ogilvy wrote a fascinating letter about his habits as a copywriter. One of his points jumped out at me:

I write out a definition of the problem and a statement of the purpose which I wish the campaign to achieve. Then I go no further until the statement and its principles have been accepted by the client.

This is applicable to design projects as well. If clients (internal or external) ask us for some quick wireframes, it is our responsibility as user experience designers to push back and make sure everyone agrees on the problem and the goals of the project first - before the design cycle starts. It sounds so obvious, but I see people falling into this trap all the time.

The product discovery process can take months, weeks, or even a few hours if there are tight deadlines. But it cannot take zero hours - that’s a recipe for disaster.

A few months ago Nilay Patel did a good interview with Tony Fadell, the creator of the Nest thermostat. From Inside the Nest on The Verge:

Fadell looks out at the Manhattan skyline and says that he always wanted to be an architect; that buildings stay beautiful forever but digital devices are quickly obsolete. “You look at hardware or software five years later? They’re crap. You would never use them again. People use architecture all the time.”

His voice rises. “What is our form of architecture? What is the thing that lasts of beauty?”

I’ve been thinking about this for a while now, and the reason I can’t get the interview out of my head is that I just can’t think of a good answer to Fadell’s question.

In web design, what is the thing that lasts of beauty?

Aesthetics and beauty in web design is so subjective, so polarizing, that I wonder if anything lasts of beauty in what we do. As one example among many, the current trend set by Path and Feedly seems to capture everyone’s imaginations. Beautiful, high-quality, full-screen photography with functional interactions and copy elegantly embedded:

I also find these sites beautiful - and functional. But will it last? 2010 and most of 2011 were mostly about minimalism, and now the pendelum seems to be swinging towards a more emotive aesthetic again. That’s fine because our field is fluid and dynamic, and unlike buildings, things change very rapidly in what we do.

But I do wonder: where are our timeless stadiums?

In a recent article on Russian architecture Dmitry Fadeyev describes metro stations in Moscow and ends with the following remark:

What’s interesting about this type of architecture is that its aim goes far beyond that of creating a functional underground system. Its aim is to promote a political ideal, and it does it through beauty by enriching lives of the people who get to experience it. The question here isn’t: how do we solve the problem of creating a metro station in an efficient manner - instead the question is: how do we create a station that elevates people’s mood and inspires their lives. This architecture isn’t there just to help you live - it makes life worth living.

Maybe that’s why I think it’s important to talk about lasting beauty in web design. 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”?

---

Update 1/10/02: Francisco Inchauste wrote a great comment on Google+. Instead of summarizing it, I’ll post it here in its entirety. His point about content being that thing that lasts of beauty is particularly interesting. Francisco writes:

Our raw material doesn’t have a cost. You can cut up pixels and add to them. You can only cut a stone or wood once. Then it’s in a final form. We never find a final form for our digital goods, because by nature they are in a state of flux. The real beauty could be the changing connections of nodes that make up our Web.

_The lens (browsers/devices) to view that work is always different and also evolving everyday. I think that’s why people have landed on content as the focus again. The content can evolve in presentation, but at the core is still the same content. So, maybe the goal of lasting beauty is in content, instead?
_

Fred Wilson on what’s needed to build product in the early stages of a startup, in The Management Team While Building Product:

Building product is not about having a large team to manage. It is about having a small team with the right people on it. You need product, design, and software engineering skills on the team. And you need to be focused, committed, and driven. Management at this point is all about small team dynamics; everyone on board, working together, and getting stuff done. Strong individual contributors are key in this stage. Management skills are not a requirement. In fact they may even be a hindrance.

Startup teams always have software engineering skills on board from the very beginning - as they should. But too often you see marketing and business development skills being added before you see product/design skills. This leads down a dangerous path that too often ends in a catastrophic lack of product/market fit.

This is a great post by Anil Dash. There’s so much to learn from the Foursquare story, but my favorite part is the last paragraph. In Foursquare: Today’s best-executing startup he writes:

But perhaps most importantly, I think we need more stories that celebrate the success of what seem like small, iterative product launches, but actually reflect triumphs in unsung disciplines such as systems operations, design process, business development and product management. There are lots of loud, pointless headlines about companies getting money from venture capitalists or angel investors. What I’d love to see more of in 2012 (and beyond!) is headlines about how a few small successes with users are a demonstration of a small company outperforming and out-innovating the biggest companies in the tech industry by being focused and disciplined in their execution.

This is why I hope all the cynics are wrong when they publicly wonder when Facebook will buy Path’s design team. I’m done with Path because I couldn’t find a use for it, but some people have found a place for it. I’d much rather see Path succeed as a small, niche social network that continues to push the design envelope, than have them be gobbled up as a “talent acquisition” move.

When we design for the web we often find ourselves balancing the use of established UI patterns with trying out new ways to solve existing problems. Facebook Timeline is tilted towards the former, while Path bet heavily on the latter. Yet both approaches are important. If we’re going to move the web forward we can’t get stuck in the existing ways of doing things without also experimenting with possible better ways. If we shine a bigger spotlight on those small companies that “outperform and out-innovate the biggest companies”, then maybe we can maintain this necessary balance between design status quo and new ideas indefinitely.