If your team lives and loves agile, God bless you. You need read no further. If, however, your team does not follow agile practices or has found agile disappointing, here’s another idea. You can use this approach either along with agile or instead of agile. It requires no training, no reference books, no coaches, no special software, and no cutesy vocabulary. In fact, you probably learned this approach in third grade. It’s not a process or a methodology. It’s really just a habit—a disciplined reminder to do something systematically that you already do now and then.
I call this approach Lists and More Lists, or LML. The idea is simply to make lists for every aspect of a product itself, as well as the process of creating it. Everything.
Champion Advertisement
Continue Reading…
We already make all kinds of lists such as to-do lists, pros and cons, ideas, reminders, and cheat sheets. Sometimes, we make lists without even realizing it. A calendar or schedule is really just a type of list. What is a boxes-and-arrows sitemap, but a glorified list? Agile epics and stories, Kanban boards, backlogs, global navigation, content matrices, use cases, scenarios, and password requirements—all are glorified lists.
LML just turns list making into the explicit guiding principle of the entire product-creation process. I’ll discuss LML in terms of creating software, but it really applies to creating any kind of product or service. I’ll talk about product teams making decisions together, but this approach applies no matter how decisions get made.
Why Lists and More Lists?
LML calls for making lists first—before wireframes, comps, prototypes, presentation decks, or a single line of code—because a list offers the following compelling advantages over all of those deliverables:
A list is way faster and easier to create and modify.
A product team can easily argue about what should and should not go on a list very early on—before anyone wastes time producing something that would eventually get axed.
The stark, skeletal minimalism of a list demands and sharpens decision making—Does X go on the list, or doesn’t it? This incidentally forces us to anticipate implications of our decisions and think through their scope.
The very act of generating and grooming a list as a team naturally imposes a certain level of discipline on team members, helping them to stay on topic and avoid getting lost in the weeds.
When a meeting’s agenda is to agree on a list, everyone can see the upshot of their decisions starkly and instantly.
Creating lists requires no special technology. Word, Excel, Post-it notes, and Starbucks napkins all work just fine.
Even the busiest executive can scan and evaluate a list, in just a fraction of the time it would take to absorb a presentation deck or sit through a meeting.
Team members are less likely to forget to do some task that’s on a list.
Having an agreed-on list of elements to include on a page, screen, widget, form, or navigation bar focuses an information architect’s or visual designer’s efforts. You get fewer surprises.
People invest less ego in a list, so there may be fewer wrestling matches among team members.
For all of those advantages, there’s something ever so terrifying about a stark, simple list: It leaves us no place to hide. It spotlights our ignorance, murky thinking, omissions, contradictions, indecision, and procrastination. It distills all our talk into actual choices.
The 3 Principles of Lists and More Lists
There are three principles behind LML:
Each aspect of a product or project begins life as an item on a simple list.
List first, then agree, then elaborate.
Religiously update your lists, deepen them with increasing levels of detail, and split lists up as necessary.
Now, I’ll elaborate a bit on each of these principles.
LML Principle 1: Each aspect of a product or project begins life as an item on a simple list.
Having worked as a consultant with a lot of different clients, I have seen over and over that my most time-consuming and least-productive task is finding out or figuring out what to include in a project. I often ask clients to just give me a simple list such as key points in the value proposition, payment scenarios to accommodate, must-haves versus nice-to-haves, things they want to learn from next week’s usability testing, and so on.
Rarely are they able to do it. Almost invariably, they talk on and on, dwell on one thing or another, and wander down various detours. It’s not unusual for me to ask a client for a list, listen to them talk for ten minutes or an hour, then hand them a short list that I’ve distilled from their many words, only to hear, “Yes, but there’s also…” some other thing they hadn’t thought to mention.
That’s not a criticism. It’s human nature. So suppose you instead started with lists in the first place. Here are some kinds of lists a team using LML might put together:
problems in the world that your product will solve
kinds of people who have those problems
ways your product will be better than anything else out there
which browsers, operating systems, form factors, languages, currencies, authority levels, or payment methods you will accommodate
a product’s main components
functionality you intend to offer
competitors you must keep an eye on
steps in a workflow or process
options to choose among
pages or screens you expect to need
elements, content, and functionality on each page or screen
which team members make what kinds of decisions
assumptions
accessibility reminders
what is and is not in scope for the next release
questions you’d like research to answer
fields on each form
items to offer in the navigation
filters and sorting widgets to offer for search results
columns that a table must or might include
concerns that Quality Assurance should look out for
deferred decisions, issues, or features
You’re going to have to make these decisions sooner or later anyway. By making as many of them as possible up front—at least the big ones, even if only in very general and, initially, tentative terms—as you add items to a list, you pave the way for the work that follows.
LML Principle 2: List first, then agree, then elaborate.
Maybe one team member creates a list alone, in just five minutes. Maybe the whole team spends an hour coming up with a list together. Either way, once someone has drafted a list, everyone can review and assess the same concise, skeletal set of ideas at a glance. More signal, less noise.
The team can now easily focus on deciding what to add, what to nuke, what to move, and what to prioritize. Seeing seven items on a list makes it much easier to think of the eighth, ninth, and tenth items that belong on it—or to realize that the third and fifth items are expendable. Are these six tabs the optimal set? Should you accept some additional forms of payment—and if so, which ones? Or are you already trying to accommodate too many? Is your enrollment form asking for too much information, or have you left out something important?
Bad ideas and sloppy thinking stand out much more clearly when you see them in the cold, brutal context of a list. People will naturally disagree about which items are the stinkers, but lists can come in handy there, too. When colleagues strongly disagree and emotions start running high, it might help calm things down if you ask each side to make a list of their key points, reasons, and evidence. This can help cool their passions. It can also clarify the issues and facilitate decision making. The two sides might even realize just how much common ground they actually share.
Once a team has made a list, argued about it, and decided what it should comprise, the path forward suddenly becomes remarkably clearer. Now, you can flesh out the details, nuances, and implementation particulars in design sketches, wireframes, comps, prototypes, presentation decks, research plans, agile artifacts, or code. If you’re not sure what to do or what to include in your mockups or prototype, look at the list. If the information architect and visual designer disagree about what should go on the home page, look at the list.
Fussing with details prematurely is a delicious flavor of procrastination. The more details you fuss with before deciding on the big stuff, the more time and money you’re probably wasting. The time for details will come soon enough. But you need to settle on the boulders before polishing the pebbles. Once you have, the time you spend on the pebbles will yield a far greater payoff.
LML Principle 3: Religiously update your lists, deepen them with increasing levels of detail, and split lists up as necessary.
No matter how good your first draft of any list, it’s going to change over time. So update each list whenever the facts or your decisions or realizations change. Splice in new and better ideas. Weed out the things that didn’t quite work. Categorize the items in your list. Sequence them. Prioritize them. Get more specific, by providing additional levels of detail. Nest list items. Create a master list of all your lists. Be religious about version control.
The process of working from a list will reveal impracticalities, contradictions, lame ideas, and oversights. Great. Update the list. As you elaborate on a list over time—for example, by creating mockups or prototypes—you will get new ideas, have epiphanies, and set new priorities. You will hear additional views, learn new things, and change your mind. A new stakeholder with different ideas will come on board. Great. Update the list. As you give an issue more and more thought, you will realize some nuances and alternatives you had not thought of originally. Great. Update the list.
For example, one list for an ecommerce site might start out as a rudimentary set of scenarios such as the following:
Item is in stock.
Item is out of stock.
As you have more time to think that through, it will no doubt expand into something along these lines:
Item is in stock:
only the warehouse has it
only the local store has it
the warehouse and local store both have it
some are in stock, but not as many as the customer wants
Item is out of stock:
we do have a different color, size, or fabric in stock
we have already backordered more
we know when we will receive more
we do not know when we will receive more
we have not yet backordered more
the item is permanently discontinued
One or more items in this order are in stock.
One or more items in this order are out of stock.
We don’t know whether the item is in stock.
Once a list reaches an unwieldy size or an unmanageable level of detail, split it up into a bunch of separate lists. Some lists may persist as your magnetic north for the life of a project. Most will probably serve only a temporary purpose, then get overtaken by events. That’s fine. A list is just a means to an end. Once a list has outlived its usefulness, retire it.
Conclusion
There is no right or best way to implement LML. Just get started by saying five times a day, “Let’s put this in list form.” See what works out and what doesn’t. Settle into a new habit that works for you and your team.
There. That’s all the LML training you need. Give it a try.
Great article. Gets down to the meat of what any Project Manager really does: manage lists. which is also managing expectations. The one missing thing not covered that Lean Software teaches us to examine is “The Checklist.” This finalizing step makes things real and concrete. If something is a Release-to-Production Checklist Step, it must either be done or consciously skipped over. The Checklist has been shown to be the prime instrument of Airline Safety in the modern era. Think about the Checklists NASA uses for any rocket launch, and you begin to appreciate its true power.
John Boykin has worked as an information architect, interaction designer, and UX researcher, but prefers the title UX Strategist. Whatever hat he’s wearing, his objective is always to minimize users’ effort—whether to accomplish some task, find what they need, or absorb some communication. His client list includes Walmart, Macy’s, Bloomingdale’s, Bank of America, Janus Funds, Visa International, Blue Shield, Mitsubishi Motors, NBC, Symantec, and HP. John has been a speaker at the IA Summit, Total UX Summit; University of California, Berkeley Extension; and University of California, Santa Cruz. Many UX leaders use his three-minute video, “Satisfy the Cat, aka User-Centered Design,” to evangelize user-centered design within their companies. Read More
