In this post I argue that we need to communicate the differences between the science and art of Visual Design better to help change the common perception by stakeholders and clients that user experience is purely subjective.

One of the most difficult aspects of visual design is finding the right science:art ratio to accomplish user goals. I’ve always subscribed to what Tim van Damme calls the mathematics of design. You start with the science:

If art is about talking and expressing yourself, interface design is about listening and disappearing into the background. You listen to the content and its context, and take it from there, one step at a time. Don’t worry about the looks, just start with the variables. 1 + 1 + 1 + ”¦ Baby steps, over and over again until what you have on your screen feels right.

And then you mix in art where appropriate:

But sometimes, even 1 + 1 is too much to handle, and you need to clear your head. This is where art comes into play, in the broadest meaning of the word: Paintings, illustrations, architecture, human beings, even nature is art. They won’t help you decide whether you should draw a 1 or 1.5 pixel highlight, but allow you to take a step back and just decide on what’s more suitable or pick one and move on.

Of course, this is not a serial process. Great designers are able to design within that delicate balance between science and art, and find the right ratio as they’re doing it. And even though it’s not easy, I do feel that most designers inherently get this - that visual design is science and art combined in different levels based on the needs of the user and the application.

What’s even harder is explaining this to stakeholders and clients in a convincing way. Over the past week I’ve seen so many comments about how “UX is subjective” and “standards always change” that it got me thinking about a possible solution to this problem. I haven’t figured it out, but I’d like to write down some initial thoughts for discussion.

The problem with Visual Design

I think as a UX community we’ve done a good job of splitting out the different elements of UX Design. Stakeholders and clients are slowly starting to understand the difference between Information Architecture, Content Strategy, Interaction Design, etc. And most people also now understand that those functions are not just gut feel or whatever is the trend of the day. We’ve done a decent job of showing the evidence behind the decisions we make - thanks in large part to the results of user experience research methods like ethnography and usability studies.

But Visual Design is the odd one out in this equation. It walks the line between science and art so tightly that most stakeholders and clients only see the art part. So they look at a design, make a gut call, and think that it’s all just whatever style the designer fancied on that particular day. Sure, some of it is our own fault, and many designs don’t have enough science at all. As Zeldman pointed out:

When Style is a fetish, sites confuse visitors, hurting users and the companies that paid for the sites. When designers don’t start by asking who will use the site, and what they will use it for, we get meaningless eye candy that gives beauty a bad name ”” at least, in some circles. Not enough designers are working in that vast middle ground between eye candy and hardcore usability where most of the web must be built.

We have to find a better way forward.

Breaking down the elements of Visual Design

So how do we fix this? One way is to provide a much clearer distinction between the different aspects of visual design. I’m not saying we should split the job title into two functions, I’m saying we should be more explicit about the goals and outcomes of visual design. And it needs to be simple, so it can’t be too detailed. I’m not 100% sure how to do that yet, but here is one suggestion:

• Hierarchy Design could refer to decisions made during the design process that sets the appropriate visual hierarchy based on the scientific principles of visual perception (such as contrast, grouping, balance, symmetry, etc.). See Designing for the Mind as an example.
• Aesthetic Design could refer to decisions made during the design process to help the design fit the brand promise and elicit an appropriate emotional response (such as choice of color, typography, button styling, etc.). See In Defense of Eye Candy for more.

Now, as I already mentioned, there is a lot of overlap between these activities, and you can’t have one kind of visual design without the other. But there has to be a way for us to talk to our stakeholders and clients about the visual layer of design that is not based on style preference but on “hardcore usability” as Zeldman puts it.

As we continue to grow and define the different elements of user experience I believe that Visual Design has the most baggage to overcome simply because of the history of web design and its initial focus on what’s pretty vs. what works. What works is not subjective, and we need to communicate that effectively to our stakeholders and clients. It’s not their fault for not “getting it”, it’s our fault for not explaining it properly. Let’s change that.

South African movie site Ster Kinekor just relaunched their web site to much fanfare. Much of the discussion I’ve seen on Twitter about the new site is about their decision to remain completely reliant on Flash. I agree with all the technology arguments against Flash, but I want to take a slightly different approach here and talk about Flash as an enabler of bad user experience.

You see, Flash is like the guy who keeps giving your alcoholic uncle a drink while the rest of the family is trying so hard to help him get sober. Every time he gets close to quitting he gets “one more drink” from somewhere and falls back into bad habits. And this is what Flash is to user experience.

Every time you might get close to following standard UI conventions or have a simple flow, Flash comes in to whisper sweet animatic nothings in your ear… “Just one more flyout,” it says. “Just one more hover state - come on, everybody’s doing it.” Designing a boring old button? “No man,” says Flash, “we can make this thing move and light up with Flash, wouldn’t that be cool?”

And before you know it, you have this:

In my view, most of the user experience issues with the old Ster Kinekor site have not been addressed in the redesign. For example:

• There is no visual hierarchy on the site. Everything is important, so nothing is important. I just don’t know where I’m supposed to click.
• Animations are intrusive and adds to the confusion.
• Standard UI conventions are ignored. Buttons don’t look like buttons, links don’t look like links (links are grey on the site…).
• Forms are non-standard and not easy to fill out. For example, the checkout flow uses skeuomorphic design to make the credit card look like a real card, but it’s just confusing. And you can’t copy and paste your card number from a different document.

There are more issues, but that’s not really what this post is about. This post is a call to cutt off Flash as a primary development technology on a web site, not just because it’s slow, difficult for SEO, doesn’t work on iOS, and all the other technical arguments against it.

We need to cut off Flash mostly because it makes it way too easy to design bad user experiences. The web is undeniably moving beyond Web 2.0 (whatever that was) and into an era where simple designs that put content first provide the best user experience. And Flash simply doesn’t fit that mold.

Perhaps the most succinct summary of Monday’s Apple WWDC keynote is this tweet by Dustin Curtis:

I understand the sentiment, and a lot of the post-keynote blog posts echoed this general statement. The most measured response, in my view, came from Marco Arment, the creator of Instapaper:

If Reading List gets widely adopted and millions of people start saving pages for later reading, a portion of those people will be interested in upgrading to a dedicated, deluxe app and service to serve their needs better. And they’ll quickly find Instapaper in the App Store.

I’m certainly not going to stop using Instapaper. I’m deeply invested in the service and can’t see myself moving to Safari any time soon. But that’s beside the point. Here’s the point.

I find it strange that people are freaking out about how Apple is going after successful apps and integrating them deeply into Lion and iOS. Here’s Rich Mulholland (well, censored a little bit):

For my part, I agree much more with Justin Williams when he says:

Some people grow frustrated by Apple continually making inroads in existing developer’s territory, but it comes with being a part of the platform. The key is to ensure your product lineup is diverse enough that you can survive taking the blow Apple may offer at the next keynote.

The Theory

And this is where we have to start talking about Sociology theory (No, don’t go away, this is going to be great!). One of the key concepts in Social Network Theory is Ronald Burt’s theory of ‘structural holes’. This theory aims to explain how competition works, and argues that networks provide two types of benefits: information benefits and control benefits.

• Information benefits refer to who knows about relevant information and how fast they find out about it. People with strong networks will generally know more about relevant subjects, and they will also know about it faster.
• Control benefits refer to the advantages of being an important player in a well-connected network. In a large network, central players have more bargaining power than other players, which also means that they can, to a large extent, control many of the information flows within the network.

Burt’s theory of structural holes aims to enhance these benefits to their full potential. A structural hole is “a separation between non-redundant contacts” (Burt, 1992). The holes between non-redundant contacts provide entrepreneurial opportunities that can enhance both the control benefits and the information benefits of networks.

To understand the role of structural holes in this regard, it is necessary to understand the concept of tertius gaudens. Taken from the work of George Simmel, the tertius gaudens is defined as “the third who benefits” (Simmel, 1923). It describes the person who benefits from the disunion of two others. For example, when two people want to buy the same product, the seller can play their bids against one another to get a higher price for the particular product.

Structural holes are the setting in which the tertius gaudens operates. An entrepreneur stepping into a structural hole at the right time will have the power and the control to negotiate the relationship between the two actors divided by the hole, most often by playing their demands against one another.

Apple’s Strategy

This is exactly what Apple is doing, and have been doing from the start when the first iPhone came out (maybe even before). They saw the structural hole between 3rd party developers and consumers, and walked right into it. Through the app store, they built an enormous network (information benefits) where they broker the relationship between developers and users (control benefits). By providing developers with a massive audience, they became “the third who benefits.”

I also don’t think they’ve been particularly secretive about this strategy, so it shouldn’t come as a surprise to developers that if they have a one-platform strategy, and that platform is iOS, they might get disintermediated at some point.

Which brings us back to Marco Arment and Instapaper, and why I don’t think he’s in trouble. Instapaper is an ecosystem that’s intimately part of my workflow. It’s integrated with Firefox, iPhone, iPad, Twitter, Google Reader, Flipboard, Zite, … the list goes on. I’m not going to switch away, because I don’t see Instapaper as an iOS app. I see it as a solution to my reading needs.

So should developers still make iOS apps? Of course. But it’s important to realize that the product shouldn’t be the app. The product should be the problem you solve for users, on multiple platforms and in a simple, integrated way. Those are the apps that will survive (and even thrive) despite any changes that occur on Apple or another platform.

Over on the 37signals blog they just reposted an old article entitled Product roadmaps are dangerous. Jason Fried says the following:

Instead of the roadmap, just look out a few weeks at a time. Work on the next most important thing. What’s the point of a long list when you can’t work on everything at once anyway? Finish what’s important now and then figure out what’s important next. One step at a time.

It’s hard to disagree with a person (and a company) you have great admiration for, as I do for Jason and 37signals. But I do think it’s important to set the record straight on product roadmaps - particularly when it comes to large organizations. The post highlights two main concerns with product roadmaps:

• Product roadmaps assume you know what’s going to happen 6 - 18 months from now
• Product roadmaps set expectations, so you can’t change them (and if you do change them it becomes a worthless exercise)

So let’s look at each of these points in turn.

Product roadmaps assume you know the future

Jason writes:

When you let a product roadmap guide you you let the past drive the future. You’re saying “6 months ago I knew what 18 months from now would look like.” You’re saying “I’m not going to pay attention to now, I’m going to pay attention to then.” You’re saying “I should be working at the Psychic Friends Network.”

This is not what a product roadmap is, or what it’s supposed to do. The purpose of a product roadmap is to set forth a long-term vision for the business, and break that up into smaller, meaningful pieces of work, based on what you know now. It’s fallacy to believe that this is an unchangeable list of dates about where the business is headed. A product roadmap that doesn’t react to day-to-day changes in the market and within the company is a pretty dumb document.

At my organization we are very clear that the product roadmap is a flexible guideline that can (and must) change frequently as needed. But it gives the teams (and the management team) something to work towards. It’s a common vision, a sense of direction that’s more than just fluffy language - it’s concrete evidence that we’re headed somewhere good, and we know how to get there.

We can change direction as many times as we want. This doesn’t make it a useless exercise, it means that instead of starting fresh on a new “roadmap” every few weeks, you build on your past successes, don’t make the same mistakes twice, and keep making measurable progress since you can see where you came from.

Product roadmaps set the wrong expectations

Elsewhere in the post:

The other problem with roadmaps is the expectations game. People expect you to deliver what you say you will in 4, 5, 6 months. And what if you have a better idea? What if ther’s a shift in the market that you need to address? What if what you thought wasn’t what actually happened? Any change in the roadmap nullifies the roadmap. Then the map isn’t a map at all.

If you have this problem it doesn’t mean that product roadmaps are wrong, it means that you’re doing it wrong. As long as everyone in the organization buys into the fluid nature of the roadmap, you won’t have this problem. In our organization we do this mainly through the mechanism of what we call the Product Council (I was partial to Intergalactic Product Force, but for some reason that didn’t fly so well). Here’s how it works.

The Product Council is made up of the heads (VPs) of every department in the organization: Engineering, Marketing, Support, Category, etc. This body has a weekly meeting where we discuss the current product roadmap and priorities. We ask ourselves, Are we still working on the most important things? If something more important comes up, we prioritize it higher in the roadmap, and something else shifts down. If we’re happy with the direction, we do nothing. If a new opportunity arises we ask ourselves, Is this more important than what we’re working on right now? Or is this something we should work on next? If so, what moves down in the priority list?

From here, I communicate with my Product Team about any changes, and we discuss this to make sure no one missed anything. But then - and this is important - the Product Manager has complete autonomy and ownership over the implementation of the roadmap. The Product Council sets the priorities (with input from all parts of the organization), but the Product Managers work with their development teams (and others) to set the timeline, the implementation details, the design, everything.

There’s more to it, but in the interest of brevity I’ll stop there. This process has three main advantages:

• It gives the management team complete transparency into what the Product team is working on, and it allows for anyone to make the case for a change in priorities. Why this kind of transparency is so essential is a subject for a different blog post, but in short, it takes away a vast majority of the politics you see in many organizations, and it frees up the teams to do what they do best - execute.
• It prevents scope creep. Nothing can go on the roadmap without something else moving out or down. As anyone who ever worked at a large organization knows, this is an absolutely critical part of a successful development cycle.
• It gives the Product Manager and their teams what they need to be successful: direction and autonomy. As Jocelyn Glei says: “Give your team members what they need to thrive, and then get out of the way.”

Why product roadmaps are safe (and essential)

At a practical level I went through the exercise of figuring out how we could execute in my organization without a roadmap. And I just can’t see it. Changes to current pages/flows affect changes we’ll make down the line - I have to think about that.

If you’re serious about frequent incremental change as opposed to large redesign projects (as we are), you can’t live without a roadmap because you’ll have no idea how far you’ve gone, what you still need to do, and what’s more important than something else. And perhaps most dangerous of all, everyone in the organization will come to you and want all their projects done right now, and you’ll have no systemic method for dealing with that in a way that’s best for the business.

Andy Wagner summed up my feelings on this issue quite succinctly in a comment on the 37signals post:

[Product roadmaps are] an opportunity to dream about what the future might look like so that as you make your day-to-day responses to the customer, you can do so consistent with building the future state. It emphatically should not be anything to be slave to, it should be dynamic and notional, not static and specific.

Jason says, “The further you get from now, the less you know. And the less you know, the worse your decisions will be.” We agree on that. My argument is that without a roadmap you only see now. And if you only see now without seeing yesterday and tomorrow, you don’t see a whole lot. And “the less you know, the worse your decisions will be”.

These are my notes from Oliver Rippel’s talk at NetProphet 2011. Oliver is the CEO of MIH, a group company overseeing African and Middle East online properties like Mocality and kalahari.net.

The state of e-commerce in Africa

• As soon as e-commerce becomes more than 1% of retail sales, that’s when it becomes mainstream
• US not the most successful e-commerce market - Korea is, with 9% of retail sales online. US is at 4%
• E-commerce in Africa is still nascent:
  • Egypt - 22% Internet penetration, less than 0.01% online retail penetration
  • Nigeria - 29% Internet penetration, less than 0.01% online retail penetration
  • South Africa
    • 6 million Internet users, 12% penetration
    • 0.4% online retail penetration
    • 16.7% credit card penetration
    • 14 e-commerce sites in Top 100 SA sites

Positive e-commerce macro-indicators in Africa

• Big average projected real GDP growth
• There is a growing middle class of 320m Africans
• High mobile penetration (World average: 60%; South Africa: 92%)
• The promise of accessible and affordable broadband Internet is there

Lessons for building a winning e-commerce business in Africa

MIH’s focus is on the full e-commerce value chain The brands cover the whole purchase cycle: awareness, interest, decision, action, post sale, resale

• Embrace mobile
• Leverage offline
  • Go where the users are - online marketing on its own simply won’t work
  • Go to shopping malls and put up posters - whatever works
• Cash is king
  • 50m million banks accounts in Africa, 95% of transactions are cash-based
  • The only mobile payment system that is scaling is M-Pesa in Kenya: P2P payments
  • They are converting a cash economy into a digital economy, so that can now also be used for e-commerce
• Build trust
  • Open marketplace model is inadequate in low trust early stage environment - unlike eBay
  • Instead, MIH uses controlled marketplaces that reduce barriers for buyers by building a trusted brand

BlackBerry maker Research In Motion just cut their earnings guidance for Q1 2011, blaming slower sales. Even as the future of RIM looks bleak from a US perspective, you wouldn’t think so looking at the South African market. BlackBerries are simply everywhere. I’ve always wondered why BlackBerry has such a large portion of the SA smartphone market, and I can think of two four reasons:

1. Most BlackBerry contracts come with unlimited free data, which (to my knowledge) no other smartphone handset does at a reasonable cost.
2. When it comes to business users, it’s still the only phone trusted by corporate IT departments.
3. A capable smartphone at a reasonable price (although an influx of cheaper Android and Nokia phones might make this a moot point). (Thanks Steyn for pointing this one out in the comments)
4. The popularity and cost-effectiveness of BBM (although WhatsApp largely takes this away as a selling point). (Thanks Stafford for pointing this one out)

Now, here’s where it gets interesting. The latest earnings guidance cut clearly spells big trouble for RIM, and in a great blog post on Forbes, Eric Jackson lists 10 questions he would ask CEO Jim Balsillie based on that news, including the following:

Your bullish analysts used to say “yes, the US business is dying but International is going to keep growing.” You seemed to be saying last night that demand is drying up in Latin America too.  Does that mean the US was a sign of what is to come for your future International growth?

Now combine that with a recent IDC report that predicts Africa would become the first truly post-PC continent:

IDC estimates that in South Africa, 800,000 PCs were shipped in 2010 and the number is expected to decline by about four percent annually to reach 650,000 by 2015. Meanwhile, 1.3 million handsets were shipped in 2010 and that rate is expected to increase at a compound annual growth rate (CAGR) of nine percent to reach 2 million annually by 2015.

You have to ask yourself: how long can BlackBerry keep its apparent dominance in the smartphone market in South Africa? As mobile demand increases it appears that they will simply be unable to produce hardware that can keep up with consumers’ ever increasing smartphone requirements.

The “How Angry Birds would look on a BlackBerry” joke is funny, but there is certainly some truth behind the joke. As the line between work and life continues to blur, you don’t want a business phone that can also make calls. You want a personalised handset that can also be used for work. This is something RIM simply hasn’t figured out how to do, so they continue to double down on the “corporate security” angle. As Slate recently pointed out in a review of the PlayBook:

The incoherence, I think, is a sign of something deeper: Research in Motion doesn’t know what kind of company it wants to be. It made its fortune selling gadgets to chief information officers””IT guys who wanted to give their employees access to office e-mail on the go, but only in a way that accorded with corporate security policies. When they talk about RIM’s strengths, the company’s leaders like to point to their “CIO friendliness.”

The trouble is, being friendly with CIOs doesn’t matter as much as it used to. Nowadays people don’t ask the tech guy which mobile gadgets pass muster. Instead, tech guys look to employees to decide which gadgets to support. RIM’s strategy””to infiltrate companies as a first step to becoming a mass-market hit””has been eclipsed by the Apple approach, which is to infiltrate schools and homes, and then hope that regular people nag their IT guys to let them use iPads at work, too.

Meanwhile, Nokia appears to have given up on the US, but they’re coming for Africa in full force:

Nokia is already working with developers in several African countries and Peng feels that Nokia’s next big growth opportunity is to go beyond bringing affordable voice and SMS to delivering affordable web and applications.

“Rural populations live their lives largely outside of the reach of high quality services; through solutions like Nokia Data Gathering, we are already supporting field workers to collect, send and receive information quickly and securely via a mobile phone helping circumvent infrastructural challenges and speed up data collections needs in sectors such as health, agriculture, environmental conservation, population census and emergency services,” added Peng, in a press release sent after her speech.

It might not happen in the next few months, but I think there is a dangerous trend on the horizon for RIM. Between mobile handset growth in SA, trouble in the US market, and huge competition on the way, there’s a perfect storm brewing in BlackBerry land.

[caption id=“attachment_1181” align=“alignright” width=“240” caption=“Thinking about writing at Melissa’s Food Shop, Cape Town.”][/caption]

How good I am at my job as a software Product Manager depends on my ability to do two things: Understand the needs that real people have when they go online (whether they can articulate it or not), and building products that satisfy those needs as well as meet business goals. It occurred to me this morning that in many ways writing is about doing the exact opposite. To a large extent, writing is about being selfish.

Virtually any book or article you read about writing gives the same advice: Write what you know and what you’re passionate about. Write what’s in you, not what you think people want to read. Just last week James Shelley reminded us that people cannot help but notice an individual with passion. In another post he says:

Although passion may at times appear dangerous, the planet does not need less human passion right now, it needs more passion than ever before ”” passion that refuses to be immunized by the lulling caress of consumption and the crippling inundation of knowledge.

But it is this apparent struggle between Design and Writing (with a big D and W) that makes it so damn difficult to write sometimes. As user experience designers we’re trained to get out of our own shoes and into those of others. It’s about their needs, not our likes and dislikes. “You are not the user,” we often say.

But I have a feeling that the best writers (and designers, for that matter) are those who are able to balance this apparent conflict between user needs and internal passion effortlessly. Writers and designers who truly astound us with their work are those whose understanding of what people need are so ingrained in their beings, so much part of them, that they’re able to express their passion in a way that meets those needs “without fuss or bother,” as the NN Group definition of User Experience states.

It is for this reason that I think if you’re in software, you should write. Anil Dash got me thinking about this when he said:

Some ideas are just bigger than 140 characters. In fact, most good ideas are. More importantly, our ideas often need to gain traction and meaning over time. Blog posts often age into something more substantial than they are at their conception, through the weight of time and perspective and response.

If nothing else, the practice of writing down your thoughts (yes, about the things you are passionate about) will teach you how to create words in a way that resonates with those who read it. And just go ahead and try to convince me that won’t make you a better designer.

The biggest problem is, of course, that we all hate our own work, especially in the beginning. As Ira Glass so eloquently puts it:

Nobody tells this to people who are beginners, I wish someone told me. All of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, it’s just not that good. It’s trying to be good, it has potential, but it’s not. But your taste, the thing that got you into the game, is still killer. And your taste is why your work disappoints you. A lot of people never get past this phase, they quit.

He goes on to give this advice:

And if you are just starting out or you are still in this phase, you gotta know it’s normal and the most important thing you can do is do a lot of work. Put yourself on a deadline so that every week you will finish one story. It is only by going through a volume of work that you will close that gap, and your work will be as good as your ambitions.

If you’re noticing a change in this blog over the past few weeks, you’d be right. I’ve redesigned to put the focus on the content, and I hope to write just a bit more - even if that means fewer long-form posts. I have to test this theory that writing better words will help blur the lines between what I’m good at and what people need from software. We’ll see how it goes.

And you - yes, YOU. Go write something, ok?

I’ve been thinking a lot about the importance of humility in design. About a month ago David Gillis said the following in a great article for UX Magazine:

When it comes to designing experiences, cultivating a humble approach is absolutely essential. The sheer complexity of the design challenges we face demands open-mindedness - a willingness to test and modify assumptions, to make mistakes and be proven wrong.

Humility is about knowing what you don’t know, and when it comes to dynamic, interdependent, multi-platform systems, there are an awful lot of unknowns.

And then there’s this tweet by a good friend that’s been on my mind for a while now:

Ain’t that the truth.

But let’s also clarify: I’m talking about true humility here. Not the “Oh, I’m so humbled by your praise so let me retweet it to all my followers” humility. I’m talking about the humility that comes from realising that Design is about meeting user needs, that it’s a study of human behaviour so if any of us want to call ourselves experts at it we are sorely mistaken.

I didn’t think that a medieval monk could teach us much about design, but I recently stumbled on a quote by Thomas Kempis that brought this whole concept home for me:

A true understanding and humble estimate of oneself is the highest and most valuable of all lessons.

Should you see another person openly doing evil, or carrying out a wicked purpose, [or launch a really bad website,] do not on that account consider yourself better than him, for you cannot tell how long you will remain in a state of grace.

We are all frail; consider none more frail than yourself.

I don’t think this means we should stop being critical when we see bad design. But I do think it means we need to criticise with the aim to contribute to the design community, not break it down. If we learned anything from the Dustin Curtis “Dear American Airlines” story, it’s that we cannot possibly know why people make some of the design decisions they make.

So let’s help each other out, is all I’m saying. Because one day you might put a bad design out there, and all you’ll ask for then is a little advice and lots of grace.

Last week I delivered a new talk at a Cape Town SPIN meeting (the Software Process Improvement Network). While I was preparing for it I thought of a working title for my next talk:

A talk about preparing a presentation for a talk about preparing a presentation for a talk.

You see, I have a love/hate relationship with new talks. I love delivering a new talk, and I love getting feedback on what worked and what didn’t. I love making it better. And I hate pretty much every moment leading up to delivering it.

But this is, of course, the problem with the creative process.  It’s blood, sweat, and tears, most of the way. Rands recently wrote a post entitled A Hard Thing is Done by Figuring Out How to Start. He writes:

Those who do not understand creativity think it has a well-defined and measurable on/off switch, when in reality it’s a walking dial with many labels. One label reads “Morose and apathetic” and another reads “Unexpectedly totally cranking it out”. This dial sports shy, mischievous feet - yes, feet - that allow it to simply walk away the moment you aren’t paying attention, and each time it walks away, it finds a new place to hide.

I’ve spent a good portion of my life wondering where that damned dial is hiding.

He goes on to explain how random moments of discovery and seemingly useless tangents are all part of the preparation process, and that we shouldn’t be so hard on ourselves when we’re struggling to get started. He closes with this:

W’re addicted to quick fixes, top ten lists, and four-hour work weeks, but the truth is - if it wasn’t hard, everyone would be doing it and a hard thing is never done by reading a list or a book or an article about doing it. A hard thing is done by figuring out how to start.

You’ve been spending a lot of time thinking the result is what matters. You have a bright and shiny goal in mind that is distracting you with its awesomeness. It is this allure of awesomeness that is the continued reason why you keep searching around your house looking for that mischievous walking dial.

My guarantee is that what is going to make this bright and shiny thing awesome isn’t finishing. It’s all the little, unexpected details you discover trying to start. It’s all the small pieces of unexplainable execution that will not only make it yours, but also continue to teach you how you get things done. And when you’re done, you’ll discover finishing, while cathartic, is just a good reason to go start something else.

I’ve absolutely found that to be true. My basic process for preparing a new talk is as follows:

• First, I spend weeks researching and saving articles to Delicious.
• Then I live in FreeMind for a few days, building the outline of the talk.
• I then proceed to tell myself I’m ready to roll, so I  spend another week or more getting all those thoughts onto slides.
• This is followed by several nights of bad sleep as I start seeing the holes in my thinking, and struggle to find the right words/pictures/length/style/order.
• And then, suddenly and without fail, about two nights before the talk, I hit Flow. That “mental state of operation in which a person in an activity is fully immersed in a feeling of energized focus, full involvement, and success in the process of the activity.” Things suddenly fit, I spend 10 minutes re-ordering slides and it suddenly all makes sense. From that point on, the process is an absolute joy.

Why is Flow so hard to find? Or is it meant to be hard to find, because the creative process requires struggle as its fuel?

Whatever the reason, Rands helped me relax a little bit and panic less during the beginning phases of the creative process. Because all those starts, stops, and anxiety eventually come together to collide in the ultimate high that happens when things just… flow.

We’ve received quite a few questions about why we changed kalahari.net from a fluid layout to a 960px fixed width layout. There are pros and cons to both approaches, and Smashing Magazine did a great job of explaining those trade-offs in Fixed vs. Fluid vs. Elastic Layout: What’s The Right One For You?

For me, the most important reason to use a fixed layout is that it allows you to have full control over the experience and what the user sees on the screen.

But since a picture is worth a thousand words, I guess you can sum up the problem with fluid layouts with a single screenshot: