(This is a long post but there's a special treat for you at the end!)
My favorite part of the product cycle is right before we start the development phase. For me it’s extremely exciting to work with all of the different disciplines to build a feature that will affect millions of people across the world. At this point, I spend almost all of my time working with my “feature team” composed of dev, test, design, and usability to map out how the features that I work on are going to look and behave. Today I’d like to give you some insight into the process of designing a feature inside the Windows organization.
Brainstorming
Brainstorming starts with a kick off meeting with your feature team. My role in this meeting as a program manager is to kick off the discussion with high level problems that this feature will address. Once the problems are established, we start throwing out goals and scenarios that map to those goals. In this meeting it’s perfectly okay to go off-topic and talk about the technologies we could use or individual behaviors, all of these thoughts help mold the feature. When the meeting(s) wrap up I collect all the information and head back to my office to make sense of the madness.
The "Page 1"
Once all of the brainstorming ideas have been collected, I look though all of the notes and start mapping out what’s called a “Page 1.” This “Page 1” is essentially a rough draft of the feature vision and outlines the feature requirements. This typically contains the following information:
- Overview & Scope – What is this feature and how does it fit into the overall vision of the product?
- Problems – What are the problems users or developers face in this area?
- Opportunities – What opportunities can we leverage inside or outside Microsoft to make this feature happen?
- Goals – How can we address the problems in this area with this feature?
- Non-Goals – What are we explicitly not going to address?
For me, this is probably the most difficult part of the process; it can take up to a week just to get a first draft ready. This “Page 1” essentially maps out exactly what the feature will do for a release. Once this “Page 1” is completed, it goes through multiple reviews with the feature team. This is where the program manager has an opportunity to really show what they’re made of. I’ll explain.
It’s been said at Microsoft that “Program Managers have all the responsibility but no authority.” Essentially, we can’t tell the feature team members what to do 
If a feature team member doesn’t like your decision, it’s up to you to figure out why and either change your decision or convince the feature team member to go with your plan. So, during the “Page 1” process it’s extremely important to talk to your feature team members and get they’re feedback on the “Page 1.”
Once the “Page 1” is polished and everyone agrees on the vision, it’s time to create a detailed spec.
The Spec
I love writing specs. Out of all of the things I do as a Program Manager, writing a spec has to be the most exciting and rewarding for me. When I first started at Microsoft, my specs were pretty terrible. In fact when I had my first spec review I felt like I just got an F on a paper for school and had to go back to re-write it! Of course, your spec writing only gets better over time. You learn what your feature team likes to have in a spec and you do your best to add as much information as possible.
There are two types of specs on the Windows Shell Team – a “Feature Spec” which outlines the UI look and behavior of a feature, and a “Developer Design Document” which outlines the technologies used for the feature as well as implementation details. Program Managers write the former.
When I write a spec, it’s important that I capture as many details as possible that describe the UI and behavior of a feature. The spec is extremely valuable for the developer and the tester. The developer will use this spec as a guide when building the feature and the tester will use it to create test cases for the feature. I like to take the top-down approach where I layout the overall plan, then start breaking the feature down into little details. I also put myself in the tester’s shoes (because they are the ones that find the holes in your spec) and try to come up with as many relevant issues as possible. Here are some examples:
- Does this feature ship down-level?
- What does it look like when it runs with Visual Styles?
- What does it look like in Classic Color Scheme?
- Is it Accessible?
- What are the keyboard shortcuts?
- What are the MSAA properties?
- How does it respond to High Contrast?
- How does it respond to High DPI?
- What is the minimum screen resolution it will work on?
- What does it do in low memory conditions?
- How does it look in Right-To-Left (RTL) mode?
- Are there any security implications?
- Are there any cases where you would want to display any error messages?
- If so, what are the error messages & what caused them to appear?
- Does this feature change based on SKU?
The other set of questions I ask myself all relate to the customer:
- Who am I building this feature for?
- Could a novice user use this successfully?
- Is it good enough for the power users?
- Do we offer any ways for the power users to customize it?
- Can a person with a vision/hearing/speech/motion impairment use it?
During this process it’s extremely important to involve the feature team to get constant feedback on the spec. I want to nail as many of the details as possible before it goes off to a review. I find I get the best feedback from my tester. If my tester likes my spec, I know I did a good job. Once I collect all the feedback on the spec, I send out copies to my feature team and we spend time reviewing every bullet point to catch anything I missed. I iterate on the spec until I’ve answered all the open issues and the spec is in a “stable” condition.
Building the feature
When development starts on the feature, this is where the spec can start to break down. Program Managers do their best to keep the spec up to date with any behavior changes or removing any ambiguity, but it’s hard to do that over time. Eventually when you’re in bug fix mode, the code becomes the spec. Right now we’re fixing bugs for Vista. Every day we make decisions based on bugs that comes in and most of the time those decisions don’t get reflected in the spec. It’s not important that the spec stays up to date as long as the information on that decision is recorded somewhere. In this case, the information is recorded in our bug database for us to refer too in the future.
A special treat
If you made it this far through this post I have a
special treat for you. For the first time at Microsoft (that I know of),
I’m posting a real feature spec to give you some insight into what our specs look like. This particular spec is for Aero Wizard. It’s one of the earlier specs that I wrote so if I’m missing anything try not to hold it against me
It’s been a very long time since I touched this spec so it may be slightly out of date, but you get the idea. This particular spec is for the Windows Platform, so it’s written slightly different than a typical UI feature in Windows.
Hopefully this will be the first of many specs that we share with the Windows community! Enjoy!
Links: