Pattern Driven Usability (opportunities and challenges)


There’s been quite a bit of talk, on and off, around developing a library of patterns that interface designers could use that would mean that technology would become a whole lot more consistent and usable. So I was interested to discover that XPDesign, the methodology that PTG Global have been talking up for a while now, is essentially a part of this whole discussion.

PTG have been in the press a bit lately since they’ve launched their ‘certified usable‘ product.

The Certified Usable Guarantee: We guarantee that, on average, 90% of users can complete 90% of tasks with minimal assistance, within a reasonable time, without error, and with at least 80% satisfaction (based on a random sample of at least 300 end users using a Certified Usableâ„¢ technology product).

Craig Errey of PTG presented some of the fundamentals of XPDesign at the NSW CHISIG gathering last night. At the very least he should be congratulated for stimulating probably one of the most engaging debates around HCI methods that I’ve been a part of for quite a while.

The last one was probably back at OZCHI conference, where another PTG representative presented their work on the Citibank Mobile Banking interface and surprised many of us by stating that PTG didn’t need to iterate in their design process because they *knew* what worked and what didn’t. (Obviously, given that mobile banking is a pretty new application on a reasonably new device with many special complexities, many in the audience found this difficult to believe!)

Craig started his talk by asserting that ‘nothing particularly interesting has happened in HCI for the last 10-15yrs’. Big call. I guess that depends a lot on what you consider interesting, he then went on to challenge people to answer two questions: what is usability? and how do you make something usable?

This is all a big lead up to his statement that a user centred approach is not the best approach and that iteration is for losers. He, and PTG, are of the belief that there should be ‘one best way’ to design, and that variance between the way that people design things is not beneficial. Rather than interface design being an art, he asserts that it is much more a science.

“Humans are essentially the same in how they do things”,
James Breeze, PTG Global

Craig argued that current methodologies focus on the users too much, and that consequently, the business objectives are often not given the level of attention they require. Similarly that a user centred approach tends to focus on the surface issues, and not the fundamentals of design.

One of the foundations of XPDesign is that usability needs to be able to be measurable in a quantifiable sense. For example, being able to demonstrate that people can perform a task in half the time that they were able to before. Showing a reduction in error rates was another example.

He asserted that PTG has been able to develop a library of interaction patterns that could be applied by someone with 3-6 months of training in the XPDesign methodology. Using this methodololgy, any trained practitioner (because, we probably shouldn’t call them designers) would come up with the exact same output as their similarly trained peers, and this output would be the single best user interface design.

“Motivations are irrelevant… they’re there to do a job”,
Craig Errey, PTG Global

As you can imagine. There was plenty of discussion.

It was around this time that the qualifiers emerged. XPDesign, you see, is *only* intended to be applied to purely transactional interfaces. Preferably business interfaces, in particular eGovernment. Certainly not “marketing websites”.

(It wasn’t entirely clear whether it was intended to apply to social/community applications online or to information sites… but I left thinking probably not. Craig Errey wasn’t particularly familiar with Flickr, despite it being his stock example of web 2.0 / social applications. I don’t think PTG had given this much thought. No money in it!).

The other important context is the business driver from which XPDesign emerged, which is that PTG’s clients didn’t have the budget to develop multiple interface designs then test the best one. They could only afford to have PTG get it right the first time. And from that business demand, XPDesign was born.

Now, it would have been nice if Craig had made these qualifiers clear at the beginning of his talk… or even in the blurb that was sent out to promote the meeting. They’re certainly marketing XPDesign as a method that can ensure *any* interface is *most* usable, and that’s not something that this methodology, or PTG, is capable of. As many people commented throughout the evening, in some cases, people’s emotions and motivations *do* count. And oftentimes, speed doesn’t matter.

But, enough about XPDesign specifically (except, I do have to make a quick note about the irony of naming a non-iterative methodology with the term XP, which as an agile development methodology is hugely supportive of the iterative process). What of using patterns for design?

Yahoo are probably the best known participants in the land-of-pattern at the moment. If you haven’t already, check out their Design Pattern Library that they have generously made public. They also provide a great explanation of patterns, and the lifecycle of a pattern. The lifecycle in particular, makes for interesting reading.

There are many other groups developing and sharing patterns. The Wikipedia entry lists some.

For me, I think the idea of patterns are great. Why re-invent the wheel every time we come to design a site/form/interface? It doesn’t make sense. Its not efficient, and it doesn’t result in consistent outputs, thereby negatively affecting usability.

It doesn’t mean that as interface designers we become automatons. There will always be skill involved in placing these patterns together, and most importantly, deciding *which* patterns to use. And there will always be opportunities for patterns to be iterated… I find it hard to believe that we ever know for certain that we’ve found the one best way.

The problem with patterns are twofold.

Firstly: How do we get to the point where there is one pattern library? Or, at least, one that has significant enough uptake as to be useful for designers and users? Who can or will take responsibility for this?

PTG have been selling their XPDesign solution. They claim that they’re going to make it publicly available for free (under a creative commons licence). This is good. But still someone needs to step up to the plate and guide the development and marketing of this pattern to designers and clients.

Who could that be? Is there/could their be sufficient promotional benefit for a corporate to take this on? Would it be possible to garner enough energy, resolve, commitment and agreement from a not-for-profit association to achieve this task?

Secondly: How do we make sure that people learn to apply the pattern’s appropriately?

This, assuming the pattern library exists, is a much easier question to answer, but I mention it here because the pattern library is not an end in itself. Just as Blogger doesn’t make everyone a good blogger… and Dreamweaver doesn’t make everyone a great website developer… the pattern library will not make everyone a good interface designer.

OK. That’s already a *much* too long blog post.

I can’t believe you made it this far.

You might as well leave me a comment and tell me what you think about this pattern business, seeing as you’re here :)

UPDATE: Just a couple of things to clarify (thanks to Craig and James for the emails).
When I said above ‘iteration is for losers’ that was my extrapolation of what Craig was saying in his talk. A more accurate representation of Craig’s position is: ‘iteration is not a good thing’
Also, regarding the name XP design, you should know that XP in this instance stands for ‘eXperience and Performance’ and it’s not intended to refer to Extreme Programming methodologies.

5 thoughts on “Pattern Driven Usability (opportunities and challenges)

  1. This is truly scary. My team does a lot of transactional work, some of which is for government clients. They often come to us because someone else had sold them a load of BS about their system working right the first time… and forgot to mention that it would do so only for a particular user group, or only until they needed to add some functionality, etc.

    Craig’s arguments remind me of all the “silver bullet” approaches that have emerged over the years in software engineering. That field has also had its share of people claiming that, by following a given process, any programmer or system designer could come up with The One Best Solution to a given problem. Perhaps it’s time for someone to write the equivalent of Fred Brooks’ Mythical Man-Month for UX…

  2. As one of those hybrid IA / Producer types, I’m inclined to agree with Craig’s argument that business objectives sometimes are drowned in a welter of user needs. After all, the business wants to do business, right? A good interface starts with the objectives for the application, and moves to the best way of implementing it (where user needs come in) so as to achieve the objectives. Great creativity can come out of the tension between two interests…

  3. I tend to agree Dmitry… I think it’s a bit scary too. But having said that, I think that the idea of the great UX community working together to develop a library of patterns that are used appropriately is pretty exciting. (Probably because it’s also completely utopian and will never happen… doesn’t hurt to dream).

    Meliss: Good points. What do you think of using patterns? Do you think think this will help maintain an appropriate focus on business goals?

  4. Lisa,

    I don’t know if you have come across It’s your utopian dream in action (and Aussie based, though of course global via the internets)

    Actually, it may not be quite as utopian as you think. Afterall, it’s really in many ways just an extension of developing standards like HTML and CSS (which a decade ago looke d like a utopian vision, trust me!)

    I’ll asnwer more in detail to the issue at hand shortly


  5. I think the overall problem with the idea is that patterns are not meant to be templates, or “boilerplate” solutions. Rather, a pattern describes (in Alexander’s words) “a problem which occurs over and over again … and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice”.

    I do think that patterns bring benefits in learnability and consistency to the user’s experience (as well as demonstrable benefits for developers, and beyond that for software, as I outline in the article linked above). But I also think patterns emerge from use and behavior, and are adaptive. You don’t enforce patterns on users, rather you identify emergent behavioral patterns and then use a design patterns approach to formalize these.

    The idea is that cowpaths emerge, and we pave them. The thing about cowpaths is, you don’t know where they’ll be until the cows start a walking. Well, I don’t think you can know them. This methodology is predicated on the belief that you can.

    Its seems that this methodology assumes that all cowpaths will emerge in the same locations, we just have to know where it is.
    From what we know about emergent systems, (and human behavior is a classic emergent system) this is unlikely.

    As to the assertion “Humans are essentially the same in how they do things”, I guess

    0. it is superficially appealing (see everyone starts ordered lists at 1 right :-)
    1. it is at best highly contentious
    2. it would only be demonstrable by watching users and identifying their behavior – um, that sounds a bit user centered doesn’t it?

    I know it is a precis but if the following is accurate, there is another, deeply philosophical and far more important issue lurking beneath the apparently methodological one here.

    “Craig argued that current methodologies focus on the users too much, and that consequently, the business objectives are often not given the level of attention they require”

    User centered design is a philosophical choice. Yes, it is predicated in part on the belief that by solving the problem the user wants to solve, the provider will somehow benefit from providing that solution.
    The alternative is really to treat users as some part of the business process – business process centered design. Sounds a fair bit like a Soviet approach (and I mean that in a non rhetorical way).
    And this is predicated on a philosophy of business which says in business, my needs and outcomes as the business are paramount, and those of my customers are subordinate.

    Personally, it’s not how I do business, nor how I like to be treated. But aboveall, I wonder which philosophy will win in the coming decade or so.

    OK, strayed way too far off the topic,


Comments are closed.