Mercedes Gozalbo-Moragrega

Metaphors for UX

[tinmunkey-blog]

Bye literal design, hello design thinking

While digital development has been through seismic changes in work processes (see agile software development), design has been surprisingly unaffected by those changes. Unsurprisingly, it’s not working.

Designers are still expected to produce a specification, approved by the Product Owner that will be then handed over to “the developers” to build as literally as possible and passed on to QA to test, again, as close as possible to the original specification. If this sounds waterfall-y is because it is, it’s just that in “agile” the design cycles are much shorter.

This obsolete set up stubbornly demands that the designer has ALL the answers at the point of design and insists that the world cannot possibly change from drawing to product.

This literal view of the product “as designed” is divisive and perpetuates a siloed mentality to production, one discipline never enriching other disciplines.

The tyranny of the pixel needs to give way to a more holistic design thinking approach facilitated by designOps, where everyone in the delivery team, from product owner to QA tester, participates of the product’s sentiment and principles and applies those in their role.

[tinmunkey-blog]

Is design a luxury?

No, design isn’t a luxury, design happens whenever you have a human-made product.

A different matter is the quality and “intentionality” of the design exercise, or as Ralf Speth* put it:

If you think good design is expensive, you should look at the cost of bad design

Often buyers of technology think of design as a “nice to have”, something extravagant and “gold-plated” that you can do without if you are cost-conscious.

You may not think that your product needs to be “designed”, but I can guarantee that someone, somewhere in your digital programme is making design decisions that you will pay for but could have been avoided with some design thinking, from a very slow delivery, to poor user experience or inability to scale your product.

* Ralf Speth is the current CEO of Jaguar Land Rover with previous roles in BMW and Ford

[tinmunkey-blog]

Enrolling users for user research: Please handle with care

It’s easy to be over enthusiastic when recruiting users for user research, specially for internal research. Be warned, you may be setting yourself up for failure...

You firmly believe in user-centric design and want to get users involved as soon as possible for qualitative research, your communications are probably on the lines of “we are interested in knowing what you think or how you work”, “you will help up design a better experience for X”, “we will be capturing your needs and requirements”... and, without meaning to, suddenly these representative users have become something else. Their opinions, likes, quirks and barely formulated thoughts, matter to someone and now they’ll tell YOU about them. And now it’s your job to do something about them. Good luck to you.

To ensure that you get as much as possible from involving users in your user-centric project:

control (and design!) the communications when recruiting the users (ie. BEFORE the research starts). Use neutral language and lightly play down the influence that individual users will have on the actual design

Validate the raw research data you collect, someone’s opinion is not necessarily a requirement. 

An opinion is not a user requirement, requirements are the product of careful analysis and insight.

Even when there is value in the raw data as a requirement, check that you are not making the same mistake as King Midas made...people are not very good at saying what they mean.

Let me know how you get on!

[tinmunkey-blog]

Managing client’s expectations

[tinmunkey-blog]

The Midas approach to requirements

Capturing requirements, either from users or from the business, often reminds me of the story of King Midas, who was granted a wish to turn anything he touched into gold, which was an awesome idea until he tried to eat :/

What do Midas, users involved in user research and product owners have in common? 

what they say may not be what they mean, so it shouldn’t really be taken literally.

Before “wishes” are taken as “requirements”, they need to be properly understood, rigorously analysed and validated.

[tinmunkey-blog]

The complexity of the product, how big or super talented your delivery team is and even which sector you work on play almost NO part on how successful your product’s delivery is.

As long as design is a second class citizen within delivery and not a true partner and facilitator of the delivery process, no amount of talent on your team will be able to overcome the problems embedded in that design-less structure.

In general, when a talented team is only able to deliver an unremarkable, unsustainable product very VERY slowly, you have to look at how the team’s operations are handled (“agile”, I’m looking at you), including how design is embedded in delivery.

[tinmunkey-blog]

The Milgram experiment or how you ended up with THAT functionality

The famous Milgram experiment in which test subjects were asked to give (fake) electric shocks to others is supposed to highlight how people can become compliant with seemingly outrageous requests from others in a position of authority.

Leaving aside considerations of methodology of the experiment itself (and those that were done afterwards), what I find interesting about it is how compliance with an unreasonable outcome was achieved through incremental requests, rather than with a single unreasonable request...which reminds me of how many software programs end up with crazy functionality.

A good quality product will be the result of commitment to the vision, the vision alone can get diluted through the myriad of seemingly innocuous requests.

[tinmunkey-blog]

Rapid design? careful preparation

Like with any humans, there may be a big gap between what your client wants and what they need.

Your client has this deadline to deliver a functioning product, they are engaging a UX and design team maybe a little too late so they want you to start delivering assets to devs straight away, what do you do? You tell them you are not going to deliver straight away, you will be prepping first...

This scenario is not dissimilar to that of a professional kitchen, the chefs have to deliver a finished product at around a given time, but it cannot be cooked until the customer has actually ordered it: 

In order for these chefs to quickly deliver when the customer places their order is to have spent most of the day prepping the food.

Like these chefs, design teams have to spend some time getting their tools and assets ready before they start delivering to development. Pattern libraries, visual language, templates, bootstrap, etc must be in place, or very much advanced, in order to produce assets that are consistent and coherent with each other.

[tinmunkey-blog]

The fallacy of User-centred design

User-centred design is a methodology that considers the user's needs, wants and limitations throughout the whole product cycle, from conception to use.

This is awesome and, frankly, who, in their right mind wouldn't do this in order to get a successful product?

However, I have two problems with this:

The emphasis on UCD seems to place the designer squarely on the user's corner but against other crucial aspects of production. To produce a good quality product there are considerations other than The User that a designer must address and should not be left for others to solve, such as how can this product be feasibly produced industrially, what are the steps that will help the stakeholder sell the idea internally? User Centred Design limits designers to a very narrow role in the product life-cycle

The fact that the product is "designed" should already include the concept that it's designed for someone, for a user. User Centred Design is surely tautological. 

Be a designer.

[tinmunkey-blog]

Positively discriminating features

Positive discrimination in law is the process of giving preferential treatment to minority groups. It's also known as affirmative action, introduced in the 1960s in the US to help reduce discrimination, initially racial and later on expanding to include others like gender.

The United Nations Human Rights Committee states that "(...) the principle of equality sometimes requires States parties to take affirmative action in order to diminish or eliminate conditions which cause or help to perpetuate discrimination (...)"

I find myself thinking about positive discrimination in the context of designing software because, as a designer working on an agile environment, design features are constantly being de-prioritised by other, let's say, more ominous sounding development features.

It is very difficult to argue that, for instance, changing the capitalisation of those menus and the position of those sliders should be prioritised over getting some server do something or whatever.

Because the dev resources are shared between technology, business and design, design features, which usually focus on UX and quality, are not seen as important enough to dedicate resources. Even when the pressure to deliver business or technology focussed features, design has a hard time to argue the need to invest resources.

I wonder if the solution lies in using positive discrimination thinking, such as quotas of resources (eg. 10% of the points assigned to a sprint must be prioritised by design)...

[tinmunkey-blog]

Ce n'est pas un marteau: from a design to a product

One of the most surprising effects of working in an agile environment as a UX is that a lot of design is left on the shelf and never actually gets implemented.

Somehow, stakeholders get the impression that, once the thing has been designed, the box of "design" has been ticked, without realising that for the design to be completed, the thing needs to get built. I find myself repeating to stakeholders that a drawing of a hammer is not the same as an actual hammer. The fact that there are designs and layouts of "The Interface" doesn't mean that "The Interface" is going to be built so they need to prioritise design work to be implemented in order to use it.

It looks like designers working in agile should be producing not only the specification (wireframes, design assets) but the breakdown of how it can be implemented, otherwise, the design may appear to be too complex to be fulfilled within the agile methodology.

[tinmunkey-blog]

Isaac Newton was a bit thick, wasn't he?

"Well, he didn’t come up with quantum mechanics, now did he? or with the theory of relativity, uh? he just wrote that Latin book about gravity or whatever”

So many times, I hear UXers talking on those terms about work that has happened in a program before they joined which, invariably, leads them to start everything from scratch, because their ideas are soooo much better than anyone else’s, obviously. Which, of course, means that thinking never advances as we are all too focused in having the same ideas as previous UXrs have had…

Our thinking is constrained by the context where that thinking occurs: Newton wasn’t more stupid than, say, Einstein, his thinking was intimately joined to his context. Einstein did not start from scratch to come up with his theory of relativity, he was aware of the thousand of years of physics prior to him sitting at that patent office…

Interrogate and prod design decisions and assumptions with the purpose of understanding them and their context before criticising them.

[tinmunkey-blog]

More socratic thoughts for UX

Socrates’ attributed quote of "I know that I know nothing" is a reminder to recognise that, in order to acquire wisdom, one has to be curious and interrogate assumptions. Only by starting from ignorance, one can be open to new insights.

This approach is sometimes used, knowingly or otherwise, by UXers, who will not be able to design a piece of software without doing in-depth research on users, as they just don’t know what the user does/thinks/feels/etc…

Although I do agree with the need to do user research before designing, I must admit that I find this attitude somehow obstructive in a delivery-focused environment:

Having more data or information won’t necessarily result in a better design. Data or information overload may mask more visceral issues that need to be resolved

Design is not an exact science, there isn’t a single, holy grail-like, solution to your problem. Honest.

Delivery projects are, yes, delivery focused, so they tend to have very little scope for research. Constantly stalling delivery teams with the “I don’t have enough information to make a decision” will end up in these teams bypassing UX entirely. You may have found the “holy grail-like solution” but if your delivery team has moved on, this solution will never be built, will never be enjoyed by anyone. Sad, isn’t it?

Research is not the only thing that informs a design: experience, standards, best practice, etc… should also play a part at the design stage. Make assumptions, document them, caveat your solutions. Give.Solutions.

Research is a great way to gain insight and understanding that can drive innovation, but not all projects are looking for innovation. Pick your battles, the ones that are not worth it, jfdi.

[tinmunkey-blog]

Lean to discover, JFDI for everything else

Lean UX methodologies allow UXrs to quickly get rid of assumptions on their designs by breaking solutions into small deliverables that can be produced rapidly so users can actually use the product, UXrs can observe how the product is actually being used (note that I say "use" and not "test") and can refine the product based on the outcome of these observations.

All this is good for problems that are new and need a discovery approach to them. For everything else, JFDI. 

[tinmunkey-blog]

The product is what gets built, not what is designed

It may sound like a truism, but it is very easy for designers to forget that the product is what is actually built, not the drawings of the product, or the prototypes that have preceded it.

It means that the most delicate moment of design is at the point of deciding what is actually going to be built, at the prioritisation point.

[tinmunkey-blog]

Build the bridge first, then build it again

Fig.1: Old London Bridge

The area around the current London Bridge has been used through history as a place to cross the river Thames, initially through natural occurring swamps and estuaries, then through man-made structures, the first of them probably dating back to Roman times. Since then, the bridge has been rebuilt and repositioned many times.

The current London Bridge, opened in 1973, is just the last of a long list of iterations on “London Bridge” adapting to the changing needs of the city and its citizens. The Romans did not build the bridge that we know today.

Designing and building software should be seen like the iterative process of building the same bridge…no, the first iteration won’t be made of concrete and have a motorway on top…it may be a much simpler affair, but it will give us an idea if putting a bridge there is a good idea at all. Keep iterating to move from crossing the river through the swamps to a truly solid structure that meets the needs of its time.

[tinmunkey-blog]

The socratic method for UX

From Wikipedia, the socratic method:

is a form of inquiry and discussion between individuals, based on asking and answering questions to stimulate critical thinking and to illuminate ideas.

Some UXrs use the rule of asking 5 times why in order to understand the underlying problem that their design will resolve which is, basically, a variation on the socratic method.

The method is quite successful in unearthing the real issues to be solved with the design, but it's important to be careful in when and how to use it as it can come across as irritating and it requires both parties in the dialog to be pretty articulate and be aware of the purpose of the exercise. 

Socrates so irritated his contemporaries in the city of Athens that he was sentenced to death by poison...in an office, you are unlikely to be forced to drink poison because you've used the 5 whys method, but you do still need to be aware of when and who to use it to and, ideally, you will weave the 5 whys into a conversation, instead of just shooting them point-blank.