Jon Plummer

Michael asks:

Once you have a variety of potential solutions/designs how do you know which one(s) to choose to iterate on and which ones to discard?

The ideal concept is something you can make without too much difficulty, delivers the intended benefit, is intelligible, leaves you open to future improvement, and has a ready way of witnessing success.

Typically you’ll be working on a team with (or at least have a high level of contact with) someone in charge of the product (a product manager, usually) and someone in charge of engineering (a software architect or software engineer, usually) – with design this group forms the “product trio.” Each person on the trio has expertise in or evidence for some of the criteria by which you might evaluate concepts. With these in mind the negotiation of which concept (or what parts of which concepts) can begin. For example:

UX – Is this concept intelligible to users, i.e. do they understand it and believe that it will deliver the desired benefit? Will this concept create a pleasant experience for the people we hope to serve? Does this concept use familiar interaction paradigms? Is this a concept we can build on later or will it need to be scrapped to add functionality? Can we partialize this concept if we need to reduce scope? Will we be able to detect whether or not people are successful in using it (e.g. by counting orders or conversions of some kind, or some other measure of user outcome)? Etc.

Product – will this concept deliver the intended benefit? Is this concept strategically relevant? Does the cost/complexity fit our appetite to do the work? Does it seem intelligible to customers (who might be distinct from users)? Can we partialize this concept if we need to reduce scope? Can we add capabilities to this concept to improve it in the future? Will we be able to detect whether or not use of the concept is helping the business (e.g. by counting orders or conversions of some kind, or some other measure of business outcome)? Etc.

Engineering – is this concept feasible? Does it use data we have available or can get readily? Does it use technology and services we are familiar with or can learn readily? Does the cost/complexity fit our appetite to do the work? Does it lead us into an area we want to develop technically or to strengthen existing capabilities? Etc.

You can see some overlap. For example, the appetite question is PM + Engineering, for example. Customer and user intelligibility is PM + UX. There are others.

In an individual case study lacking these team members you will need to guess at some of these, or at least reveal your thinking about your concept selection.

• For the first time in several weeks I did not type “weekly winds.”
• Quarterly coaching/reviews are done. Annual merits are done. Things are almost in place for a productive offsite meeting in about a week’s time. Everything’s coming up Millhouse (except that the product has plenty I’d like to change or fix, not unexpected).
• I received good feedback this week from one of the people I support, indirectly through my supervisor. That’s nice.
• I used a power bar rather than a deadlift bar to deadlift this week, and it was fine. The knurling was more aggressive than my hands prefer, but the weight went up just the same.

The general idea is that scope should scale but quality should not. All of these are achievable in small scopes and if we care about quality are not “extra” costs.

• If it is not usable we will not learn what we hope to learn from an alpha or beta – our learning will be confounded by usability issues.
• If it is unpleasant to use, its uptake will be blunted.
• If it is not visually credible, confidence in its function will be blunted.
• If it contains needless toil its uptake will be blunted.
• If it is incomplete in the intended use cases it will seem broken.
• If it is incomplete in its states, messages, and errors for the covered use cases it will seem broken.
• If it is not obvious it is not usable. This is just a facet of usability that we should strive for in every delivery to live users.
• If it is not self-explanatory it has poor usability and increases the cost of training, which is backward from what we plan to do.
• If it is poorly-labeled it is not usable. This is just a facet of usability that we should strive for in every delivery to live users.

• The taxes are done. Never mind that the American tax system is needlessly difficult for the vast majority of taxpayers due in part to the political intervention of companies that make money off of this difficulty; the taxes are done.
• I have prepared for or delivered four of my five quarterly coaching/reviews. So far, so good.
• Another weekend, another dance competition or showcase. The girl did great as a “tall swan” in excerpts from Swan Lake! Lovely to see. And it was nice to stomp around North Bend and Coos Bay for a few hours. One thing you can typically find in maritime towns is old machine shops. No exception here. Fun window-peeping on the weekend!

• We’ve finished emptying our storage unit! That’s money that no longer needs to fly out the door each month. And I’ve repacked several boxes that were collapsing, making it possible to stack better, be more organized, and pass on some things that others will like but that we don’t need.
• Our landlord found a service that refurbishes old control boards and shipped them the display and relay boards from our oven. The oven display will be working again when he returns on Tuesday.
• Better insoles fixed my favorite hiking shoes – no impassioned argument for a return needed.
• The girl’s dance team won first place at her competition this weekend. Good job, ladies!

• My six phase benefit/concept/detail process is going to be piloted in our growth product.
• A work relationship that started with a little contention has become a cordial, iron-sharpens-iron collaboration. Tough but fair, I love it.
• I’ve been able to refer or be a reference to three former coworkers in the past two weeks. It’s nice to know how you can help.
• A couple of weekends ago I chose to do a project for a relative with whom I’ve had a contentious relationship. This turns out to have been a great choice. I finished the project this weekend; it’s nice to feel a sense of accomplishment and to have set a new tone in our relationship, and it cost me only time.

Just like the false tradeoff between security and usability, I don’t want to play into the notion that light scope and quality are opposing forces. We will not make progress if we habitually shortchange quality. An “MVP” of poor experience quality is certainly “minimum” but forgets the “viable” and a bit of the “product.” You could say it is actually below “minimum.” For another take on this, see Jason Cohen’s Simple, Lovable, Complete.

• This is the first week in quite a while that I fulfilled all of my at-work weekly objectives. Sometimes lowering your sights slightly can pay off. Yet I also feel I accomplished more than recent weeks. It’s probably a combination of smaller, more accomplishable (therefore likely better-defined) objectives and actual progress on a thing that’s been lingering for a while. We’ll see if this is a trick or a technique.
• Having to explain my thoughts about product research/design/development to folks I work with, and having them ask me to operationalize parts of it they don’t fully understand, has led me to explaining some of the concepts from new angles. This is challenging my thinking and helping me to firm it up.
• I had a lovely chat with a person who is contemplating moving from designer to design manager. I find this sort of thing rewarding because I like helping, and I like meeting people, and because it reminds me of what I’ve learned, what I think, and to listen first. It’s tempting to opine, but only valuable lightly and if that opinion is actually relevant to the person’s situation or question.

Be it version three or an MVP, the experience we deliver should

• be valuable to specific users
• be usable by those users
• conform to or enhance the user’s understanding of the subject area
• be pleasant to use
• be visually polished
• deliver value in results and conveniences
• minimize toil
• be complete in its delivery of the uses we offer
• be complete in its states, messages, and errors
• make good use of familiar controls and interaction paradigms
• make success obvious
• be obvious in expected actions and right action
• be self-explanatory, relying on recognition rather than training and recall
• be well-labeled
• be instrumented so we can witness users’ successes and difficulties

…even if the scope is small, even if it’s a little slice of functionality from a bigger, longer-term plan, even if it is a fragment of the excellent future we envision. Even the basics should be built completely, with thoughtfulness and pride.

• I installed a bluteotth kit behind the factory car stereo in the 2006 Matrix and
  • it worked on the first try,
  • it sounds great,
  • pairing was easy and the connection seems reliable, and
  • in doing so I accidentally fixed the clock.
  • I also found a decent way to plug the hole in the dash left by the old aux in jack.
• There’s a personnel issue at work, but it has a bright side and is totally surmountable. It is very likely that the parties involved will grow as a result. That’s not an easy way to get growth, but I’ll take it, this time.
• I hit a new one-rep deadlift max on Wednesday. 365lbs is a far cry from the max of my youth or even of a decade ago, but I can see my way to exceeding those with time. Forward!