More features, lesser product.

Before I start let’s be clear: product development is not an easy pursuit. If it was then, as they say, everyone would be doing it.

Although at times it can feel like everyone is doing it. The number of apps and online services jostling for our attention is overwhelming. When faced with precisely 100 results (at time of writing) for “to-do app” in the App Store, where do you start? And as an app producer how do you make your product standout in such a crowded market? It’s understandable if your conclusion is that the app with the most features wins.

My favourite run-tracking app changed recently (don’t worry – this isn’t a glib excuse to squeeze in what an accomplished runner I am. I’m not. I run short distances, infrequently. And slowly.). After finishing my run, instead of simply recording the details as normal, a new message popped up. “Share with friends!” it said.

For the reasons outlined above, I had no intention of sharing the details of my run with anyone. So I bypassed the invitation with a couple of taps. And now, much to my chagrin, I have those extra couple of taps to perform every time I want to record my run and get on with recovering from my exertions. So why the extra feature that I didn’t want?

The fact is that many users will want the feature, and introducing a community aspect (or in the case of the running app, a competitive aspect) can create an additional hook that takes engagement with the product to a new level. But when does “feature rich” become experience rot, and how do we stay on the right side of the line? More is better right? Therein lies a minefield for the budding product owner to negotiate.

At Fathom, we are firm proponents of a couple of frameworks that help bring objectivity to the feature-pruning process. The first is the Kano Model, dating from the 1980’s, which applies three categories to features – dissatisfiers, satisifiers and delighters. ‘Dissatisfiers’ are features that, if absent, cause frustration. These are threshold features, must-haves. ’Satisfiers’ are central to the product’s function, the core features. ‘Delighters’ are those additional elements that differentiate the product from the competition.

By categorising potential features along these lines, prioritisation follows naturally. Make sure dissatisfiers are firmly in place, that satisfiers provide excellence in user experience, then – and only then – move on to delighters. In other words, don’t shoot for delight if you’re not providing for basic needs.

So what to do when you have a whole host of delighters? What if you have feature after feature that you are convinced will take the user experience to new heights? Well, chances are you now have a bloated product.

I have a Swiss army knife at home; great little tool to have around the house. However if I need to tighten a screw, I don’t think “now where’s my Swiss army knife?”. Similarly, next time I need to gut a fish (it could happen), I’ll be looking for a specialist tool.

And this is the dilemma. Do you want your product to be a swiss army knife, not specialising in anything particular? Or, do you want it to be a scalpel – clinical, with a singular purpose, and built for the job.

Irish entrepreneur Des Traynor is doing great things with his CRM web app, Intercom. He’s also a great contributor to the thinking around product management. According to Traynor, healthy product management is the willingness to drop features as well as add them. But which ones to drop Traynor’s approach is simple. There will be a natural scale of features which runs from those used by most users, most of the time, to those used by few of the users, little of the time. It is the latter features that need pruned in order to keep a product lean and relevant.

Whenever difficult decisions need to be made (and in the world of product development, there are very few easy ones), we don’t have to resort to guesswork. Applying some rudimentary classifications to features can help you see a product through the customer’s eyes. Not everyone loves your product as much as you. Get over that fact, and you’re on the way to better decisions about its future.

Formula doesn’t mean formulaic

One of the occasional criticisms hurled at user experience as a discipline is that it is simply a box–ticking accessibility exercise; that by engaging in solid research and analysis, somehow UX is the boring bitthat has to be done before real design gets a look in.

Related to this is another misconception that if a diligent user–centred design process is followed, somehow we will always end up with the same formula, the same outcome – the same design. This is part of the same myth which says that design is arrived at through inspiration alone; that ‘design’ is a noun rather than a verb; that we should ignore established best practice or patterns and instead search for true ‘creativity’ and ‘innovation’ (add your favourite devisive industry buzzword here).

The retort to this isn’t that UX design does not involve the use of formulae. The defence is that it is the very use of ‘formulae’ that ultimately leads to differentiation.

Some years ago I learned about a narrative pattern called the Hero’s Journey. American Academic Joseph Campbell wrote about it in his book ‘The Hero with A Thousand Faces’, the result of years of study of myths and legends from many different cultures from around the world. What he discovered was a set of common elements, a formula if you will. You can read more about it here.

Ever since Campbell put his findings in writing, a huge number of popular stories – be they in literature or cinema – have taken cues from the Hero’s Journey resulting in some of the most beautiful, most inspiring tales in popular culture. You need look no further than the original Star Wars (a story that wears Campbell’s influence on its sleeve) to see the template at work. The thing is, although you may be aware you are watching or reading something inspired by Campbell’s work, it doesn’t make it any less stirring or appealing.

It’s worth looking also at popular songwriting. I’m willing to bet that your favourite songs go something like verse–chorus–verse–chorus–middle 8–chorus. I’m also willing to bet that they are based around seven main chords, or variants thereof. And yet from this we get pretty much all modern popular music, and certainly some of the most emotionally resonant, moving songwriting the world has known. Even Lennon and McCartney knew the rules… albeit they stretched them more than most.

UX design is a similar: working within constraints, sometimes with familiar patterns, the unique aspects of the project – the client’s aspirations, the user needs, the business model – bring to the table elements which alter the chemistry of he process to create something if not unique, then truly effective – the most important benchmark of all.

Last year I worked on a support micro site for a minority community group. Conventional wisdom would have held that, as we were dealing with an already well–researched audience, user research would not yield too much in the way of insights. The client however was wise enough to seek validation of received wisdom and consented to a round of public workshops. One of the most valuable outcomes from these was a set of five distinct personas that the website needed to connect with and communicate to. The personas derived informed everything from navigation and wayfinding to site content and overall tone–of–voice, as well as providing themes for the associated promotional campaign.

As in music or storytelling, the basic building blocks may be limited but there are potentially infinite directions a project can take. And yes, as in those other examples, some results will be poor if a formula is relied on too heavily. What matters though is that the chosen outcome is an effective one, and one that connects with the right people.

In a changing world, where human factors consistently remain the most important elements in communication and interaction, a solid user–centred design process remains the best formula for achieving success with digital projects.

This post originally appeared on the Fathom_ blog

The Entropy of Intent

With the publication of his article ‘A Mathematical Theory of Information’ in 1948, a visionary mathematician and engineer named Claude Shannon all but established information theory, outlining in his paper the building blocks of digital communications.

His work introduced a contextual definition of ‘entropy’, addressing the reliability of data transfer, the conveyance of information from a source to a receiver. If ‘Shannon entropy’ was low, then the predictability of the information content was said to be high. Shannon has been credited with laying foundations that ultimately led to the creation of the world wide web itself.

The fundamental problem of communication,” Shannon put forward in his publication, “is that of reproducing at one point, either exactly or approximately, a message selected at another point. He was – and is – of course absolutely right.

However the specific challenge that Shannon was referring to was one of technology, and the need for purity of signal and removal of distortion caused by interference such as compression of data. The irony is that, in a web that is a legacy of the work of pioneers like Shannon, information entropy is less likely to be as a result of technological factors, and more a simple failing of human communication.

To put it more succinctly – it doesn’t matter how perfect data transfer is if the data itself is wrong.

In this post from last month, (echoing this piece from earlier in the year) Jeremy Keith opines that the web has drifted away from its original vision. It is lacking, states Keith, “because we shaped it that way, either through our own actions or inactions”.

A deterioration of vision or purpose due to human-related factors – the entropy of intent.

This same decay can manifest itself at a granular level in design and development projects; a deterioration of what was originally desired, intended or agreed, dissipated across meetings, through processes, sign-offs and the myriad communications that take place between various parties as a project progresses.

The idea of ‘entropy of intent’ is not referring to, for instance, constraints being applied to features or narrowing the scope of the project (both of which can actually be hugely positive moves). It may however manifest itself in other seemingly innocuous ways such as: poor copywriting; ineffective navigation and wayfinding; needless functionality. Anything in fact which distorts the communication of ideas and concepts between the source (the project team) to the receiver (end users).

Protecting intent doesn’t come under project management; it isn’t the client’s responsibility, nor specifically that of the design or development teams. Responsibility exists both within and outside the traditional project roles. More than anyone though, I believe it falls to the UX function to keep a project true to its original purpose, which will generally be  more all-embracing than the minutiae of conversions, KPIs and metrics.

Without question it takes a huge amount of effort to even articulate the central intent for a project never mind maintain focus on it. One key contribution that UX design can effectively make is firstly to identify and agree core guiding principles, and then to keep those principles in play right through to delivery. But it is a monumental challenge.

I’ve been involved in projects over the years where mere delivery was celebrated. Something that began with high aspirations and apparently clear goals became something to simply get finished and tick off a list. This is not necessarily anyone’s fault. What it means is that somewhere along the way the original vision for the project has become secondary to other priorities – sometimes this may be just getting it ‘out the door’.

Help is at hand, unsurprisingly from a fantastic and supportive UX and design community:

  • Any project comes with a brief, albeit one that might be vague or unfocused. Creating a vision though is just as important. This article from UX Magazine offers some excellent advice on creating an effective, singular vision
  • It may be the user’s intent, rather than the project’s, that requires clarification. UX Matters published The Importance of Knowing User Intent some time ago, documenting how this can be identified, which in turn can feed into the vision for the project as a whole
  • Dan Klyn has spoken on defining what “good” means on a project and outlined the use of Performance Continuums. I highly recommend his talk, which can be listened to on the UX Thursday website, with accompanying slides available on Slideshare

No project will ever embody perfection. But neither should every project fall prey to a lack of stamina or will to create something if not great, then truly effective for the organisation funding it and the people who will ultimately make use of it. Following the critical early stages of a project, when it is often easy to feel that the difficult decisions have been made and all the big battles already won, the war of attrition against entropy is only beginning.

Practise like an expert, don’t communicate like one.

Peer networking in the design community is thankfully not the rarity it used to be. Where there were onceinfrequent events based around an occasional high-brow lecture or overly self-conscious ‘networking opportunity’ (ugh), thanks to any number of driven and enthusiastic individuals we now have conferences, unconventions, informal meet-ups and increasingly relevant and compelling talks.

Industry peers aside though, our professional communications take place with a number of other key groups: colleagues, clients and end users. It’s worth considering how we handle these conversations.

A couple of years back the excellent UX Bookclub Belfast covered ‘How to Use Your Eyes’ by James Elkins. Each chapter delivered a brief but compelling insight into the expertise of others. By deconstructing (amongst other things) a culvert, an oil painting and the Periodic Table, the book revealed hidden mechanics and meanings, inspiring admiration for those whose contributions you might not otherwise consider.

Had there been a chapter devoted to the makeup of a graphic user interface or how a web browser renders HTML, no doubt most in the web design industry could have articulated something to inspire  similar, admiring reactions from readers outside our sphere of activity. Indeed, expertise is (or should be) the minimum price of entry into the increasingly crowded Service Industry Club. A key question to consider then, is: how do we convey our knowledge to those we most need to engage with?

It just works

Almost everything we interact with or consume is the product of others’ technical mastery; their input is largely invisible, allowing us to go about our day without having to consider theories, systems or production processes. We care about these things, only in the sense that they just work without insight on our part.

The same goes for most experts we come into contact with. Be it a doctor or a car mechanic, we appreciate it when these people frame problems and solutions in the simplest possible simple terms, revealing more detail only when we request it.

Dumbing up

In UX design, and I’d suggest pretty much every other design discipline, expertise should manifest itself in simplicity. Or to rephrase that, the science we incorporate into what we produce should be invisible to a non-expert; and we should be able to communicate our expertise while remaining intelligible to the listener.

Too often we trip over ourselves to prove our competence rather than communicate it effectively. In many ways our ability blinds us. We should not berate the client for, as designers are so fond of saying, “not getting it”. Others do not see as we do. We are the ones who have the responsibility of making sure clients “get it”… whatever “it” may be.

So perhaps the truest test of our competence is how simply we can share it. When we discuss a project’s challenges and potential solutions with a client, make it simple to understand. Communicate like a true expert.

In (further) praise of personas

I felt this piece from UX Matters – Are Personas Still Relevant to UX Strategy? – and the string of great comments that follow it warranted a post here, based on personal experience forged in rigidly commercial environments.

To my mind, personas introduce a much needed human aspect into what can otherwise be a soulless, technical process that leads to an anodyne web site, app or web strategy. Rarely is the case for designing for people put as strongly as during a persona building exercise.

Personas also help to communicate strategy to otherwise sceptical stakeholders. When they are executed correctly, they ring true. They transform the “users” we so often refer to in design industry-speak into the clients and customers that your client recognises; they will know these people.

When it comes to crucial decisions of prioritisation, creating a hierarchy of needs for functionality can be greatly assisted by basing these decisions on the most important customers as a first step, rather than working with an exhaustive list of features or content.

The final, crowning glory of personas is their potential to bestow a lasting legacy. Beyond the life of an interface project, the organisation – your client – now has a valuable insight of their public. They will not be marketing personas (a very different proposition) and done badly, they are nothing but caricatures. But they can provide an enduring reference point for future communications. They inform your client about the people they currently, or aspire to connect with and how they prefer to interact. Above all they can imbue an organisation with the capacity for empathy.

Done right, you will change you client’s perspective for the better, giving them wisdom that they simply did not have before. They will know it and will thank you for it.