The LiquidPlanner Blog

Designing Better Software: 5 Rules to Follow

I began my career designing software at Microsoft. Back then, our products typically involved a three-year development cycle – a deadline unheard of in today’s software R&D space. Back then, the long development period meant there was no real sense of urgency involved in the process. We all had three years to defend our designs – and three years before you could correct any mistakes that crept in during the prior three years.

Software design operates in a whole new world today – and good design remains as critical and as difficult as ever. There are a new set of drivers dictating product functionality but I believe the guidelines for software design leadership are the same as ever.

Three Major Influences on Design Today

Today’s software development cycle is completely different from even five years ago. Now we enjoy a rapid development mindset and an absurdly low cost of updating software. In the case of a SaaS product like LiquidPlanner, every customer gets all the changes at the exact same time because there is only one living version of the product.

There are three major changes that impact today’s design process. First, no software is designed for individuals anymore. Everything we design must function in the context of social interactions (in our case social business interactions.)

The second change involves mobile form factors: phones, pads, and desktops must always be present in our minds when we design. The trick is to build the right interface for each platform while retaining the feeling of using one product.

The third change is the availability of raw computing power. At LiquidPlanner we have features on our roadmap that will allow us to present very interesting visualizations of project management information ─ think moving forward and backward through the life of a project like you can with a video ─ that requires serious horsepower.

Guidelines for Smart Software Design

Considering my experience in both the “old days” and new era of software design, here are five guidelines which have stood the test of time and proved invaluable in the design process.

1. Old Designers Argue Late in the Process – Not Early

When I designed software in the “old days,” I was young and very enthusiastic. I felt I had to make my points first, win debates early and avoid mistakes. In a large part, I was confused about my role as a developer and somewhat overzealous in applying enthusiasm to the process.

As I got older, I realized it is better to have as many ideas on the table as possible during the investigation phase. This leaves a field broad enough to provide room for innovation.

The time for whittling down the options will become apparent as deadlines near. I think of it like popcorn in the microwave: You know that when the popping slows down it’s time to make some decisions.

2. Design is Messy and Imperfect ─ Deal with It

If we are all such great designers, why are we all not out of work after Version 1? Because design is difficult… Because user expectations keep evolving… Because design involves style – and style is always changing…

When the Windows “Start” button shipped it was considered cool – so cool that Microsoft hired the mighty Rolling Stones to promote it. Moral of the story? As soon as your product “ships,” start designing the next version.

3. You’re Not as Hot as You Think You Are

Good artists borrow. Great artists steal. Designers who ignore these realities are just plain dumb.

When we designed LiquidPlanner 1.0, we used section tabs in “homage” to Amazon. In LiquidPlanner 3.0, we are killing tabs ─ the last vestige of the online manila folder will be gone forever.

Another way to put it is that designs should be “uniquely familiar.” They should feel intuitively easy to use because they work like other things. Stick with Grandma’s cupcake recipe and use your unique “frills” for the “frosting.”

4. A Writer is Somebody Who Writes Every Day – The Same Goes for Designers

If you want to be a great designer, commit yourself to creative disciplines.

First, embrace the idea of continuous improvement; circle back to your designs and look for opportunities to improve them ─ even if nobody asks you to.

Second, embrace the idea that your developers don’t want you to be “continuously improving” because they just got the damn HTML tables working on IE6. If you don’t batch changes up into logical and reasonable packages, they will get cranky (don’t say I didn’t warn you!) In practice, this means you constantly use solid project and program management skills.

Think of it like photography. What makes a wedding photographer great is not so much camera mastery; it’s the process of taking 1,400 shots so that the newlyweds receive 25 good ones. Get good at generating realistic mock-ups very quickly so that the cost to explore a new idea is close to zero.

5. Consensus is Everything / Consensus is Over-Rated

When the team likes your design they say nothing. When they don’t like it, they say “Test it.” When they hate it, they say nothing. Go figure…

It’s the designer’s job not to mess it up. In many companies, this is tricky to manage. That means no one is going to get what they want every time. Unless design leadership emerges, this dynamic will lead to hard feelings on the part of one group or another.

A design leader excels at drawing out sentiments, ideas and opportunities from all parties – and above all, keeping things moving. My advice? Build a tangible vision of the next round of changes and socialize it until it ships.

“Just Making the Bread”

These five guidelines have helped me become a better designer over the years. I’ve found passionate R&D – “innovation,” if you will – is built on talent and core principles which can sometimes be at odds with purely financial goals. The leader of the organization must care deeply about design and the customer experience and govern accordingly. Apple is a great example of this corporate value in action.

Consistently great software design is created with a great process – not a lucky string of inspirations. That process should be very rapid and based on short cycles. The leader must have no fear in developing a deep understanding of the customer’s relationship with the product; the rest as they say is just “making the bread.”