Design Tips from Lessons Learned in 2009

December 9, 2009

We had some fun and rewarding design projects this year.  Open Mountain has a new logo and Web site, and we executed a new ad campaign.  We also designed sites for our clients and were involved in many creative projects throughout the year.  I think it’s time for a little retrospective.  Before I take you through some of work, I thought I would provide some lessons learned from the year.  Assuming you are following a healthy design process, here are some tips to help you achieve success with your creative endeavors:

1) Start from a creative brief

A creative brief synthesizes the desired results or impacts of your project.  I recommend a single page brief that has 3-5 words that describe the emotion you wish to evoke, a sentence describing the impression you are trying to create or message you are trying to communicate, and then 5-10 bullet points listing everything that should also be considered.  We skipped this step a couple of times only to find out later that our lack of alignment was driving the design in different directions.  Resist the temptation to dive right in creating images before you collect your thoughts.

2) Use multiple visuals where ever you can

This one seems obvious.  Of course you are going to create visuals of your design.  We recommend using more than one as much as possible and use existing work for inspiration.  We started our logo project by creating a page of logos we liked from other sites and a page of logos we didn’t like.  Our Web site went through many prototypes before we started working in HTML.  Our design partners deliver 3 to 5 design choices per deliverable and that gives us plenty to discuss as we strive for something creative, intuitive and unique.

3) Plan to reset or start over at least once

All our best design projects hit the inevitable “we’re stuck” moment at some point in the project.  The current trajectory has run its course.  Where do we go from here?  Starting over allows you to dump the bad parts of everything you did while retaining the best of your brainstorming and thinking.  For our logo project, we liked the two-tone nature of the images but couldn’t converge on colors.  We realized that using brown to represent the strength of mountains was putting a damper on our brand.  Hills in California offer other choices such as green for spring or gold in fall.  The logo design direction was good but we dumped our color palette and started over.  You’ll see that progression below.  We recommend you embrace the set back as a healthy part of a creative process.  Try not to resist just because you are under deadline.  It may take you longer to make a bad design better than create a new design that works.

Here now is a trip down some of the design projects from our year and how we came to learn these valuable lessons.

Open Mountain Gets a New Brand

Our first project of the year was a new logo and Web site.  As I mentioned above, we did the logo ourselves starting from a creative brief.  Open has strong connotations for approachable and transparent but also open in the open source sense implying community and knowledge.  Mountains are strong, substantial and impressive.  The image below shows our progression from earthy colors toward what we have today.  This project benefited from all 3 tips listed above.  We used a brief.  We created mountains of visuals to consider different options, pun fully intended of course.  Our earth tones palette was replaced by something green, open and fresh.

We tackled the Web site next.  Below is our first attempt starting from our existing creative brief.  Do you see any major issues with this perhaps after reading our previous post about design?  You see a guy in a kayak against a mountain range exactly where the eye looks first on the page.  How informative is that?  We had hoped that the serenity of the lake we create a peacefulness when perusing the site.  One reviewer thought we were a travel Web site.  Furthermore, most people didn’t even look at the content at the bottom because it appears secondary to the overall page.  Time to start again.

Our new design started by utilizing our own advice and putting meaningful content in key positions.  We decide to use Flash animation to make the experience more engaging.  Below is our first shot at the flash panels for the animation.

Next we played with color and attributes to encourage the users toward different sections of a page.

In the end, we feel we created a site that is informative and engaging, and delivers the right message about our company.  Take a look and tell us what you think.

We Have Ads Now!

Our next project was creating advertisements for our business.  We procured several 250 by 250 spots on various Web sites through pay or partnership.  Due to timing constraints, we were forced to create something quick and dirty to meet a deadline.  This is what you get when you don’t follow good process or utilize any of the design tips we mentioned above.

Is there anything in this ad that is the least bit engaging?  What incentive do you have to explore this company?  What service do they really offer?  Right, you get the point.

We reset the entire project and thought hard about what were trying to do.  An expert gave us some advice on how to think beyond our current approach.  She talked to us about advertising and about how you create something like a “Got milk” or “Just do it”.

We have said from the beginning that we wanted to be different from what customers have come to expect with outsourcing.  We strive to overcome the separation between organizations and instead work to provide insight into what is really happening with the remote development team.  Working with Open Mountain should not feel like typical outsourcing.  It should feel like your own team.

Outsourcing never felt like this!

That was it.  We knew right away this was our “Got milk”.  When you outsource with Open Mountain, it should not feel like any previous experience you might have had.  Below is our first concept piece with the new approach.

Happy smiling people.  People actually enjoying outsourcing.  Exuberance.  Feedback from our experts confirmed this had appeal and communicated the right message.  We created 4 ads.  Here are the two favorites and we also used the one in the upper left corner above.

If you outsource with us, you’ll be as happy as a kid sledding or a crazy guy eating a huge lollipop.

These ads still crack me up.  They are quirky and unique and communicate our core message.  Of course, we rejected some ads as well.  Here are the two most controversial.

Outsourcing should feel like you are about to eat a huge hamburger, right?  People said he looked constipated or nervous.

Reaction to the woman eating cake was truly mixed across woman and men.  At the time we rejected the ad, one woman reviewer was saying this degrades our business while another said this would get the attention of our target audience.  Let’s just say that the ad did not fit well with our corporate values.

Clients Restart Projects Too

Design tips were learned working with clients as well.  Our client ThriveOn.com launched their site based on the design below.  As we added features to the solution, we soon realized that the design was creating some challenges.  This design is more consistent with a Web portal such as iGoogle or my.yahoo.com, and didn’t fit well with upcoming product changes.

The client went back to the drawing board and created a design more suited to the long-term growth plans of the product.  Below is an interim step from when we experimented with different color schemes.

The final site is presented below.  You can read more about our work with ThriveOn in our case study on the OpenMountain.com.

A Look at a Work in Progress

The year isn’t over yet and we’re designing new products all the time.  We strive to follow good process and utilize the tips mentioned at the start of this post.  Here now are two final mock-ups from a product we are working on.  The project is in stealth mode and some content is redacted.  Overall, the design process has gone very well.  Our favorite approach is not displayed below however.  You’ll have to wait until launch to see where we ended up.

3 Comments | Development philosophy | Tagged: , , , , , , | Permalink
Posted by bbenedict

Understanding Engineering Management Through Shipping Metaphors

May 31, 2009

We completed our first release with our new client ExpertCEO and were pleased to read the blog post of CEO Ken Ross about the update and the role our team played.   Open Mountain experts work as engineering management to oversee development and guide near shore teams to successful releases.  Ironically, we sometimes find ourselves explaining engineering management to companies even when their own experiences tell them software teams need leadership.  I’ve joked that you don’t know what engineering management is, but you know it when you have a good one.

Ken described our leadership as “oversight services to ensure that all of the technical, architectural and operational aspects are synchronized.”  Mario Chaves, CEO of our development partner Avantica, described Open Mountain another way, “[Open Mountain] experts improve communication, refine requirements and ensure all parties work seamlessly as one integrated team.”  These explanations certainly help to clarify our duties.  Perhaps a metaphor might help explain things better?

Developing software is like shipping cargo

Developing software is like loading a ship with cargo and navigating calm or rough seas to get to a final destination on time.  The captain puts together his best crew hopefully using seamen he has worked with before.   The navigator is the architect planning the journey.  The helmsman is the lead engineer and has the best sense for how the ship is handling.  The crew maintains the engines, cargo and supplies.  The captain, of course, is in charge of the ship and crew.  Let me provide some examples of how this metaphor is useful.

I took over a project in trouble at a previous job and described the project like this.  The ship was on a trip from Hawaii to San Francisco and right now they’re half way to Alaska.  We need to make a hard right turn and we may lose some of the cargo and crew overboard to get there on time.  This translates to making some decisions to change the direction of the project and that may include changing the team and cutting features.

Prioritizing features is like loading cargo.  We need to be in San Francisco within 3 months and you still have cargo on the loading dock.  You need to make some decisions fast and get this ship going or we’ll have no chance to arrive on time.  Load the ship too full and the ship will travel slowly.  Let’s quickly decide what needs to be loaded and shove off.

Agile development is like using a small, fast ship.  The client need not decide all the cargo he wants right away because the ship will be back in a month to pick up the next load.  It’s easier to select some items to load on a ship returning soon than trying to decide the only cargo you can bring in one shot.  As you can see, shipping works quite well.

Engineering management is like being the captain on the ship

The job of engineering management is to act as the captain of the ship.  The captain’s first job is to get the ship underway.  He helps the client decide what cargo to bring while selecting the crew and loading supplies.  The captain reviews the plan with his navigator and helmsmen, and manages the team to get the ship to sea as quickly and efficiently as possible.

If your development leader is pushing you to decide what is in a release, that’s because he knows the decisions you make start the journey.  He still needs to navigate the boat out of the harbor and across the ocean.

A good captain watches the early part of the journey intensely to verify his decisions.  He makes sure everyone knows their job, that the course is clear and the weather is known.  Making major course corrections in the middle of the ocean is definitely more difficult.  He makes sure the cargo is tied down and the supplies are sufficient just to be sure.

The role of the crew is clear to the client.  The navigator did the navigation, the helmsmen steered, and so on.  But if you refer to my earlier comment about engineering management, the captain was in charge but the client can’t say for sure what he did unless he was on the ship or talks to the crew.

Most captains I know are fine with this.  If the cargo arrives on time, the client is happy.  A well managed crew walks off the ship content.  If a captain made good decisions early on and tracked progress with an experienced eye, then the job was well done and the cargo is on its way to the final destination.

Had enough of this metaphor yet?  How about one more time?

Weather is unpredictable

Like it or not, projects get in trouble despite the best laid plans.  You’ll find out the hard way if you have a good captain when this storm hits.  An ocean storm can loosen your cargo or create a leak in your hull.  At that moment, the captain is the only crew member not assigned to a specific task and this probably is not his first storm.

A good captain will know that the leak is the most serious.  He’ll make sure that the navigator and helmsmen have their marching orders and put his best men on the leak.  The rest of the crew will be assigned to battening down the cargo and doing other less critical tasks.

By having the knowledge and leadership from experience, and the freedom to asses and assign, the captain is in perfect position to restore order and get the ship under control until the storm clears.  Most captains will simply confirm for the client they hit the storm and apologize for the damaged cargo.  He might ask for an extra long furlough for the guys.  And that’s really how you know you have a good captain!

So you see, a good engineering manager will do his best to create a project that runs on schedule and without hitches.  He’ll work with the team to define the work and make sure the engineers understand what needs to happen.  Throughout development, the manager tracks the progress of the team validating his decisions just like the caption of a ship checking in with his navigator and crew.  If things go awry, the engineering manager is the one team member with the experience, bandwidth and responsibility to get the project under control and manage it through to completion.

Three rules for selecting a good captain

Here are a few guidelines for helping you assess if you have an experienced and reliable engineering manager:

1) Has he been to many destinations encountering different weather patterns and obstacles along the way?  Is he an experienced manager and can he describe projects that were challenging to manage to completion?

2) Does he know how to build a good crew and does he bond with them and treat them well?  What does the team say about him?  Do they respect his experience and leadership?

3) Is he familiar with the most common and reliable boats used for shipping?  Is he familiar with the latest technologies?

These guidelines should help you select the best engineering manager for your project.  If you can’t find a sea worthy captain, a good leader will work provided you pair him with an experienced navigator and helmsmen.

Whatever you do, don’t head out to see without a captain.  If the ship hits rough waters, someone is going to have to step away from the job they are doing to get the crew under control and he may not have the experience to get the ship to port with cargo and crew intact.

Here’s to calm waters and white sandy beaches!

DSCN0636

Leave a Comment » | Development philosophy | Tagged: , , | Permalink
Posted by bbenedict

Is 2 Months Reasonable to Launch? Or even Doable?

January 19, 2009

We see a very interesting pattern for launch dates in requests for proposals (RFP) that we receive. Nearly everyone who starts development from April to August wants to launch in October. The trends makes sense when you consider seasonality. The difference between April and August is obviously significant. Yet, companies seem to want the same amount of functionality regardless if development starts in April or August:

“Why can’t this be done 2 months? How hard can this be? Can’t you just use some open source products and customize them? We don’t need to start from scratch here. My expert says…”

Customers bring up many salient points during these discussions. Can the team work longer hours or can they work smarter? If a set of features requires 6 months to reasonably develop, can it also be done in 2 months with about the same size team? In this previous post, we point out that coding is physics and that we can’t simply reduce the schedule to meet a deadline.

Have you seen those home improvement shows where the contractor blows the schedule and the budget because of some unforeseen factor or change in the plan by the home owner? The home owner looks at a set of materials, imagines in his head the work to put them together, but never quite understands that it is never that simple. With software development, it’s the same principle. People look at a set of features and think in their heads, sure, this is doable in 2 months. They rarely consider that the implementation may not be as simple as they think, or that they might see the product and decide what they wanted is not what they thought.

Let’s look at a simple feature example of implementing sign-up and login. You can’t do much in a product if a user can’t create an account. An experienced developer using PHP or Java could do these features in a few hours by creating an HTML form and writing some SQL to add or look up a record. If features are that easy, why do we even need 2 months?

A good team thinks about the best way to implement a feature above and beyond the mechanics needed to create a form or put a record in a database. The developer must define a user object that has properties like email and password and functions like saveUser and validatePassword. The team must define objects smartly, otherwise you may have longer term problems maintaining your code base.

The page must be properly formated to match the mock-ups and overall aesthetic of the site. Color and font attributes are centralized in CSS files. If these are the first two features of the site, then the login and sign-up pages created will be the ones that define the styles for the rest of the site. Usually, the team needs a graphic or two from the designer as well.

The developer must also understand the client’s login and sign-up business rules. Do users login with email, login name or both? Must users validate their email before accessing the site? Should the developer check to make sure the email address is valid on input? We had 3 customers launch or hit beta in fall 2008 and each one had subtle differences in their business logic for sign-up and login.

You can now see how something as simple as sign-up and login might take a day to implement and another to test and validate.

With a new code base, the team must define the infrastructure of the code. Developers consider scalability, security, exception handling and a host of other services to make your product secure, robust and scalable. The best teams use existing technologies or frameworks to solve the infrastructure problems, but they still need to customize the code to meet specific needs. We no longer have to cut down trees or mill wood when adding on to your house, but we still need to cut the wood to size.

The good news about objects and infrastructure is that they both solidify over time and the effort to implement new features reduces. Economies of scale start to kick in once you have your solid foundation. You can hook into existing pipes when adding a bathroom on the second floor so to speak.

When you consider how much design work, object definition, and infrastructure is needed to create a scalable product, you just may find that 2 months is only enough time to get a small collection of features working. I told one client recently that after 2 months, the product will look like an unfinished house. Showing the product to their customers would be like walking on to a job site and imagining where the living room will be. After 3 months, you’ll see walls and after 4 months you’re painting them.

We suggest avoiding the 2 month launch for the simple fact that the best product comes from gathering feedback and re-thinking core problems, which is hard to do when the people providing feedback have to imagine where the walls of your hypothetical house will be. A development cycle of 6 months provides enough time to implement a robust feature set for launch, and to make improvements based on real feedback. This seems like a good idea to us. You’ll see this theme along with our predictions for trends in 2009.

My final point is this. If you launch with something that took you only 2 months to build, how defensible can that be if you happen to uncover the next new market like blogging, social networking, software-as-a-service or some new island in the Pacific? In 6 months, you can have something better, with more ingenuity and functionality, that has validation from your target market, and is not something a competitor could replicate in time to rain on your parade.

So back to the original question. Is 2 months doable? Maybe it is. Maybe, if we all stay focused and implement a minimal feature set, and if we don’t seek any feedback on what we created, it’s doable. But is it a good idea?

2 Comments | Development philosophy | Tagged: , , , , | Permalink
Posted by bbenedict

Engineers Discuss Philosophy, But Only Late Nights in Skype

July 27, 2008

It’s 9 pm at night and I am chatting with my Ruby on Rails architect in Argentina who is working late to prepare a demo server. I know just how late it is in Buenos Aires because I have multiple world clocks set up on my iGoogle home page.

One of the things I like most about near shore development is getting to know people all around the world. This month, I have projects with team members in Argentina, Peru and Costa Rica. As a person interested in both technology and the world, I am grateful to have found a way to combine them both. And by the way, I am showing it is 1 AM in Argentina and the guy is still going. What a rock star!

While I wait to look things over, I am playing poker in facebook, perusing contacts in LinkedIn for business where I just requested to join the Intuit Alumni group, and started a download of the first season of Lost into my iPhone for my upcoming trip to see my sister in NY.

My engineer wants an iPhone. I tell him the quality is not so good but we agree the device is cool anyways. Then he introduces me to the Jawbone Blue-tooth borg ear phone and the video alone convinces me I need to have it too. Turn about is fair trade so I point him to thinkgeek.com and the 2 Gig USB drive watch I bought the other week for $30. Looking around my desk, in addition to the multitude of computers, I observe a sea of thumb drives, USB hubs, think geek devices, and wonder if maybe I should admit I have a problem.

I decide I need a new movie for my trip and buy Cloverfield instead.

While he’s waiting for a job to finish, we discuss github which he wants to use for source code control. I am open to considering this. So he sends me a YouTube link to listen to Linus Torvalds discuss his creation. We like the idea of combining EngineYard, github and RallyDev (we’re not exactly in agreement on this last one so he tries to persuade me to look at Lighthouse) in one suite of Software as a Service tools for managing a project. This seems like a very effective approach to me. I agree to look at it later.

In case you are not keeping track, the technologies and related topics we have hit in just the last 30 minutes of our Skype session include: Ruby on Rails, iGoogle, facebook, LinkedIn, Blue-tooth, Jawbone, Apple, iTunes, iPhone, USB, Intuit, YouTube, Linus Torvalds, EngineYard, github, RallyDev, SaaS, Lighthouse, and Skype

I have two minds about this (I am a gemini after all): first, this is really fun to be in the middle of such a dynamic, evolving and exploratory industry; second, how can we all possibly stay up on everything that is happening in all this industry???

I guess the answer lies in late night Skype sessions waiting for builds. But I know in the next week, a client or prospect will ask me about the latest JDK, virtualization, cloud computing, Ning, something like that, and I will be back again Googling the Web trying to keep up on the latest trends and changes. That is what I think defines a geek. Not if you do this, but do you enjoy it?

After finishing this post, we had a really funny exchange in Skype I thought to add. It really captures the essence of my point this evening:

ARCHITECT
java isn’t full oo language
you allways fall on the primitives
and all oo goes to the hell
with generics java adds some dynamic
but still you need to write to much code

ME
Yes. If you get just wood, you really need a good architect to build a good house

ARCHITECT
yes, but, you cannot build a house of ice at africa

ME
Now THAT is funny.

Leave a Comment » | Development philosophy | Tagged: , , , | Permalink
Posted by bbenedict