Personae, then and now

The first personas I ever created were based on a template I inherited. I was really just filling in blanks, except I redid the graphical portions of it. The original graphics had vertical sliders to show levels of some discrete qualities of the users. I replaced these with horizontal sliders in order to downplay the relationship between those qualities, because at a glance it erroneously looked like the curves created by the array of sliders had meaning. I determined this was less of an issue with horizontal sliders.

On subsequent projects, I created new persona formats for increased scannability, graphics that were more direct and transparent, and content categories based around information I knew my team and I would want to refer back to. This turned into an ongoing internal challenge: the quest for a more useful persona, one that isn’t just a perfunctory artifact designed to be shown once on a slide in a presentation to stakeholders, but an actual tool the UX team will use throughout the development of the system.

To do this we had to consider what kinds of information about users we likely need at a glance 1 month, 3 months, 6 months, or 2 years into a project. Some information might be useful now but not later, or later but not now.  Because of the way personas tend to get used by the business, we leaned toward information that was immediately useful near the beginning of a project but made sure to fortify it with content that would continue to be useful later on as reminders of important high-level information.

That’s where we started to get into things like work culture and values. To be honest, the best way to represent that in something like a persona is a challenge I’m still thinking through and have ideas about. It’s something I’d like to continue to work on in upcoming projects.

Small difference in design, big difference in user experience – water bottle edition

Sometimes a seemingly insignificant design feature can carry bigger assumptions and implications for the lifestyle of the user.

Water bottlesConsider two reusable water bottles, as pictured above. Both have a capacity of 20 ounces. Both have a small opening designed for drinking out of and a larger opening designed for adding ice or other solids. Both have about the same footprint and will fit most cars’ cup-holders. The only real difference is the shape of the upper portion.

To fill either one up to maximum capacity, you have to first secure the top part and then make sure your stream of liquid is narrow enough to fit easily through the small “drinking” opening. The alternative is to unscrew the top part and fill up the bottle through the wide opening, which is much easier, but won’t get the bottle all the way full.

The design of the bottle on the left assumes that its users have access to a steady narrow stream of water and can easily hold the bottle still long enough to fill it up through that small hole. The alternative approach—unscrewing the top part and filling it through the large opening—would end up causing users to forfeit about a quarter of the bottle’s capacity, merely because of the long slender design of the bottle’s neck.

The design of the bottle on the right mitigates most of this problem by only placing about a tenth of the volume in the top part. This means it can be filled by the easier method of unscrewing the top part, without much sacrifice in capacity. In turn, this means assumptions about what kind of stream of water and bottle-holding abilities the user has access to are no longer necessary.

It’s usually a good thing when we can tweak a design so the need to assume things about our users or inadvertently force requirements on them is eliminated.

These two styles of bottles are both for sale right now in many different stores, and the people who bought each one are getting very different experiences even though they bought very similar reusable water bottles.

This example does not demonstrate the most dramatic impact on users a design can have, but it demonstrates how there can be more of an impact than the designers may have considered. The little things matter, and design works out better if you account for that.

Setting a technology baseline

There are often good reasons to eschew the latest technologies in favor of older ones. As I think of these reasons, they seem to fall into various categories. Here are some of those categories, and an example of each:

  • Practical reasons. E.g. you don’t want to worry about running out of batteries or going out of service range with your GPS or smartphone so you use a paper map for navigation.
  • Emotional reasons. E.g. you feel you will enjoy your lawn more if you have poured your sweat into it, so you use an old-school reel mower.
  • Moral or ethical reasons. E.g. you listen to music on CDs instead of live streaming it using an Alexa or similar listening device which poses privacy concerns.

People can be observed lining up to buy the latest technology anyway. Apparently we are often swayed by new technology’s tempting offer of benefits. When we do forego new technology though, it is rarely in exchange for something more primitive than what we were accustomed to while growing up. (The resurgence of interest in vinyl records might be an exception.) For instance, I don’t use a smartphone, and at times I’ve considered just having a landline, but I have not entertained the idea of going without a phone altogether.

This makes it all the more important to think hard about what kind of technologies we give our children access to. With technology we don’t just give our children tools, we also give them a frame of what is acceptable or tolerable–in a sense, what is conceivable–for use. In the future our children may wish to retreat from some new technology (for practical, emotional, moral/ethical, or whatever other reasons), and what they feel comfortable retreating to is being decided right now, by us.