the_eggwhite: (Default)

Originally published at Eggwhite's Eggbox. You can comment here or there.

After listening to the ” What is Wrong With UX? ” podcast (from Kate Rutter and Laura Klein ) for a while, I recently picked up the book the hosts have been relentlessly shilling (and writing or contributing to) since the dawn of time  start of the podcast.

But to start with, before I get onto the book ( Build Better Products by Laura Klein), I’ll mention the podcast a bit more.

They introduce it every time as “The podcast where two old ladies yell at each other about how to make products suck slightly less”, and typically conclude by complaining about how they’ve run out of booze.

If you’re a UXer who likes talking about UX a) in a frank, open manner and b) in a pub, this might be a podcast for you.  They have a cynicism which is oddly refreshing in this particularly shiny and glossy field, and I’m pretty sure I’ve been to workshops presented by one or both of them at some point.  One of them probably helped me get into sketchnoting… which you might have noticed included in some of my other posts.

So.  The book.

It’s a no-nonsense, clear and straightforward guide to UX processes, which (for a nice change) acknowledges that some of us are in-house UXers working in the enterprise space, and so have to live with our work for years (decades!) in a way that just doesn’t happen the same way in the consumer world.

There are parts of if which I’d describe as leaning towards “my first UX” or “teaching grandmother to suck eggs”, but they’re wrapped in a mountain of useful advice and sane ways to make some fairly weird and wonderful UX practices actually make sense to business users and developers .

Really, I ought to wait until I’ve finished reading the book before blathering on about it, but this time I decided not to.  Why?  Because it’s that good.  Because not only does it make sense to me in the UX field, but it’s also written in a clear and concise way that  managers,   directors and developers will understand and find useful as well.

It’s not about putting some UX next to your product, or trying to smear it on at the end.  It’s about baking UX design thinking in throughout the life-cycle of the product.  From identifying user needs, through promoting behaviour that supports and addresses them and on to validating assumptions, measuring outcomes and then iterating based on what you find .

I’ll be making sure a copy gets added to our office library, and quite possibly demanding that our product management team, senior developers and architects get locked in a room until they’ve read it.  If you’re a UXer who works with other human, read it.  It’s a breath of fresh air. Written with the same combination of capability, realism, pride and self-effacing humour that the podcast has, it manages something that most UX books have utterly failed at: It provides an enjoyable and memorable reading experience .

If you work with a UXer and don’t really know what they actually do or why they keep asking weird questions and going off sideways from problems, you could do a lot worse than picking this up.

the_eggwhite: (Default)

Originally published at Eggwhite's Eggbox. You can comment here or there.

Two Bad Words

Nothing turns a design to crap faster than a certain two words.  They are the bane of my professional life. They are a signifier that work I’ve done is either the wrong work, the right work done at the wrong time or the right work done for the wrong people.  They are, without fail, the worst words to hear in response to a request for your work to be reviewed.

The words in question?

“Seems Fine.”

Give a shit

There are other words that can be similarly bad, but “Seems fine” basically boils down to “this was not important enough for me to give any time to”.

If it’s a design review, and you’re seriously and honestly not able to see any problems then shout it from the rooftops .  You have found the perfect, shining unicorn. Hand that designer all the money in the world and tell everyone else to retire because they are done .

If you are involved in a design process, be involved . Merely being present is not good enough. In the event that it’s not so perfect that a life of perpetual ecstasy would disappoint, say something .

If you don’t give a shit, you’re in the wrong place .  I don’t care what job you actually do, but if you don’t care enough to do more than phone it in then be up-front about it.  Remove yourself from the process.

Push Back

If you do give a shit, then push back .  It’s not even about disagreeing .   It’s about making sure that the design stands up.  A rough design that you agree with still needs to be challenged, otherwise that rough design is what you’ll ship .

All design thrives on creative tension – you can usually produce “good enough” without it, but is “good enough” all you want? Do you really want to ship your designer’s first draft?  They sure as hell don’t you to.

Constraint

A request for a design to be reviewed is a request for one of the following:

  • Information to inform or further constrain the next iteration of the design
  • Information to inform the complete restart of the design within different contraints
  • Confirmation that the design is the best it can be, given the established constraints

A first draft is more interview technique  than design

I always consider my first-draft to be an interview technique rather than a design. It’s a means to gather more information about what’s needed and refine the direction, rather than an actual attempt to deliver a solution.

The sacrificial first-cut is a long established way to tease out other people’s ideas. People are a lot more able to articulate what they’d rather see than they are to articulate what they want in the first place.

If you don’t push back, then you’re committing to a shot-in-the-dark .

Constraint

Design is all about constraints. Without constraints, all problems are trivial and solutions are obvious. Design, as a process, works best when the current result of that process is challenged and pushed to improve.

One of the best ways for that push to come is from tightening and refining the constraints – from speaking up when something is not good enough .

If everything is good enough from the outset, you’ll never get to actually good .

Summing Up

If you take one thing away from this post, take this:  If you’re meant to be involved in a design process, be involved or acknowledge that you’re not, acknowledge what that means and step away.

the_eggwhite: (Default)

Originally published at Eggwhite's Eggbox. You can comment here or there.

Half finished posts from the unpublished archives #1:

Anybody who’s worked in software know that one thing is virtually impossible to get: Positive feedback.  You’ll get negative feedback up the wazoo, but meaningful positive feedback is a right bugger to get hold of.

So how about we start asking for it more?  We’re always very good about inviting people to tell us what we’re getting wrong, but we’re also terrible about asking what we get right.

Why don’t we have a bug reporting tool that’s specifically designed on a “one up, one down” basis?  The idea here isn’t that you can’t submit bugs without giving praise too, but that giving meaningful, useful positive feedback gives the bugs you raise a higher priority. Yes, folks, I’m talking about bribery .

Raise a lot of bugs without giving any commentary about what we’re doing right?  Well, you’ll still get help, but we’d prefer it if you engaged with us on a less superficial level.  Tell us what you like.  We probably already know about the stuff you hate – we probably hate it too, but can’t get it on the table to fix it.  What we’re less clear on is if you’ve used the bits we don’t hear about.

As things stand, If you’re not complaining, it could go either way.  Either things are not bad enough to make you complain, or they’re so bad that you’ve stopped using those features and so have nothing to tell us about them.  We can’t know for sure.  “We’re pretty sure it’s not bad enough to make people complain” isn’t a great marker for design to aspire to.  There’s a big difference between “we got that right” and “we either did okay or did so badly nobody’s using it”, and being able to tell that difference would be nice.

the_eggwhite: (Default)

Originally published at Eggwhite's Eggbox. You can comment here or there.

My previous post generated a bit of commentary on one of the sites it syndicates to, so I thought I’d post them up here and follow up with a bit of response.

From Themadone:

“I think my answer would be that it should not feel like you’re trying to roll a large rock up a hill. With the obvious associated problems of something going wrong and you ending up at the bottom with a large rock on your face. Or finding the rock is stuck on something that you can’t readily see or do anything about.”

From Nojay:

“For various reasons my workflow involves an older graphics editing package, an esoteric OCR package, several web apps, another graphics package for review and testing and a batch image processing package for final release. I have to remember that “Paste” is Alt+F+W or [Shift+Insert] when editing, for the OCR package it’s [Ctrl+B] and for review it’s the classic [Ctrl+V] . Enterprise software MUST NOT work like this.”

I’ll acknowledge that I’m quoting a bit selectively in places, but can you spot the commonality between those responses? It’s been common with the verbal responses I’ve had too…

There’s a strong focus on what a good Enterprise UX isn’t .  The field is so bad that just not sucking is enough to be seen as a good experience.  That’s a pretty low bar.  It’s like having your personal best at the high jump being “didn’t tunnel underground”.

A couple of other responses did stray away from the negatives towards the positives - which I wasn’t really expecting.  I did my readership a disservice – which was nice to discover.  Some more selective quoting:

More from Nojay:

“That implies a consistent interface between apps with seamless switching and information transfer.”

From Katlinel*:

“Imperceptible? That is, the software enables you to accomplish the tasks you need to do, without getting in the way of those tasks. The software should facilitate this and not provide stumbling blocks that impede the user.”

From Cryx:

“At the moment user experience is often done like going to a convention. You open the door and there is a hubub of options. You may have a guide to the event, but you have to pick your way around to the areas of interest, and slowly fill up your bag with the info you want.”

“It should be more like you are the VIP. You say ‘I want X done, by X time’ and people scurry away and work out the best way to make it work for you. They come back and present the plan/information to you. They don’t go on at length about all the work they did, and keep asking you small questions. However if you bring your laser focus to a task they can tell you each step, and will let you modify things quickly and without fuss.”

From those it becomes clearer.

Good Enterprise UX plays nice

No enterprise software application exists in isolation – everything is just a step in somebody’s workflow, and needs to fit into that workflow.  Each enterprise application is there to fill a step, or some steps, or every step of somebody’s workflow… even if it’s not providing an end-to-end workflow, it’s still part of one and it needs to play nice with its neighbours.

It becomes clearer that enterprise software needs to not be a bottleneck or a hurdle.

Good Enterprise UX  works for you

I particularly like the analogy in the final quote – about enterprise UX needing to be more like a concierge or a team of employees, being ready with what you need when you need it… but also serving a large number of users. I’d like to take it further, though – for common behaviours, I don’t think I should have to ask.  The software should know who am and what I do – all of that information is available within an enterprise anyway.

If it’s being like a concierge, it should be a really good concierge who can anticipate my needs and have prepared some information ahead of time.  I should be able to start my interaction with that software by being greeted with a clear picture of what’s going to be relevant in that interaction, to pick and choose from and add to if needed.

So, the comments exercise this time is slightly different.

In your day job, you almost certainly use some kind of enterprise software.  If the UI for it was a very, very good (human) concierge or PA, what would it be doing for you?

Please let me know either as comments where you see this post, on the original blog post at www.eggbox.org.uk or however you like on social media – but please tell me where so I can read!

the_eggwhite: (Default)

Originally published at Eggwhite's Eggbox. You can comment here or there.

It’s been a fair while since I posted on here, so I thought I’d try kicking off again with a question, and then see what comes back.  But, because not everyone works in the same field I’d better define some terms first:

Enterprise Software is software designed to serve the needs of an enterprise (typically a larger business) rather than an individual, although individual human users still have to use it and may have multiple different jobs to do which require them to use it.

User Experience is what you have when you are one of those individual human users being forced (it’s rarely a choice you’d make on your own) to use it.

So, on to the question:

What does a  good  enterprise software user experience look and feel like?

Answers in comments please. Or on your own blog or social media of choice, but let me know about them here.

the_eggwhite: (Default)

Originally published at Eggwhite's Eggbox. You can comment here or there.

At work, I keep hammering on to people about how design is an iterative process.  How it’s not something that you do once at the start of a project and then never touch again.  Mostly my colleagues seem to get that and run with it, but occasionally I get farmed out to elsewhere in the company, where I find stark reminders of how much progress the team I usually work with have made.

The big eye-opener is to work with people who’ve never had the opportunity to learn about good design or how to shape a user experience.  Going right back to the basics like that reminds you of a few of your core ideas, and forces you to find new ways of expressing them.  On my most recent such excursion, I became a lot clearer about an idea I already knew and understood:

Good design is as much about the bad ideas as the good ones.

Bad ideas happen.  There’s no way around that.  They happen, and they chew up time and resources before they either finally get identified and cut away, or they get munged around until they’re workable.  In the really bad cases, they linger for a long time and chew up all that’s good about a project, leaving only an enthusiasm-free husk.

I’ve generally found that the bad ideas that hang around the longest are the ones that come out latest in the project… the ones that looked good when somebody suggested them at the 11th hour, and which grabbed all the remaining free time.  The ones that became somebody’s pet idea, which they couldn’t let die because they’d invested too much time already.  The “fixer-upper-opportunity” style time-and-money sinks that just seem worse every time you look at them, but that you can’t step away from because you don’t have the resources to start again.

It’s those ideas that are why I’m a big fan of collaborative, rapidly-iterating design processes early in a project.  To find the bad ideas, and to find them early.

The early stages of design are often referred to as “exploration”, and that’s an extremely appropriate word.  Exploration isn’t just about finding your way somewhere or finding the things you want… it’s also about finding and avoiding the pit traps, blind alleys and quicksand.  It’s not just finding the destination, but about avoiding the  hazards whilst doing so.

Good design isn’t just about making sure you build a perfect picnic bench.  It’s also about making sure you don’t build it on an ant colony, next to a sewage plant or halfway down a firing range.

So, folks, make sure you spend enough time identifying bad ideas… just so you know where they live and you can avoid straying too close to them by accident.

 

the_eggwhite: (Default)

Originally published at Eggwhite's Eggbox. You can comment here or there.

I’ve been thinking of this post for a while, and have decided that rather than trying to come up with a better way to explain it, I’d just explain how I picture it in my head.  Consider this post to be one-part UX design related and one-part insight into my mental processes.

It’s a UX related thing, but I’ve not been able to work out how to explain it particularly clearly. It’s a discussion of the complexity of designing a user experience versus the complexity of the resulting experience, and how it’s far from a one-to-one mapping between the two. By which I mean that a really simple experience can be really complicated and troublesome to design, whilst a complex looking design is often the result of a *lack* of complexity in the design process.

Read the rest of this entry  )

Profile

the_eggwhite: (Default)
the_eggwhite

May 2017

S M T W T F S
  1 23456
78910111213
14151617181920
21222324252627
28293031   

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 28th, 2017 04:45 am
Powered by Dreamwidth Studios