Finding Simplicity Through Thoughtful Reduction

I’ve been spending a lot of time over the past few years thinking a lot about simplicity. Simplicity is one of those things that we mention a lot in passing, but it’s also something that we don’t dedicate much effort to achieving.

We develop software where 60+% of the functionality is never or rarely used. We focus on feature-matching the competition while we neglect listening to our users. We litter our presentations with excessive bullet points instead of focusing on our core message. We write user manuals that rival Atlas Shrugged because we’ve failed at providing usable interactions.

By nature, we tend to add when we should subtract. Evolution has plagued us with reactions that promote complexity and avoid clarity. When we create, we focus on building more – but when we consume, we tend to find the most joy out of having less.

How do we make a conscious effort to find simplicity in a world of complexity? Well, to start, we can start to think about thoughtful reduction.

Thoughtful reduction is an extremely powerful tool in our quest for simplicity.

The next time you are faced with an opportunity to improve or modify your process, or your software, or your life – think about what you can remove instead of what you can add. Take a little extra time to remove root causes instead of adding workarounds. Think about how to communicate more clearly instead of how to communicate more. Think about the things that you can stop doing instead of the things that you can start doing.

When we remove the non-essential then we end up with a stronger focus on the truly essential. Find the core of your application, your message, your purpose – and take away the rest. You might not end up winning the feature-race, but you could find a beautiful product and a renewed sense of focus.

Subcycle Labs Multi-touch

I’m not sure how to describe this, but I love it…

You can also find the video on Vimeo.

Subtraction

Speaking At Agile Carolinas

I’m going to be speaking at Agile Carolinas on May 21st (this Thursday). My topic will be: Adopting a Whole-team Approach To Quality

The talk includes some discussion of testing, but it is mostly centered around figuring out how to deliver great software.

If you’re in the area, stop by and say hi.

I’ll post the presentation here after the talk.

The presentation is embedded below. If you download the presentation, it will have a summary of what was discussed in the presenter notes.

Modeling vs. The Model

It’s interesting to me how much people rely on formal tools for modeling. I frequently talk to individuals that tend to assert that just because a model is made in some modeling tool (like Visio) that it is *right* or at least superior to whiteboard sketches.

The Visio fan-boys and fan-girls seem to snicker and generally doubt the effectiveness of a sketch done at a whiteboard. Why is this?

Is it because of the appearance? Is it the lack of gradients? Is it the lack of the drop shadows? Is it the lack of the standard company logo in the upper right-hand corner? Is it because of how straight the lines are?

My view is exactly the opposite. If I had to summarize my stance, I’d say that the straightness of the lines has an inverse effect on the understanding of the problem.

In my experience, most of the models created with modeling-tools are done by one individual. If others collaborate on the model, it’s usually in a serialized fashion. It’s “tossed over the wall” to someone else who follows a similar process. It’s also my experience that many people spend more time worrying about the polish of how the output looks than spending time thinking about what is being modeled.

Contrast this to a whiteboard-session:

When a model is explored on a whiteboard it’s usually done with more than one person. It’s usually done collaboratively with at least two participants, a variety of view-points, and it’s iterated on quickly. Because it’s being done collaboratively, it also frequently results in break-through ideas or understanding.

Unfortunately, the modeling tools also tend to focus our attention on the output, not the creation of the model (where the real learning occurs).

It’s important to remember that the modeling, learning, and understanding is what provides the real value, not the model.

Photo courtesy of Doc Searls.

User Stories For User Experience

I’ve always found it interesting how a simple change in semantics can make a huge difference for a team. One area that I’ve been thinking about for a while is the structure of user stories.

In it’s basic structure, a user story follows the format of:

Most teams (at least in my experience), use the format:

An interesting assumption of this format is that we know what the feature that we will be implementing should be.

In many cases, this format neglects the tasks of taking some time and dedicating some effort to think about a suitable implementation. In some cases this might be ok (commoditized software, maintenance modifications, a thorough understanding of the solution space, et cetera). But, in cases where we are innovating or focusing on providing a differentiated user experience, this assumption can lead to a me-too product or mediocre software.

In the event that we need to think a bit about the solution, I’ve found it very useful to change the story format to be goal-oriented. My recommendation is to use a slightly different format:

This is a minor modification, but it certainly changes the focus.

The goal-oriented story format encourages empathy, understanding, and exploration. When we are in a situation where we are focused on delivering an optimal experience to our users, I think that the latter format is appropriate.

Your Users Don’t Know Best

You don’t build great software by putting your users in the driver’s seat. Techniques that focus on asking users what they want in your product or asking users to “vote” on the functionality that they would like to see in your product are recipes for mediocrity.

Don’t ask your users what to build. Instead, focus on understanding what your users “do.” Know the goals of your users, understand what they think, how they interact, what they do in their time-off, and understand what their life is like on a day-to-day basis. You can’t get this information by disconnected feedback, you have to get it face-to-face, side-by-side, through direct and unbiased observation.

Everyone who designs, develops, tests, and manages software products should be spending time with their users. Be an apprentice, observe your software in use in a natural environment, pay attention to the psychology and interactions – then you will understand what needs to be built.

Every interaction with a user in their natural environment will leave a lasting impact in how you understand your users and guide your product.

Wally Wood’s 22 Panels

If you are having a hard time putting together compelling presentations then a great source of inspiration is to look to Wall Wood’s 22 Panels.

The 22 panels are great inspirations for help in designing your slides to tell the visual story of your content or ideas.

TIB #22: Use An Exchange Program

If you are working with a distributed team, especially if that team is offshore, you should implement an “exchange program” to bring remote people together. The phone, email, instant messenger, and other similar tools can help with collaboration but they don’t have a fraction of the power of face-to-face communication.

Do you work with people in India? Then go to India. Do you work with people in the China? Then go to China.

Making eye contact in a high-bandwidth environment can do wonders for teamwork and cohesion. In addition to the face-to-face time there is also the understanding and feeling of culture. Culture provides the basis for viewpoints and actions and without understanding the culture of your co-workers, how can you ever understand them as individuals?

As you make your budget for your project, always remember that your best tool for collaboration is a plane ticket.

TIB #16: Listen To Nature

Nature is often neglected as a source of inspiration. There are many opportunities to look to nature to find solutions to our problems and inspiration for our thoughts.

Our minds and our thoughts are often shaped and blinded by growing up as children of industry. There was a world that existed before industrialization and there will likely be a world that exists after our impact is felt on this planet.

The next time that you look to any of the standard clichés that tend to rule our thinking – try looking to nature and see what you can come up with. My guess is that you will be surprised in what you find.