Visualizing Feature Valence with R

Every once in a while it's worth forgetting everything you know and looking for new ways of doing things. To that end...

Suppose you were looking at how users feel about the features in your application. (I am, presently.) Suppose you wanted to visualize this data. (I do, presently.) In the past, I might have used Excel (double ugh), GNUPlot (ugh), Scilab (meh), or HTML/CSS (yeah...). I thought it was high time to check out R. After some playing around, voila:

It's not the most interesting or most readable language I've ever used, but, whatever, here's the code:

Zen and the Art of Seeing

Since I'm going to indulge in some backstory, I'll lead with my thesis, so you know where we're headed: You're probably bad at perceiving, and your product suffers as a result. Hard to believe you're bad at something you've been doing you're entire life, right?

v1: Seeing Like a Tourist

This summer I hosted some first-time visitors to New York. As I showed them around, I shared the joy of experiencing Manhattan through their eyes. I found myself deviating from routine, taking routes I would never take. I found myself pausing to observe, when ordinarily I would rush toward my destination. And, most interestingly, I found my gaze widening, to just take it all in, even routine things my eye now automatically, unconsciously ignores.

I struggled to name this mode of observation, but "Seeing Wide" seemed close. Where ordinarily I would only look where my eye expected to find novelty (things that change often) or utility (affordances that help me accomplish my task), through their eyes I stepped back to take in the whole gestalt of the scene, and I devoted a lot of attention to observing parts of the scene that I had learned to ignore in the name of efficiency and purpose.

Since then, I've tried to intentionally observe in that way from time to time. It would be sad, I've thought, to only experience that joy when tourists give me an excuse. It's especially enjoyable when leaves are falling, or when I find myself on a rooftop with a great angle. This Thanksgiving, in Los Olivos, California, I spent an hour or two staring across the beautiful landscape trying to meta-observe how my eye was choosing to look at some things and ignore other things, in an attempt to un-train myself from focusing in on parts instead of seeing the whole:

v2: Seeing Wide

It dawned on me that this mode of observation can be professionally useful -- and that product managers don't do it often enough.

Most product managers--by personality and by professional need--have a natural tendency to unconsciously abstract what they see and not actually revel in the glorious detail. Partly it's how we're built; partly it's out of a need to think more strategically, at a higher level. Either way, we don't even perceive a rounded polgyon with lettering and gradients and whatnot -- our minds have wired themselves to unconsciously filter and categorize it as a "submit button" and from then on, we perceive it not as it is, but as we have categorized it.

In the language of Myers-Briggs, most product managers perceive information intuitively (matching it to expected patterns) rather than through direct sensing (seeing the detail first) -- by default, that is; unless they consciously think about perceiving differently.

Perceiving intuitively has its benefits. Someone in a product design team needs to be thinking abstractly and strategically. But it has costs, as well. You (the product manager) may not have the same set of filters, categories, and expectations as your users, and so you need to be sure you're not viewing your product as a product manager, but rather as a user would.

How does one do that -- observe, perceive, see as a user might?

v3: Beginner's Mind

Last week I read "What Kind of Buddhist was Steve Jobs?", which mentioned, "Apple devices, you might say, are sophisticated tools for evoking, supporting, and sustaining shoshin, beginner’s mind." The article also referenced the Zen quote, "in the beginner's mind there are many possibilities, in the expert's there are few."

That quote is powerful in life, generally, but also for product design, in particular. Beginner's mind is exactly the concept I was looking for; it's a more general, deeper version of what I was getting at with "seeing wide." In Zen, shoshin "refers to having an attitude of openness, eagerness, and lack of preconceptions when studying a subject, even when studying at an advanced level, just as a beginner in that subject would."

Most of the abstractions through which intuitive perceivers perceive are not unique. They're things like "call to action", "left hand nav", "drop-down menu," which are all part of a shared culture. So, in order to make interesting new choices, product designers need to cultivate the ability to look at their own work with beginner's mind--without expectations, without prejudgements, seeing it as it is, versus as abstractions. Only then will interesting, new possibilities be apparent.

One seeming paradox is how to bring to bear your knowledge and wisdom upon a situation while also recognizing that your knowledge and wisdom hold you back, and cause you to see things through a set of distortions that you're not even aware of.

I'll end here. Others are more qualified than me to talk more about shoshin:

• Beginner's Mind
• How to Live Life to the Max with Beginner’s Mind
• Shoshin “Beginner’s Mind”
• Beginner's Mind

Image-Free, CSS-Based Icons

Unicode is like that nether-region between your sofa and the cushions -- no matter how many times you look, there's always something cool and unexpected in there, plus lots of crap. Tonight I discovered that there's a tickmark character. Combined with the exclamation mark character, that means you could do simple icons entirely in CSS, without the aid of images. Check this out:

Here's the CSS (in SASS):

TrackerDashboard - UI Overhaul, New Features

Last weekend I did a complete overhaul of the UI for TrackerDashboard. I also added a few new features based on feedback from folks at Pivotal and another project that's now using the tool. Check it out:

Let me know if you've got feedback or have ideas for how it could be more useful.

TrackerDashboard

For the last week or so, I've been building a tool called TrackerDashboard (open-source, on Github) for managing enterprise projects in Pivotal Tracker. This post explains why I built it and how my team uses it.

The Need
At Case Commons, we've been using Pivotal Tracker for years. (We've been partnering with Pivotal Labs for years, so it's no surprise.) Two aspects of our project make Tracker difficult to use:

First, we've got 25 developers, 2 designers, and 4 product managers. That's a lot of velocity for one project, and it makes it difficult to plan and manage the work. One way we've coped with this scale is to break down our development into parallel tracks focused on separate parts of our application. Managing parallel tracks in Tracker is not well-supported, because Tracker is entirely built around the notion of of a single, prioritized backlog.

Second, although we're practicing pretty orthodox Agile, we serve enterprise market (state governments), and with that comes a need to plan out our work and deliver certain committed-to stories each week. Tracking these "scheduled" stories in amongst a prioritized backlog also violates Tracker's basic conventions.

The Tool
This tool is primarily for our project manager (to identify red flags that help her keep the iteration going as effectively and efficiently as possible) and for our head of product (to help her get a sense of the week's progress, without wading through the detail). There are two primary views, for a given project.

First is the "track view" which shows progress in a set of independent parallel tracks (which are based on a configurable subset of your story labels). It highlights overall progress (stories done, in-progress, and scheduled) and red flags (stories that need estimated, stories that have crept into the backlog mid-week, etc):



Second is the "snapshot view." This view lets you take a snapshot of your backlog, and then go back to compare that to the current view of your backlog later. This is helpful for tracking deltas once or twice a day. It helps identify if unexpected stories have crept in, if stories are languishing for longer than expected, if stories are getting re-prioritized mid-week, etc.



Check it out and let me know what you think.

Accelerating Design: Accomplishing More By Doing Less

In my last post, I started to describe how my company's product/design team is undergoing our latest evolution: this time, to establish and manage our visual language as a set of templates, and to get out of the business of producing fully styled, high-fidelity, pixel-perfect mockups for every feature we build.

Context: Our Old Process

Currently, we do feature design in a 3-stage process. First our product managers and UX designers work on a sketch. After that, they iterate and refine that into a medium-fidelity wireframe. And, in our old design process, our visual designers would then produce a pixel-perfect mockup to give to the developers. Here's part of one feature, traced through each stage:



We'd then write a user story that asks for such-and-such functionality, with new some new visual styles, and we'd say "see attached mockup."

As described in the last post, this produced at least 3 problems:

• Our visual design team can't keep up, producing mockups for all the incoming wireframes
  
• Our visual design team loves building *exactly* the right feature for the given wireframe, which was resulting in a lot more visual complexity than really necessary
  
• Our developers, lacking the full semantics of the layout, didn't know which visual elements to implement as generic patterns (and if so, where else to apply them), and which to just do quickly as one-off solutions.
  

Our New Process

What we're doing now is developing a live style guide in our application that will serve as the evolving, living specification of our visual language--a sort of Noah's Ark of visual patterns/styles in the application, named (so they can be referred to unambiguously), annotated with semantics (so developers know when, where and why to apply them).

For the above feature, our product manager and UX pair working on the feature would pause after developing the black-and-white wireframe. They'll take a look at the style guide and look for the patterns they think work for their wireframe. When they find them, they'll annotate the wireframe to identify which styles to use where.

It's likely that for any new wireframe, there will be a few elements that don't map to the style guide. In these situations, the UX designer will present his proposed design (the part of the wireframe) to the our visual design team and one of two things will happen:

1. The visual design team will say, "Yeah, that element requires us to extend our visual language. We'll design a new style; we'll write a story for the developers to add this style to the style guide; and then you can use that for this feature." Note that this *separates* stories into those that add new visual styles (and don't add functionality) and those that add new functionality (but only use existing styles). That is a big aid to the developers, who in the former story, can talk with the visual design team about how to properly abstract this pattern, apply it, understand the semantics, and properly add it to the style guide. In the latter type of story, our developers now have the cue the visual team thinks the style guide has all the styles they need, and so they can devote the extra time to figure out how to reuse that and possibly refactor the code to extend that visual style to the current feature.
   
2. The visual design team will say, "Look, that feature doesn't need a new style, because it's really similar to this other thing. Just tweak your feature a bit and you can re-use that style."
   

In either case, the story given to the developer will only need to contain the annotated wireframe. This saves the visual design team from having to do a layout for every single feature. It also means they don't have to fight the temptation to add fancy new style to the visual language each time they encounter a semi-novel situation. What this ALSO means is that the stories given to developers by the PM and UXer only contain functionality, and don't involve inventing any new styles.



Analogies to Other Methodologies

It's a rough analogy, but this process is like the visual design analogue of test-driven development. By developing the visual styling up-front, we, in effect, use the live style guide as a test suite. Applying the usual red-green-refactor process, the developers can make sure (a duplicate of) the styling isn't already there (red); extend the visual language in the style guide, and let the visual design team sign off on it (green); then go use it in the various features that use the style (refactoring each time, as they encounter variations and special cases).

This approach is also interestingly similar to the separation between content and presentation. By creating a dichotomy between presentation-related stories and content-related stories, this process encourages the development of well written CSS that is minimally coupled to the feature and ready to be applied site-wide.

Problems We Haven't Solved Yet

There are a few challenges we're going to face that we haven't come up with answers to yet. It's possible one of these may prove intractable and sink our undertaking, but we're optimistic we can solve them:

• Can we reign in our visual complexity enough so that it's feasible to represent our entire visual language in a reasonably-sized set of templates?
  
• Can we really achieve the speed-up from this that we need, in order for our visual design team to no longer be a bottleneck?
  
• Can our product managers and UX designers live with the restraints this imposes on the uniqueness of any given feature?
  
• Does this give our developers enough semantic information that they can make smarter decisions up-front that result in less refactoring of how styling is implemented in code?
  

I expect, as we see how this unfolds, I'll have more posts about these challenges in the coming weeks.

Scaling Product/Design Teams, Part 3

Recap
In Part I of this series, I explained about we how successfully integrated visual and UX designers into our team, moving from this:

to this:


In Part II, I described how this sequential/staged pipeline model allowed our team to scale up and incorporate new skills, but it also introduced some new issues (clunky features; too much viability, too little desirability; lots of wasted back-and-forth). In this post, I'll discuss where we're at now, and where we're heading.

Bringing Product Managers and UXers together in the concept stage

Since my previous post, we've made an important step toward killing the pipeline paradigm: we merged the first two stages of the pipeline. Our product mangers and our UX designers now work together both to come up with initial concept sketches, and then carrying those through to wireframes. Our PMs and UXers then hand off wireframes to our visual designers. That gets us to here:



This is really a no-brainer, but because our domain is so messy and complex, and our relationships with our client so intricate, we needed to ramp up our new designers before we could integrate them into the concept-stage work. What does it mean, in practice, to shift toward this way of working?

• Our PMs and UXers now share responsibility for identifying features to work on. This is still primarily our product managers' role, but UXers are audit existing functionality, looking for ways to improve or refactor, and so forth.
  
• While our PMs and UXers each have core responsibilities--our PMs are primarily looking at whether users can get their work done, and our UXers are looking at usability--they're pairing up on problems, sharing the researching, prototyping, and so forth. We typically throw a pair of one PM and one UX designer at problems and they work together to develop an initial concept.
  
• PMs and UXers then share responsibility for saying "good enough, let's bring in a visual designer now."
  

This is working great:

• Our work quality is getting even better
  
• UXers are loving being involved in the concept stage, and having much more strategic impact
  
• PMs are freed up from doing things they're decent at (low-fi wireframes) to the things they're great at (analyzing feature trade-offs, etc)
  

What's not working?

• Our visual team can no longer keep up with the volume of new wireframes
  
• Our visual language is growing in complexity too quickly
  
• Our developers are having difficulty executing wireframes without knowing all the semantics of the visual language. E.g., "Why is this widget blue? It seems really similar to these other two widgets, which use a red color."
  

Our Next Goal: Getting Visual Design Out Of The Pipeline

I need a whole post (the next one) to describe this, but we believe that we can solve most of the above problems by transforming the role our visual designers play. Currently, we hand off every wireframe to visual designers and ask them to apply styling. (Really it's not so waterfall-sounding; there's a lot of back-and-forth and collaboration with the UX designer, but that's not relevant to the problems above or the solution we're pursuing.)

What we're moving toward is that our visual designers would move toward developing and managing the visual language as a set of templates or widgets. In the future, when a PM and UXer are finished with a wireframe, they'll take a first pass at annotating the wireframe (which could be black-and-white and very low-fi) with a set of arrows and textboxes that say, "this thing should be styled like multi-stage progress bars" and, "this other thing should use the 'variable-length list with autocompleter' style." This should solve most of the easy problems and free the visual designers up to design only the really *new* things, and to give feedback like "this thing you're proposing isn't new -- just use existing style XYZ" or "Hey, if you just tweaked this feature like so, you could re-use pattern ABC."



Our hope is that this will allow us solve most of the problems identified above. I'll go into this more in detail in the next post...