Clint Covington: Software design, Microsoft Office Access : Shipping Software

Good writing tips for developers forced to write marketing content

Clint Covington — Fri, 01 Jun 2007 21:38:00 GMT

There is a good article on A List Apart about how to generate interest and describe the business value for software. What I like most is the use of examples.

A lot of web copy is written by copywriters who aren’t trained in writing for the web—and much of the rest is written by people who aren’t trained writers at all. If you’re a designer who can consult intelligently on basic copy improvements, you can gain a substantial business advantage. This article is designed to help you do just that.

http://www.alistapart.com/articles/whoneedsheadlines

This article targets web designers but all of us who work in technology can benefit from the discussion.

Adds/cuts uncovered: The making of a new release

Clint Covington — Sat, 10 Mar 2007 10:39:00 GMT

This is a fun time to work at Microsoft and particularly Office. One of the biggest benefits of working in Office is the opportunity to interact with some of the most experienced and proficient software talent in the world. Internal at Microsoft, the Office development process and its leadership are held in high regard. The company recently moved many Office managers into the Windows organization to cross-pollinate the rigorous Office process is that part of the company. I’m confident Steven Sinofsky will do a great job—he and his team are the best around!

Vision, specs and features

The last few months the team has been iterating on different vision alternatives and working hard to craft a release that is most compelling to customers. As with every release, we always come up with far more ideas than we could possible complete without turning the product into a Frankenstein bug farm and the release into a dreaded death march. The project I’m working on (it’s not Access) has really some cool opportunities to change how people work with data in exciting ways—figuring out the schedule is fun and painful. Let me explain…

Our team is using the Access Projects template and SharePoint to put together a detailed plan of specs and features (I might blog about the database later if people find that interesting). Developers are deep into architectural design and figuring out costs and working with PM to draft spec names and features for each spec.

The first step is to put together SWAGS. These are wild guess at the number of developer days it would take to write the feature. Every week we are working to break down big estimates into smaller costs and tasks. Each spec and task are assigned a priority of 1, 2 or 3 (three’s always get cut). Along with breaking out costs developers are also working on SP bug fixes, improving the quality and maintainability of the code base, and playing with new prototypes. Yeah, I have seen some cool demos that last couple weeks—it is fun to walk around the develop halls and here “hey Clint, I have something to show you.”

Program Managers are busy working on visual click-through, doing customer research, arguing respectfully about vision directions, and writing one page specs. These are simple documents that describe chunks of work from a customer and scenario perspective. We also try to describe what the feature isn’t going to be.

Balance a schedule that overflows

As part of figuring out our schedule we put together project rollup reports. These rollup reports break the project into investment areas (categories) so that we can get an idea of investments for big bets. The team always generate more specs and features than is possible in 2 releases. Cutting that list back is hard. We always start by reflecting back on what the vision and customer scenarios. The first few cuts are pretty easy—we always have ideas on the schedule that would be cool but don’t tie into the vision, carry extra risk, or don’t address a broad enough customer need. The hard part comes several weeks into the process when you are 30% over and have trimmed things back.

There are four ways to balance a schedule after you have trimmed all the fat:

Cut a big area. Oh this is painful. The area is always interesting otherwise it still wouldn’t be on the schedule.
Cut all P2 tasks. With this strategy you cut of fingers but keep the body in tack. This strategy cuts everything that isn’t vital but keeps all the big bets on the table. The problem with this approach is it leaves you with zero wiggle room. When things take longer than first anticipated (and they always do) the team is left with tough decisions.
Code longer and test less. This is a scary way to move forward because it puts your project at risk of not having enough time to fix bugs. Customers typically don’t appreciate buggy, slow, or unsecure software. The last thing you want to be is a coupon in the box because you didn’t have time to finish it—that is what happened in Access 95 and team members still tell vivid stories.
Move the schedule out. This isn’t an option if you ship in Office. These days, I prefer to ship more frequently and iterate based on customer feedback.

The only way to balance a schedule that over booked is to break out the ax and make deep, swift cuts. Look for items in the schedule that aren’t required for the vision and introduce the most risk. It takes courage to avoid the temptation of hiding work items from the schedule or cutting all your P2 features. Both of these approaches chew into the schedule safety net and introduce risk.

When you make deep cuts don't plan on reheating it for a future release. The process needs to start all over again with identifying customer scenarios that drive break-though innovation. The next release needs to encompass ideas that are far bigger than your previous cut list.

Today, we cut some features I would have LOVED to ship. They weren’t required for the vision and just didn’t fit into the schedule. Those meetings are painful but super helpful in focusing resources on what is most important. In the end, it is more important to ship key break-through innovation than lots of mediocre features.

Open and respectful cultures create better designs

Clint Covington — Sat, 17 Feb 2007 17:37:00 GMT

It’s not uncommon in the halls of Microsoft for a passionate Program Manager and brilliant Developer engage in verbal combat over design ideas. Anyone that has worked with talented people on a tough design problem knows that innovative design is hard—really hard. It takes passion, commitment, and willingness to explore new territory.

Often, throughout the creative process, there are tense conversations as both sides argue rational perspectives. Key to moving innovation forward is the ability to see the value of another perspective. Win/lose conversations rarely benefit the process and impede innovation. In order to understand why conversations turn win/lose, consider external factors that create tension. Things like…

Different interpretations of the project vision and target customers.
Different perspectives of customer needs.
An incomplete understanding of the idea or proposal from either party.
Power struggles.
Emotional insecurities that lead to a driving desire to be right and valued.
The “Bozo Bit” (named after Bozo the Clown, someone has the Bozo Bit if he carries credibility issues from one project to the next).
External pressures that a party chooses not to reveal.

Language that creates a “loser” is usually leads the journey down the acrimonious path. For example,

“No, you should think about it like this…”
That is not true…”
“That feature will never work because…”
“Customers will always…”
“What you need to do is…”
“Everyone will find this useful…”
“That idea is a problem.”
“You can’t…”

Win/lose situations rarely foster the creative process. I’ve found that a “Loser” tends to hold back fresh ideas in future conversations. As the competitive landscape heats up, good ideas aren’t explored because both sides are entrenched on winning, even the most insignificant battles.

Use Inclusive Language

I have found a solid design strategy avoids a polarized position. The first step is to adopt an open and respectful tone and manner, for example:

“Tell me about…”
“I agree, have you considered…”
“How will the feature work with…”
“What motivates customers to…”
“Who is the target user for this…”
“For many customers that is important, …”
“There is a grey area…”
“I agree with you on A, tell me more about B.”
“Have you thought about…”

Basically, try to understand the other perspectives—even restate positions to confirm you’re both on the same page. Also, search for common ground by talking about elements of the design that you both like.

Ignore Polarizing Language

When I hear polarized language, I try not to react. It’s hard to let polarized statements go without a good fight and just outright frustrating to hear people take positions that aren’t correct. The key is to control your reactions. The easiest way to deflect is to use precision questioning to guide the discussion away from the inaccuracy. If someone needs to be corrected, evaluate if it’s better done in private so that the constructive feedback isn’t taken as a public flogging. Again, take the time to better understand other perspectives.

Focus on your Target Customers

Clear vision statements, guiding project principles, and customer definitions are great tools that can clear confusion that causes design debates. If your project doesn’t have a clear vision statement that clarifies priorities, it’s easy for people to argue correctly for design A or B. If you have clarity about the customer and project priorities, it becomes easier for both parties to refer back to the original documents as the guide.

When conflict arises, talk through the customer scenario—get agreement on what is essential for the users of the product. Recognize that different customers have different needs and engage in conversations about the requirements of the different customer segments and how the design impacts them. Focus on what you like about both alternatives. Many times the best design is found in between polarizing positions.

Coach Others

As a team leader, I’ve coached others on these principles when I observe behavior that suffocates the design process. I’ve discovered that people really want to do great work and that in the end, humility in the workplace is respected.

Open and Respectful Culture

At a company meeting years ago, Steve Ballmer talked about the challenge of creating an open and respectful work environment. I think the quote went something like, “While the comment, ‘That is the stupidest idea I have ever heard’, might be open, it’s not respectful.” Just as Microsoft continues to work on its open and respectful culture, so do all innovative design teams.

So my call is to RAISE THE BAR. When someone has a good idea—step up and acknowledge the idea and sing praises. Also, step up and fight hard for the right design, and do it in a way that others can contribute. Finally, step up and ignore inconsequential statements to gleam golden nuggets from even the most off-beat, scatter-brained ideas. The design process is about cultivating relationships with other teams that are open and respectful. It’s about being willing to give up a good design for a better design. It’s about avoiding political battles or attempts to discredit co-workers out of self interest. It’s about understanding different perspectives, then parsing good and not-so-good ideas into GREAT design.

Tell me, does this philosophy match your experience?

7 Rules for Productive Brainstorming

Clint Covington — Sun, 21 Jan 2007 15:03:00 GMT

Yesterday I was kicking around campus, dropping off fliers about my wife’s resume service on bulletin boards. My 3-year-old loves to go to work with Dad and drink chocolate milk, write on the whiteboards, and play chase through the halls. Anyway, she starts drawing on a whiteboard in a conference room, and I notice seven large cards above the whiteboard about brainstorming. As someone who does a lot of this, I found these rules quite good.

Encourage Wild Ideas

Like mutations, they keep evolution moving

Defer Judgment

Silly ideas lead to good ones

One Conversation

This is not a free-for-all

Move On

Get it out and captured, then search for new ground

Build on Ideas

Stand alone solutions won’t do us much good

Stay Focused

Remain within the boundaries of the problem

Get Physical

Create a record with works and pictures

My favorite rules are to Encourage Wild Ideas and Move On. Many times I find we box ourselves into a particular solution too early, without exploring non-obvious solutions. One of the most common interview problems I see in potential candidates is fixating on one solution and limiting vision because they think they have a solution too early. In creative problem solving, push the boundaries, explore ideas and give them a chance to mutate. Don’t be afraid to spend some time thinking about the opposite perspective and looking at it from different angles. Identify what you like and move on.

Some ideas work well and others won’t. Keep what seems to work and look for new ground. Early in the development cycle is a perfect time to explore different solutions and try things out. Some elements of the ribbon were inspired by a couple outlandish proposals about how to make Access easier to use. We take lots of crazy ideas into the usability lab looking for things that stick and resonate with users. Most of it is left in the scrap yard but some ideas pop.

Most important—don’t be afraid to take big risks. When the user experience team started talking about the ribbon most people thought it was a crazy idea. Nobody could see it in its current incarnation but a small group of passionate and driven people gave the idea a chance to grow and mutate. I think it is fairly safe to say the ribbon is a huge improvement from what everyone thought was the best way to surface commands--that wasn’t the conclusion in the early in the development process.

BTW - I'm working on a post about forms design. If you have any tips, rules, guidelines--send them my way!

My favorite software book of the year "Get Real: The smarter, faster, easier way to build a successful web application"

Clint Covington — Sat, 16 Dec 2006 21:42:00 GMT

For some time I have been a fan of the work done by 37Signals. They have a great understanding of the value of building simple software that people fiind useful. They recently self published Get Real: The smarter, faster, easier way to build a successful web application. This book is the best book I have read this year about building software--it is a good reminder of principles to follow when designing software.

I especially liked their section on Feature Selection. In a nutshell they believe in keeping their software simple and usable. They talk about saying "no" to new feature requests that don't maintain the voice of the software. This book does a good job making you think about the hidden costs of new features, including proper usability testing, documentation, testing, fixing bugs for years to come, and most important interface clutter. I especially liked this quote:

Each time you say yes to a feature, you're adopting a child. You have to take your baby through a whole chain of events (e.g. design, implmentation, testing, etc). And once that feature's out there, you're stuck with it.

This is particularly interesting to Access applications because it is so easy to add new features to your app. However, every table, form, query, and report have hidden costs that aren't as obvious.

This book is filled with short passages that ring true to anyone who has build software. Not everything they write about is applicable for a large product like Access but it is spot-on for many Access apps. I’m going to encourage all the program managers on my team to give it a read.

You can get the book in PDF, online, or paperback: http://getreal.37signals.com/.