I had an interesting situation with a very recent client which helped me reaffirm that what I may believe to be right, or most appropriate, for my client may not be right or most appropriate after all.

It was not so much about my choice being wrong or even inappropriate, but that in this case my preferred choice was not the clients choice.

Herein is a lesson in not being an arrogant twat.

A little background
I was approached to work on a highly secretive logo project—it’s still under wraps at time of writing—with a rather tight time frame of 2 weeks. The thing that intrigued me was the name of this new company, and that it would provide a very challenging project in terms of how best to visualise their brand.

I gladly took the project, and spurred on by a generous budget eagerly set to work with my pencil and sketch book.

The agreement was that I would provide the client with all my sketches, thoughts, ideas when I felt I was fresh out of juice. At this early stage the client was not really sure in what direction to take the branding so wanted to see a selection of polar opposite ideas so that the most appropriate one would jump out.

I don’t often do this, but in this case the client was very sure about being able to work through rough idea after rough idea without getting confused or overwhelmed.

Skip 2 Weeks
Time to scan in all the pages of sketches and prepare any digital mock-ups that I had done to send over to the client.

There were a few clear favourite logo designs with one leading design that I felt summed up the brand as well as being a totally awesome play on their tag-line. I was sure that when the client saw all the ideas against my personal favourite they would agree. To help with their decision making I also took time to better prepare my idea to show it in context, and basically push it over the others.

I was so sure they would see the reasoning I put behind this logo idea which was logically conceived as well as having a quaint and visually charming logo mark.

Fail
Given the title of this post it would then come as no surprise that they didn’t choose my idea, but in fact choose a variation of one of my other preferred solutions, but this variation should not have been shown to the client. It slipped in and I was kicking myself for being such a dick head.

Truth be told I was slightly cursing under my breath whilst trying to plan my return strike so that they would ultimately have no choice but to listen to me.

No Movement
Should also come as no surprise that although the client agreed that my reasoning was very sound they simply liked this other idea much more.

Internally I just could not get behind it, but on the exterior I acted like a rational adult.

A Week Later
A week had provided me with some time to get over myself, and accept I was not in control, and we progressed with the project.

The next stage was the design of the business cards so I was determined to do what I could to pull all this together in a way I could be pleased with.

With the business card taking shape I realised my whole opinion of the logo design was changing as I was imagining certain print effects being utilised. Two sheets of 180gm uncoated white card stuck together would give us the chance to emboss both sides with this very minimally designed logo mark.

All of a sudden I could see the finished result and a renewed sense of excitement and enthusiasm came my way. No longer did the logo suck, but it now totally owned this business card.

Simply
Even though you may feel a client is not listening to you on the choice of final logo design, it can lead to a happy ending.

I was so caught up with my own sense of what I wanted for them that I almost totally neglected to see it from their side.

I think the extreme rushed nature of the project as well as the rather unorthodox prep and presention of the ideas contributed to loosing sight of the bigger picture.

The Client Was Right
In this case the client called it totally right, and I am so very pleased they didn’t buckle under my protests.

Ironically I always tell clients never to rush into making a decision the moment they see the first batch of logo designs. I ask them to sit on them for a few days before analysing and making rushed decisions. If after a few days they are still unhappy then we move on.

On more than a few occasions I have sensed their unhappiness at seeing the first ideas, but to then see a change in their opinions 3-5 days later resulting in a positive reaction, and a keenness to proceed.

I could have/should have listend to my own advice instead of becoming ever so slightly stubborn, and saved myself from some internal head butting.

The client was right, in their final choice of logo design, and for that I am happy because I can totally see that they were.
And The Moral Is?
If you find yourself in a similar situation, where you are doubting the saneness of your client after seeing them choose what you feel is the the worst possible design, then take a breath and give it a chance.

You could help yourself by only showing the client the ideas you feel are worthy, but we are not always in that position. As much as I swear on the ideals of only giving the clients the best of the best we can find ourselves giving in and showing EVERYTHING we have done.

We can be our own worst client.

I spent most of the weekend elbow-deep in weblog archives and templates, trying to update my site to MT 4.01 and WP 2.3.2 (the former required the latter to export/import). After several hours, I started looking at Expression Engine and Tumblr and even considered Blogger to run this site. After getting fed up with shortcomings, I thought I’d describe my dream weblog engine instead.

For anyone that designs and builds a blog app or CMS, consider the following as typical use cases and design technology around these experiences. As a user, it feels like blog app design is instead about picking technology first and asking users to design their usage around that.

Admin Backend

When you’re working on a blog post or setting up a blog, the backend of the application should be as close to the database as possible. A blog backend is almost by definition very low-traffic (especially with a single author) and there should be no impediments between having a thought and pushing a publish button. Most every app I’ve used is too slow in this regard, so even if you have to use another technology or application design from your blog publishing core functions, keep the backend as fast as possible.

Here’s a design goal: writing a sentence, pressing publish, and seeing it live on the site should take a handful of seconds. Writers should never have to stare at a spinning graphic for a minute as they wait for the publishing engine.

Templates

Here’s how most designers interact with templates: They work on a layout for a day or two (in photoshop and/or plain HTML/CSS), implement in whatever blog code the system requires, then they tweak it 100s of times over a few hours until it is done. Then it stays the same for anywhere from three to twelve months until a new theme/design inspiration comes along.

I personally like tweaking templates in a text editor, directly interacting with files on the server (as opposed to within a web app window, having to regenerate to see changes). I also prefer not to see the guts and/or technology of the blog CMS. Abstract it with output tags that don’t require knowledge of programming languages. Keep application logic out of the layout whenever possible, and allow minor tweaks in simplified tools (clicking options in a widget editor) instead of requiring template changes.

Simplicity is golden. The fewer templates, the better. Blogger wins in this regard by allowing an entire site to be laid out with a single template file and some CSS. MT4 is kind of a nightmare in this regard with seemingly dozens of templates, sub-templates, and sub-sub-templates that can be tweaked.

My ideal template engine would be as simple as possible and allow me one general template to control layout, maybe a few specific templates for specialized output (an entry with comments is different than a list of archived posts), and allow for fast tweaks until the design is done. When a template is “done” convert it into some stable package the CMS can use and that I can share with others easily as an archive.

Import/Export

There really should be a standard of some sort that blog CMS companies can agree on for export and import. Users of blog engines shouldn’t be hostages to their applications. Data exit and entry is problematic in everything I’ve used and it’s a shame. Blogging is supposed to be fun and I prefer to be agnostic about what tools I’m using, so it’d be nice if I could change blog engines every three months without too much friction. I won’t even go into how every engine has its own URL scheme — it’d be nice if I could keep my permalinks forever, even as I change blogging apps.

Documentation

Every blog engine seems to suffer not only from poor documentation, but also extensions, template designs, and tutorials are almost always spread out across multiple sites (often out-of-date). If I download a blog CMS from Site A, plugins for it are on Site B, but they link to Site C where you can download things (but documentation for the plugin is back on Site B). Every blog engine seems to also have internal battles between “here are the free tools for your blog” and “here are our professional services for your blog” that leaves me wondering where to find more info or extensions after I download. Then there are random people that just setup galleries of plugins and templates that often rival or surpass the blog engine company’s version of the same. It’d be nice if there was a way to find those as well.

My ideal blog engine company would hire some seasoned blogger and technical writer to be a documentation czar, keeping docs up to date when new versions are launched, produce screencasts for introductory users, and provide complete documentation at a stable URL that applies to every version of the product. If an outside site does a better job of collecting and offering templates, a documentation leader should recognize that and link to them in highly visible places. There doesn’t seem to be anyone internal at these companies fighting for the users to make sure they can keep being informed about how to best use the product.

Server Load

I’ll admit I like simple, live code editing of my template files (as described above) when I’m tweaking a design, and I love fast admin screens that let me post instantly, but once a post is up, it’s just text on a web server and should exist as a flat file. I’ve clicked through way too many digg links and del.icio.us popular links only to end up at database connection errors or too many user errors on servers that can’t handle the load. I know building a perfect cache is hard to do, but failure of your site at the most visible and important time for you should never happen.

Anyone got any other ideas of how to build the perfect blog application?

We identified a site in an area of downtown San Francisco that is underserved by public outdoor space and is in an ideal, sunny location between the hours of noon and 2 p.m. There we installed a small, temporary public park that provided nature, seating,

A campaign encouraging people to store personal details on their mobile phones to help identify victims of accidents and disasters has taken off since the bomb attacks in London.