William Gill

In the 1970’s renowned German designer Dieter Rams defined ten design principles that embodied his view of design and product development.

He said:

1. Good design should be innovative.
2. Good design makes a product useable.
3. Good design is aesthetic design.
4. Good design makes a product understandable.
5. Good design is honest.
6. Good design is unobtrusive.
7. Good design is long-lasting.
8. Good design is consistent in every detail.
9. Good design is environmentally friendly.
10. Good design is as little design as possible.

Timeless.

(The translation is mine from the original German, but I’m sure there are countless others, including on wikipedia.)

You can download the image above as a desktop wallpaper in English or the orignal German.

Stop signs are always red. Exit signs are green. Play buttons are triangles. These are patterns and norms that, when appropriately leveraged in a design, can help communicate expectations and function. It doesn’t matter if you are an interface designer working on a software UI, a software engineer writing code or a manger preparing a powerpoint presentation: consistency is important.

What consistency is not, however, is copy + paste. As a great designer on the maps.nokia.com team said in a design review recently: “Consistency is not a rubber stamp.” It’s not a cookie cutter. It is a careful and thoughtful association between what you are doing and the user’s current knowledge. In other words, the question to ask is: “will this design allow my user understand what they need to do or what I am trying to communicate to them, given their experience, knowledge and understanding?” Two elements of a system can be consistent with each other without being the same.

Consistency for consistency’s sake (or, on other words, forcing total consistency at the expense of function) is a design crime of an similar magnitude.

Rather than asking the question: “is this consistent?” – ask the question: “will my user/reader/audience/etc easily understand, given their context and knowledge?”

As Emerson famously pointed out:

“A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines. With consistency a great soul has simply nothing to do.”

What’s the difference between a cheetah and a gazelle?

One is the hunter; the other, the hunted. One stalks and sprints with total precision, unwavering focus and ultimate confidence. The other flees in uncontrolled panic.

When we’re exposed to pressure within an organisation, it is normally in the form of a risk or a threat: the risk of losing a big client; the chance we won’t get funding; the fear of losing our jobs.

The fact is that all mammals, including humans, are really good at panicking. In fact, we’re designed for it. Buried deep inside the oldest part of our brain is a brain region called the limbic system. In evolutionary terms, the limbic system existed long before we first picked up a rock and used it to hit something. It’s the part of our brain responsible for basic survival; it’s the part that takes over when we’re scared, angry, lusting for revenge or when we’re threatened.

When we feel threatened, our limbic brain sends some signals to a part of our central nervous system called the sympathetic nervous system, which activates the so-called “fight or flight response”. Our conscious brain (the cerebrum) more or less shuts down and the limbic brain takes the wheel. It will decide whether we flee or whether we fight.

This is the response that leads us to panic. But when we panic, we lose focus. All our effort goes into outrunning the cheetah… but a gazelle can’t eat, drink or make baby gazelles when it’s fleeing a chasing cheetah.

If we spend all our time running, we don’t focus on the important things. We might increase speed but we end up losing velocity.

We all have many reasons to panic… The market is moving quicker than ever. Markets and industries change and heave, companies rise to incredible heights or crash to the floor in a fraction of the time of 20 or even 10 years ago. We have to move with urgency if we want to keep up… but urgency isn’t panic.

Urgency is controlled. Urgency is precision, focus and confidence.

The Valley’s preeminent conference for Location-based services, Where (formerly Where 2.0), was on again at the start of April in San Francisco. The usual suspects were in attendance, with the likes of Google, ESRI, MapQuest and Foursquare holding prominent positions on the exhibition floor and presenting several keynotes. I was there of course with Nokia Location & Commerce, representing our Where Platform and location applications portfolio and our flagship product Nokia Maps.

Many of the themes of the presentations were covering similar material, I noticed a few main themes coming out of the presentations in general.

Open Street Maps and other alternatives to Google Maps

A common discussion was around the alternatives to the Google Maps API as a location platform for online and mobile applications. There has been lots of talk recently about Google’s decision to charge services for extensive usage of the location API, and many organisations are searching for an alternative. Open Street Maps, although not present at the conference themselves, were talked of often as “the” alternative to Google Maps. Although many other paid and free alternatives exist, including Nokia’s Nokia Maps API, OSM seemed to be by far the most talked about.

Custom Maps and open map data

A trend is emerging around creating custom maps. Products like Mapbox are providing products that let you literally build your own map. Using Open Street Maps data, Mapbox lets you design/customise everything about the map design: labels, colours, catographic elements, zoom levels and everything else. They then not only provide the completed map, but even make it into tiles and host them.

The takeaway is that there is a trend emerging whereby people and organisations are placing much more value on the map design itself in terms of building or customising a product or service. Even as we see visual developments in the map design and style of the major map platform providers (like the recent visual updates on the Nokia Maps map style), we’ll see in the future countless different map styles and designs; customised both for differentiated visual appeal and also for the product or service’s specific use case.

Layers are dead

After the very first Google Maps “mash-up” emerged location-based services focused heavily on placing data on a map. Whatever data you had, if it had a location, you could suddenly turn it into a layer on a map. Most experiences visualised all the location data as “pins” on the map layer. Other visual techniques emerged such as heatmaps or clusters, but essentially it was just like it’s real-world equivalent: a collection of pins on a map.

What is becoming clear now is that just a layer of data on a map is neither new nor innovative. Innovative location services will not just focus on collecting location-based objects, but will focus on utilising location as an object attribute to create smart and meaningful connections between these objects, and to use them to create compelling experiences. Further, when it comes to mobile, it is no longer enough to use the user’s current position to put the user in the middle of that layer of data that you’ve put on the map. Experiences need to use the current position to further contextualise a hyper-relevant experience based on the user’s location, friends, history and profile.

“Engineering Serendipity”

Serendipity has been the perennial favourite buzzword in the valley since the start of the Foursquare/checkin era. This year the talk was around how to use the wealth of location-aware activity data streams available via services such as Foursquare or Facebook Places to create meaningful online or mobile experiences that enhance real-world experiences. One such service, Meet Gatsby, is using Foursquare checkins to introduce people to each other who are nearby each other and share common connections or interests.

Everyone seemed vaguely aware of the obvious paradox in “engineering” serendipity: the deliberate, conscious attempt to spark or even force spontaneous events…

Like a local

Everyone wants to feel like they’re a “true local”. That’s a promise we’ve been trying to fulfill with Nokia Maps for over three years. Now, the trend has hit the mainstream more than ever with tons of startups focussing on building experiences that combine user’s local knowledge with their location, profile and social graph to provide local place recommendations, directions and stories.

These services will build on the successes of products like foodspotting and Yelp to harness the power of the crowd to collect stories, photos and moments that allow people to see the world around them through the eyes of the locals. Review services like Qype, Yelp and so on have of course been around for ages… new services will combine reviews and photos with social connections and user profiles to provide better recommendations of places and things to do. We also see other services coming up that don’t focus specifically on place discovery: services like Lumatic, which focuses on providing contextual, natural pedestrian directions using photos, landmarks and stories as the essential wayfinding descriptions.

As mentioned above, the success of these products will be based on much more than building a huge database of content: content itself will not be enough. Successful services will augment various content types with social, location and activity information to provide more meaningful, immersive and contextual experiences.

Big Data

As the available public and private datasets become ever-larger, crunching the data to find the meaning and connections is key. As such, a big focus has been on dealing with large datasets. Specifically, Hadoop and Pig were talked about a lot.

Factories must be awfully dull places. Factory workers working on a production line follow a strict process. Work is divided out into narrow and highly controlled portions. The guy working at machine #1 is an expert at machine #1, but not at machine #2 or #3. But that’s ok; if he stays focussed on his machine, the production line moves on and many widgets will roll off the end.

Factory workers take a given process or specification and assemble it. That the solution is provided is a given. There’s no room for initiative or individual innovation on the factory floor. If one machine doesn’t produce output of exactly the right type at exactly the right time, the system breaks down. Process improvement and innovation is for senior managers; observing the factory floor below from an air-conditioned room behind a wall
of glass.

In the early 1800s the factory revolutionised the production of goods and heralded the onset of the industrial era. It raised millions of people from poverty and created countless jobs (and millionaires). It brought about a new kind of competition: one fought along the bottom line. The problem with the factory is that the race to the bottom is over: we hit it long ago. When every factory can produce widgets as cheaply as you can (or cheaper), your ability to differentiate lies elsewhere – it’s not enough just to be able to sell widgets cheaper than anyone else.

Luckily in the software product business we’re not factory workers. We encourage individual initative. We challenge our teams to help us improve our processes. We believe that innovation can (and should) come from anywhere.

Right?

If that’s true, why do we keep treating our teams like factories, and our people like factory workers? Why do companies push solutions to teams and expect them to be just assembled, (where possible by yesterday), without asking too many questions or making a fuss? Why do organisations rebuff any innovation or ideas that don’t come from their own team? Why do we incentivise teams and individuals on the quantity of output, and not the quality or impact?

It’s not enough to talk about supporting innovation and encouraging initiative… our daily working process has to support it too; otherwise, we’re just another factory.

The creatures, great and small, that exist today exist because they, and countless generations before them, each underwent tiny, microscopic changes that made each generation just a little better, stronger and more durable than the last. Each generation was a measured experiment, and every change was measured against the context of its environment. Those that worked were carried through to the following generations. Those that weren’t died out.

The more generations you have, the more opportunities you have to experiment, change and measure.

A horsefly or a flying fox cannot easily control how many generations they can produce in a given time. As a software product designer, though, you can.

Release early, release often. Measure. Repeat.

No animal is alive today that developed all its characteristics within one, three or even 100 generations.

Human beings are naturally complicated creatures. We live complex lives and we interact daily with incredibly complex systems: office politics, personal relationships, government bureaucracy… we are surrounded by complexity. The reality is, though, that much of this complexity need not exist at all.

When humans look at problems, we have a tendency to look for the most complex solution to that problem. I think complex solutions to problems arise when:

• We do not actually understand the core problem we are trying to solve.
• We are trying to solve too many problems at once.
• We design separate solutions to related problems that are not compatible with each other.
• Often, the complex solution is easier to design than the simple one.
• We are humans… we feel a natural sense of achievement when we create something complex.

(A more pessimistic or controversial reason might be that we sometimes develop complex solutions to problems, either consciously or subconsciously, as a defense mechanism: that is, we think that if we can show that our job is complex, we can become indispensable… in other words, we use it to justify our job/responsibility/existence.)

The problem with complexity is that it’s expensive:

• it’s expensive to build
• it’s expensive to maintain
• it’s hard to learn – for users and for developers

As product creators we need to find the simple in the complex. Simplicity is so much easier: less code, fewer mistakes and a lighter learning curve.

Your value as a creator of meaningful things is in how simple you can make it; not how complex.

“Being Agile” is more than following a checklist. It’s more than following the Scrum or Kanban handbook (in fact, it doesn’t even matter if you’re “doing” scrum or kanban at all!). Being an effective and productive agile software development team is about understanding and believing in a set of values, practices and principles.

Starting with our engineers, we tried to boil these values and practices down to a handful of core ideas. We wanted to share a common language and have a common set of checkpoints where we could track and assess where we are as a team, and give us guidance on where to focus to help us get better. We created what we call the “Agile Sliders”: a set of 6 guiding principles and practices for agile engineering teams.

1. Code Quality
2. Unit Testing
3. Acceptance Testing
4. Self-Organisation
5. Pair Programming
6. Code Ownership

Each principle exists on a scale representing a journey to an ideal state. In every retrospective we assess our progress against these scales. Did we get better? Stay the same? Get worse? The point isn’t so much to score ourselves, but it is a trigger for a conversation, and a tool for the team to use to challenge themselves on their journey.

We have also found that we can view progress from multiple viewpoints:

1. The team as a whole, and
2. Individual developers.

We’ve had some success linking these principles not only to team targets, but to individual performance targets as well.

We constantly iterate on our “sliders”, and we love feedback. Please leave any thoughts in the comments. I would like to expand the set of sliders to cover Product Owner and Experience Designer roles.

The Agile Team Values Poster

Here are the 6 principles and practices in a poster form. Click the image below to download a larger version suitable for printing. You are welcome to print it, change it, make it better!

I’m often asked for help putting together a job description for a Scrum Master, so I thought I would post an extract of one we’ve used recently.

We are a product team of developers, QA experts, user experience and visual designers and product owners who are looking for someone to help us get better at what we do. We’re pretty good at the basics of agile software development but can always use new ideas about how and where to improve. We’re less concerned about what it’s called (Scrum/Kanban) and much more excited about results, whether that means moving towards continuous deployment, using ATDD, or seeing our active users grow.

You are someone who leads by example rather than by dictate and you know how to bring out the best in people. You’re not afraid to deal with conflicts. You know when it’s good to say “No” and when to push for more results.

In addition, we’re looking for someone to act as a galvanizing force for our whole wider team in terms of sharing Agile knowledge across the company. Whether it be organizing 1-day open spaces for our agile community, or organizing cross-team workshops, the goal is for you to establish an Agile center of gravity around our team.

Your main responsibilities will be:

1. Act as Scrum master for 1-2 scrum teams with a focus on guiding the teams towards improving the way they work.
2. Facilitate sprint planning, retrospective and sprint demos
3. Assist the product owner with keeping the backlog groomed
4. Ensure cross-team coordination
5. Reach out to the larger company network for impediment removal
6. Maintain relevant metrics that help the team see how they are doing
7. Coach and mentor other scrum masters in our product team. Ensure that our ways of working are consistent across the teams.
8. Liaise between the developers and User Experience/Visual Designers. Foster better communication between the disciplines.
9. Act as a project manager when necessary. Take responsibility for managing dependencies between our team and third parties or between our team and other scrum teams.
10. Strengthen the presence of our team as an Agile centre of excellence. Actively contribute to the company’s Agile and Lean Community. Keep the rest of the company network aware of our activities.

Qualifications:

1. Knowledge of the software development life cycle
2. Certified scrum master/scrum practitioner
3. Knowledge and/or experience of Kanban
4. Excellent communication skills in English in written and spoken form
5. At least 3 years experience working in an agile environment, preferably in a variety of situations

Feel free to use this, re-use it and copy it. I hope it’s helpful!

What would you add to make a better Scrum Master job description? Share your tips in the comments.