Spencer Turner - Designer On Rails

Building Communities

2010-11-11T00:00:00-05:00

Building communities around your product is a really great way to grow your userbase and enhance your brand if you do it right.

Riverford really get this right…

My wife, son and I recently went to “Pumpkin day” at the Riverford farm that is local to us.

Wow. Really brilliant community building. Free entry, no overpriced nonsense, great easily accessible entertainment for the children, a box of (free) fruit by the door, A nice tour of the farm…I could go on.

What I found so inspiring was the lack of commercialisation of the whole thing. Enormous pumpkins were £2, the coffee was less than a coffee shop, there was a discount on all farm products on sale by default.

Everything was simply, here’s what we do. No hard sell, just enjoying the farm for what it was…My son was really excited (and slightly incredulous) that he was allowed to pick and taste the herbs, straight from where they were growing.

I don’t really have any more point to make than if you open your product up to people, in a genuine and engaging way, you’ll enhance your brand, and possibly even gain new customers.

Compromise without compromising

2010-09-17T00:00:00-04:00

You all know that feeling - something’s got to give…

Time, budget or features? Oh wait a minute…interface! That can give…our code is more important, that’s what makes the product work, right? Well no. (And yes, but mainly no.)

The user (generally) only sees the interface, and has no concept of the code behind it.

I keep hitting this at the moment. Life isn’t a green field project and it’s inevitable you have to compromise, the issue for me is that UI / UX is often an easy target for ‘not MVP’ slashing. I see that’s often acceptable, but sometimes it’s a cut to far. This is for me where you have to choose your battles.

Where is the line?

For me, when I start a new project, I always aim for perfection. In the back of my mind, I am assessing where I’ll pare that back to meet the inevitable constrains. I am also assessing a baseline of acceptable functionality, usability and user familiarity beneath which we cannot compromise.

The line is different for every project. I base this off the constraints and embrace change as it happens. This is really hard when it’s a major change mid project, but things happen and sometimes you have to roll with them. (In my case, with accompanying grumbling!)

So how do you find this line?

Acceptable loss

I try to ask myself what is my motivation for arguing for this? If we lose this element, are we below the ‘baseline’ standard? Are we near enough the baseline standard that the next (inevitable) compromise will push us below it? Can we find a different solution that pushes us back up the scale of acceptable?

Sometimes, it’s simply that I really like that element/feature/behaviour/colour. That’s when I walk away…

Sometimes it’s that I know a bar has already been set in the ether, that we will sink below if we cut something. This is harder, sometimes there is a compromise to be found, that still delivers enough that the UX won’t be compromised, sometimes there isn’t and you have to decide if you are better killing the whole feature than under-delivering.

Sometimes it’s IE6. Check your logs, see how many IE6 users you have and if your client can live with loosing X% of non-upgraders. If they have corporate clients, often this simply isn’t possible. In this instance, I’ve started to favour an IE6 specifically compromised approach. Make it minimally functional and that’s it. (Or accept you need to double your project cost!)

Is massive improvement enough?

Often the starting point of a project is so bad, that you can’t really help but improve it. The issue for me then becomes one of setting expectation for ongoing improvement. UX / UI (certainly in the agile context) is an iterative process and when you release, it’s NOT done. On the other hand, I have to accept that a great improvement, is probably a totally acceptable compromise for release one.

Make friends not enemies.

I am not an island. I’ve found that if I can get people to mind-shift and understand the value of UX, I have an incrementally easier time when the next compromise has to be discussed.

My stance is to champion quality. I am not interested in glossy UI. (Nice though it is) I am interested in delivering a product for the client that turns users into advocates. I believe this is done by removing friction from their experience, making things easily usable and not forcing them to learn new interface models when the existing ones aren’t broken.

Live with it.

I have to compromise. You will (unless you are omnipotent) have to compromise at some point. I try to compromise where it’s OK, stand my ground, where I know I really should, and choose my battles everywhere in-between. If you battle over every last thing, you’ll make enemies, not friends. This will make your life harder, I know, I’ve tried it in the past!

Something I’ve seen a few times recently is the current shift to mobile devices. Mobile devices offer additional functionality such as location. Here the compromise is dangerous. You can easily deliver a ‘broken’ experience by not embracing the technological expectation of the users. ‘What, I can’t search near me? Lame.’ I also feel that just because you can, doesn’t mean you should. The ‘we need a mobile app’ mentality only holds up, only if you really do. I try to persuade the client to think about their user, what is the mobile app actually allowing them to do?

Reality is that it’s the new hotness and so you’ll probably not win this one ;-)

Don’t beat yourself up.

At the end of the day, I find, I live with relinquishing things and compromising by knowing that I’ve fought for the important stuff, and I hope that this communicates back to the team/client that I have the project’s best interests at heart.

Agile UX and Design - What's in it for me?

2010-07-20T00:00:00-04:00

A friend nudged me on twitter to write a blog post about this, which was great for two reasons, firstly I was having a bad case of writers block (or at least procrastination), lots of things had made me nearly write a blog post, but not quite catalysed. (UX of Riverford’s new store, Should you try and make your copy SMART? etc.) Secondly, we are going to a UX retreat this weekend, and I think this might be a topic I want to discuss there, so thank you James for the timely inspiration.

Creatives and agile – The smell of fear…

When I first started at Eden; in the designer part of my role, faced with an agile developer asking me to commit to short iterations, my gut instinct was panic. Not because I felt incapable, but because creativity isn’t something you always have, or can turn on, on demand. This was of course not the right reaction, or even justified. It was however, I suspect what most ‘creatives’ feel when faced for the first time with seemingly short iterations.

Reality Check

It’s true, creativity waxes and wanes, but we cope with this all the time.

What are the tricks we use to do this?

Limiting the fidelity that we work at (In the traditional design world, Marker visuals, Lorem ispum, Photoshop comps, low-res thumbnails of photos)
Trying our ideas out as quickly as possibly and discarding LOTS of bad ones. You still scribble stuff, right?
Slowly refining and enhancing ideas and designs (thumbnails, to mockups, to proofs etc.)
Working with a team to get things done quicker
Only presenting part of the solution (e.g. We need the Brochure first, lets start there)
Getting feedback from the client and refining at each stage.
Building some extra time into the deadline to make sure there is ‘wriggle room’

Hmmm - Maybe it’s not so bad… Breathe.

You are already doing it!

Limiting fidelity, Agile Story Cards are a lo-fi method of capturing the idea of a piece of functionality.
Slow refinement - well that’s iterative development
Working with a team - You are part of the team (and maybe have your own team as well - double win!)
Only present part of the solution - Work on a small chunk of functionality at a time
Getting feedback early - Weekly (or even daily or less) releases mean constant feedback.
Wriggle room - You should be in the planning meeting and state if you can do it in time.

But What’s in it for me?

Shorter time-frames add focus. Given longer, I won’t actually get more done, I’ll procrastinate until I have a looming deadline, then find focus.
You’ll have happy customers At the end of the day, we all want to deliver things customers are happy with. The problem is that at the beginning of most projects, the customers think they know what that is (and don’t) and you think you undertsnd what they want (and don’t). If you do Agile design right, you can combat this by really establishing what the needs are and then delivering a solution to the real problem.
Built in Fail. Sounds odd, I know, but it is liberating to acknowledge that you don’t have a crystal ball, and it’s not reasonable to expect to entirely acurately understand every problem and therfore, it’s impossible to provide a correct solution first time, every time.
When you do get to see the whole, you have something real to design If you’ve iterated on your project, and kept the design (skinning) to a minimum, you can at the last responsible moment, start doing PSDs with the benefit of a working prototype which removes the ‘we’ll probably need a twitter widget here’ page filling that creating PSDs often induces.

What techniques can I use.

This is a blog-post (or series) in itself. However, we’ve been trying out Story Mapping, and Sketchboarding, both of which we’ve found pretty helpful.

My main tips are:

Pens and paper Scribble your ideas, perfect drawing is not required (anyone can draw a box!) and use it as a tool to facilitate conversation about your ideas.
Conversation You need to talk. To your client, to thier stakeholders, to your team, to your developers and ideally along the line, you should talk to users (a lot).
Avoid Photoshop early on We’ve found that photoshop gives a false impression of a finished solution. Unless your stakeholders need Photoshop visuals to get buy in, we say avoid them. Try and steer them towards wireframing. If they need them for buy-in (which many do) be very clear that they are an indication of what could be. Nothing more.

Caveat lector

No amount of Agile allows you to not have to think. You still need an overview of the whole project in the back of your mind, when you are working on a small piece.

You’ll have to have an understanding not just of the problem, but of the solution, the technologies, the implications of decisions on the team and budget.

You will have to push back against developers and customers from time to time. That’s OK. Defend the things you genuinely feel are required.

You are part of the team

Agile is all about collaboration. You need to be one of the team. Seriously, the siloing of creative vs. technical is just rubbish. Developers are unlikely to have your skills and vice versa. You will learn and teach a lot (as will they). Share your skills liberally, and everyone will benefit.

I think there is a whole post in how you get ‘on the team’ and as it’s late and this is already a long post, I’ll come back to that another time.

Interface should indicate behaviour

2010-05-06T00:00:00-04:00

OK, so it’s sad to admit, but I think about user-interface quite a lot outside of work. (And should write about it more often, but that’s a different issue!) We recently bought a new house, which is great, but like a UX project, coming to someone else’s work, you suddenly realise all the things you take for granted as ‘just right’…

The cupboard handle that prompted a blog post

There is lots of built in storage in our new house, which is great. However, the handles on the cupboards look exactly the same as the door handles on the actual doors…Sounds correct, right? Good design, giving a consistent finish.

The only problem is that the cupboard doors don’t have latches, they have magnets and so are a pull handle, the main doors are turn and pull as they have mortice latches. The cupboard door handles still turn, so I find my self turning the handle, finding it stiff and wondering why the door isn’t opening with a click. I know in the back of my head that this isn’t the behavior as I’ve learned that through repeated annoyance, but I still do it wrong more times than right.

The thing this triggered in me was that interface should indicate behaviour, above design consistency even. I’d rather have different cupboard door handles (that look nice in combination with the main door handles, aesthetics being important as well!) but that clearly indicate the behaviour to be a pull, not a turn.

Things that look simple and ‘just right’ are only that way because the person planning it did a good job

We were spoilt with our last house, and I didn’t realise it. My father in law is a retired electrical engineer and kindly helped up plan the electrics in our previous house. (which needed a total rewire) I have to say, at the time I thought the number of light switches he was suggesting seemed overkill. Why would I need to be able to turn the downstairs light off from upstairs? Why do I need a pull cord over the bed to switch the bedroom light off? Surely it’s common sense to have enough power sockets?

No so. Our new house, I have to walk downstairs to turn the light off, I can only turn certain rooms lights on from one side, so I have to follow a specific route in the dark to get to where I want to go. (not the shortest route obviously) If I want more than 2 appliances plugged in, in any room, I need a trailing socket. Now, none of these things are life-threatening, or even seriously annoying, except when you have come to expect that level of thought to have gone into something, you miss it when it is not there.

The lessons for me here were 2 fold. Firstly, that things that seems obviously correct, often aren’t as simple as someone made it look. Secondly that craftsmen are everywhere. Unassumingly doing a good job, and not shouting about it.

Finally, I’d like to say thanks Bryan for the excellent planning of our electrics. I only now understand how clever that ‘simply right’-ness was!

Welcome

2009-12-14T00:00:00-05:00

Welcome to the new Designer On Rails blog. Now with added Jeykll!