Grudin's Law

Created: Monday, 24 March 2008 Written by Gary Elsbernd

"If the person responsible for using the system does not benefit, the system is doomed to failure." - Grudin's Law, Jonathan Grudin

We need to recognize that pushing our pain, that is, our needs, on someone else to implement will at best give us grudging and resentful compliance. If we can ensure that the person receiving the benefit is the one doing the work, we will get a more motivated group of performers.For example, the marketing group for a retailer decides they want zip codes from all of their customers. It involves more work for the cashier, and is resisted by customers. If there is no clear incentive for the cashier, or consequences of failure, the cashiers will enter false data in an attempt to make their lives easier.What we need to do in cases like this is to show the clear benefits of the task to the user and get them "on our side". The other option is to monitor and correct issues, but the carrot is preferable to the stick.

 

Gery's Law

Created: Tuesday, 18 March 2008 Written by Gary Elsbernd

"Designs fail when the effort required is greater than the time available at the moment of need or the perceived benefit." - Gery's Law, Gloria Gery

effort required > time available + perceived benefit = system failure

Since in most cases we cannot increase the time available (we only wish we could), we must either

1) reduce the effort required (make the system more intuitive, fewer steps, etc.)

or

2) increase the perceived benefit (communicating benefits, motivating the user)

Evolution of a Logo

Created: Friday, 28 September 2007 Written by Gary Elsbernd
Team Agilefox

Geocachers have nicknames they use to sign the logs and in the forum.  Mine is Agilefox – from my days in Wood Badge training in Boy Scouts.  I was in the Fox patrol and was anything but Agile.

Some cachers like to leave signature items in caches to show they were there.  My brother, Team Nutty Dog, leaves dogbone shaped caribeners.  Other cachers spend a lot of money to mint their own coins.  I chose to go closer to the cheap end of the spectrum and make wooden nickels.

My first wooden nickel came from Geocoins.net.  I sent them my logo and they laser  burned it into an inch and a half wooden disk.  They were cool, but kind of expensive and I couldn’t  design a back side or have color, or change the design easily, so we stopped using them as soon as the initial order ran out.  I also wasn’t happy with the amount of detail in the design and felt the need to simplify the design.  It felt crowded and didn’t give anything real emphasis.

I switched to 1.5″ laser printed labels applied to a 2″ wooden nickel blank from wooden-nickel.com.  I made them myself and could customize them or change the logo as often as I liked.  My next design had a colorful palette of oranges, browns and teals.  It was influenced by the Kansas Koyotes (whose mascot’s ears form the “a”s in Kansas) and Team Gridlox who had a possum looking out of a round frame.  I liked the  Warner-Brothers look of this design, similar to Bugs Bunny popping out of the center.  After thought, however, the colors and gradients overpowered the name and everyone kept calling it a “Team Gilefox” coin.  Weird that they could read the first “A” but not the second, but the black ears and orange text with a blue outline were too dissimilar to connect.

With that user testing feedback, I talked with Chris Mackey (of Fox-and-the-Hound, and a great coin designer) about how to make my brand more prominent.  The next iteration had no color gradient and fewer colors.  The ears were extended to the edge of the design and all text was made black.  I made versions with and without the crossbar on the A’s.  I wasn’t as happy with the orange circle but I thought it would balance the orange in the fox’s face.  This design didn’t last long, as cachers still referred to it as a “Team Gilefox” coin.

Finally, I decided to simplify once again.  I  dropped the orange circle, detached the ears and added the geocaching logo to it.  I am very pleased with this design and no one has confused it with “Gilefox”.  I used this on the rest of my geocoins, and then switched to 1″ stickers on black poker chips from Wal-mart.  I spray them with a sealant and off they go.  This has the finished look I wanted and are cheap enough I can leave them in every cache I like.

I enjoy reading through logs on caches I’ve found and hearing about how people like and grab the chips.  This is the coin design I would use if I ever decide to mint a coin or pathtag, but so far I like the releasing aspect much more than I think I’d like the collecting and hoarding that can go on with many coins.

If you visit one of my caches, or cache with us as a team, or just happen to find a cache I’ve been to, you might find one of these chips.  I hope you enjoy them if you do!

 

Remembering Why We Are Here

Created: Thursday, 23 August 2007 Written by Gary Elsbernd

I was reminded yesterday of the dangers of developing tools for the sake of tools.  Back in the day when I developed websites for folks, I would be so excited by a new technology or widget I'd found that my instinct was to include it so I could play.  I would add a bit of DHTML or javascript because I found it, not because it did something I wanted to do.  To some extent, I still do that on elsbernd.com, because it's my hobby site. The challenge when working for a client or employer was to ensure the design had as little as possible while meeting the goal, and no more. Anything else is a distraction that wouldn't help achieve the goals of the site.

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."  --  Antoine de Saint-Exuper

The actual issue yesterday was a project management process.  The process to ensure quality and governance was starting to shape the software development process, when it is supposed to be unobtrusive and stay out of the way of getting the work done.  The software design process was being asked to change to fit the documentation and reporting requirements set by project management.  It didn't help create better code, just better reporting.  The focus was going away from developing useful, bug-free code on time and under budget to completing deliverable documents and passing through review gates.  The project management process was becoming the focus of the activity, instead of being in an oversight and supporting role.  The software development needed more priority, as it was actually developing code for use by the business.  Likewise, the software development process should bend to service the business, not stay so rigid that the business has to adapt to IT processes.

The focus needs to be on achieving the goals of the organization.  No organization has a goal of "developing software" -- they either want to use the resulting software to conduct business or sell that software.  The development process is just enabling the goal, not meeting the goal.  Likewise, while the project management controls are in place to ensure efficiency and effectiveness of the development, they are not an end in themselves, but rather serve the larger goals.  When the wrong things take priority, the goals are not being met.

And lest you think this only applies to software design, remember the same thing in your own life.  My life is not all about designing cool sites.  In part, I do this because I enjoy it, but at the root, my life is about my family and serving the Lord.  I work so I can afford to do those things.  When the job takes me away from the family more than necessary, or when I start to obsess about my job when I'm at home, I'm no longer serving the goals of being with my family or serving God.  The priorities have to be in the right place and remember why you're doing things, or you will be focused on glittery distractions and useless features in this life.

Wow, that got deep.

 

More Articles ...