Are you a craftsman in your job?

Do you look at how other people do it and comb over the details, critiquing or praising each element?  Do you consider yourself a student of the game?  Someone who is striving to get better each day?  Do you read blogs and books on your job subject matter?  Do you attend conferences or participate in the community of people also doing that job?

Or are you just phoning it in?  Are you focused on friends and family and not worrying so much about the job?  When you do a part of your job, are you OK with mistakes or sub-optimal outcomes?  Do you think people who have a “philosophy” about the job are taking it too seriously?  Is “doing it right” a subjective statement to you?

Possible uncomfortable truth: Most people would characterize themselves as craftsman, but in reality are hacks just trying to make it through the day.

There is a contractor I recently worked with who made this page that had every possible error in the book.  It was a horrible piece of work that literally wasted the time of the entire team and needs to be redone from scratch.  It really pissed me off how sloppy and unprofessional the work was.  It made me think of the great people I have worked with and the difference in outcome.

Great things come from craftsmanship.  Without it, you get unpleasant UI, poor maintainability, unhappy customers, uninspired coworkers and a host of other plagues.  I salute the people who go the extra mile in their craft.  I will be loyal and praising of you for as long as you practice your art.  For those who just slap things together, I want you to know that I (we) hate the products and services you produce.

At work, there are a few servers that are getting launched for a new service.  I said that the name of the URL is a design element and users will see it and react to it.  I got several looks of disbelief, but I pushed on this as a strong UX principle.

The user is always looking for signs of life in your application.  One glimmer of humanity and humor will enhance their mood a hundred fold.

The original url was http://srv-dfw-1.domain.com.  This worked perfectly for the system administrators to know that the url was for a server (duh) in Dallas-Ft. Worth and it was the first one.  However, the user would interpret this as a robotic unfriendly name devised by robotic unfriendly people.

So I started coming up with names.  Silly names, inspiring names, serious names, Elements, planets, scientists, rock bands of the 80′s.  All of the sudden everyone in the office was participating with tremendous energy.  They were screaming out names and laughing uproariously.  They were enthusiastically and totally engaged in the name of something they scoffed at 2 hours ago.

We ended up with http://daisy1.domain.com.  It starts with D, which is good enough to know the city and still has a number.  Yet, it also has life.  It is more geared towards women than men, but it makes sense for the user base.  It has flair and personality.

Everything you do, even down to the URL of your application is indicating your personality and philosophy.  Use those opportunities to communicate wisely.  Communicate with life and don’t let your system administrators name (or design) your application.

Several years ago, I went to a P-Camp Unfonference.  (It was fun and I strongly recommended giving it a try.)  It was at that conference that I realized how long most release cycles were.  They were running quarterly releases or longer.  One company was still on CD releases track once per year.

Software as a Service (SaaS) products do not require executables or CDs to deliver their upgrades.  They don’t have to worry about who is on what version.  They just update the web application and the next day, everyone is on the new thing, like it or not.  This solves all kinds of problems (and introduces other problems).

When you can update the product without worrying about burning millions of CDs and shelf space, you can release at will.  Literally, you can patch the site whenever you want, even mid-day.  This raises a critical question about the frequency of upgrades that are desirable from a UX standpoint.

Delivering too many updates will lose the Christmas Morning effect. Delivering too few updates means you are rolling up a ton of changes and it can become overwhelming. Clearly, a Goldilocks amount is required.  Not to frequent, not too seldom.  Just right.

I believe monthly releases are the right size for companies that are less than 500 people big.  There is a natural calendar in people’s brains that maps to the Gregorian calendar.  It’s easy to remember the May release rather than the 2.1.4 release.  Time is an important factor in software.  How much are you delivering in what time frame?  These are measures of agility and productivity that play into whether your customers think you are a good partner or not.

Going quarterly is a good idea for a bigger company that just can’t get all its ducks in a row in a month time span.  However, for any startup, this should be a problem.  Going shorter (2 weeks) works for the early stages of a startup and even beyond, but the user will lose some context around the updates.

Whenever you can use existing psychological anchors in your UX design, you should.  Why fight the human brain when you can leverage it?