Wednesday, September 21, 2011

Summary Hints

When we as an engineering team start implementing something new, we almost always start with a summary. This is often followed by discussion, explanation, UI designs, requirements specifications, stories, tasks, and a whole lot of other stuff. The summary looks something like this:

Create a performant dashboard that shows all the widgets and lets you frobble them.

Here is where you get your first hints about which parts of the system really matter, and which parts are niceties. If it's in the summary, it's important. It may be important because it's promised to a customer, or because they've been burned in the past by not specifying something, or because it's what makes your version different from a competitive product, or any one of a number of other reasons.

In our example summary, what's important?

  • Performant: This almost always just means "can't be slow" rather than implying "it's incredibly fast", but it also usually means that the person asking for the feature has been burned by something slow. Ask about this - performance will matter, and just saying, "it works on my fast connection with my pretty solid dev box" is courting rejection.
  • All: "All" rarely means "every single one all the time", but it does mean you'll be looking at showing a large chunk of data on the screen. This brings up fun UI and performance considerations. It usually also implies filtering, searching, and other "sounds easy but takes time to do" considerations.
  • Dashboard: This is a very common term for "our user is going to sit on this page and pretty much never leave it". Updates, reloads versus AJAX-style refreshes, etc., are all going to be considerations.
When you're hearing about a new feature, listen very carefully to the summary. It'll usually tell you about most of the major risk areas and time sinks, and it's the heart and soul of what the user really wants, instead of all the things they think of that sound good. The summary is the part that you need to get right.... and that'll give you a happy customer.


  1. Excellent hints!

    One more...

    Frobble: Often a Summary uses marketing terms (like "frobble"). Find out what these terms mean to the stakeholders, and understand what they mean to your testing efforts.


  2. Let me add to Joe's comment. Once you figure out what "frobble" means to your stakeholders, be aware of "you" that must be able to frobble according to the summary. This is a hint that the user is in charge of the frobbling. Therefore, it must be intuitive, with a high focus on usability. Basically, if a user requires a help page to find out how to do this, it's not intuitive enough.