Are you seriously expecting anyone to be able to read that?

I’ve used Garmin software and GPS devices for what feels like about 10 years now. I used to be forced to use PC emulators on a mac (back in the bad old days) with assorted “coping” paraphernalia – such as USD to Serial Port adapters because Garmin were very late adopters (of USB). Then a few years back they brought out the Edge computers and started producing software for us Mac users – starting with something called RoadTrip and (more recently) BaseCamp. Awesome.

I have no clue why there are two different software packages – I think RoadTrip is more road oriented and BaseCamp is more for the off road walker / mountain biker, although they seem to offer the same tools and (obviously) use the same maps. And, I think you can guess where this is going – neither works very well. In fact, in recent updates, Garmin seem to have simplified RoadTrip to a point of complete unusability for any practical purpose, but first, a bit more about how I use this software.

So I mainly use BaseCamp to create route plans that I can put on my GPS and then go out and follow for an interesting / different bike ride. I generally do this by planning out a set of very few (10-20 for a 100km ride) key waypoints – something called a route. The alternative is to use something called a “track” which puts a location point every (for example) 50m  or so. I prefer the former because I find it more reliably gives me directions (turn right in 100m) based on the underlying map. The latter only really gives directions if it has detected a sharp turn, so you have to keep a much closer eye on the map (not so great if you’re hammering along at 35kph on a road bike).

And that is the start of the problem.

There have always been challenges. The thing about routes is the computer / portable device has to calculate which road(s) to take between the waypoints. When I’m creating a route on the computer, I want to balance having enough waypoints to force it (the computer) to follow a particular route from A to B to C … Z, but not so many that the portable unit is telling me every 5 minutes that I am “approaching XYZ”, “passing XYX”.

Apparently it is impossible to get the computer and the portable unit to plan the same route. Many many times on a route, I find myself cycling down a road and then being told to do a U-Turn, not because I’ve gone wrong, but because the head unit has calculated the route differently and is just trying to include a waypoint to tick it off, not because I actually wanted to go that way. Now, to be honest, over the years I’ve got used to it. Ride the route, find the problems, get back to computer and revise route looking at original plan and track to figure out how to force it to do the right thing next time. It’s annoying (it’s the same map, and the same manufacturer – why is the route planning different / using different criteria!), but it doesn’t make my blood boil. Maybe (if they haven’t gone bankrupt) Garmin will get it right before I die, but I’m not going to hold my breath.

So, given you now have all this background, imagine my frustration with the latest version of BaseCamp.

I click on a waypoint to start creating a route. It is selected. I can’t move it. I can’t do ANYTHING with it. All I can do is delete it and create a new one which will destroy a number of other routes that also use this waypoint.

I click on the create route tool… Up pops a helpful window with two “drop zones”, one for the start of my route and the other for my destination. Now, if I was creating as simple a route as this, I wouldn’t bother to use the computer software. But anyhow, I can click the “Advanced” mode. And then I am stuck. I can add existing waypoints, but that’s it. I used to be able to use the route tool to click click click, merrily plotting out a route in sequence. Nope, if I click on that, I lose my “Advanced Mode” and go back to the “pick a start and a destination” mode only.

There are lots and lots of frustrations around the recent “advances” in this software that have been driving me nuts for several hours now. And true upshot, is it’s now not really any use to me. Question is – what do I do now – at the moment, Garmin are the only company with anything like this combination of mapping / bicycle / fitness (heart rate etc). Come on all you others: Polar pull your finger out, Suunto did you just give up after doing fancy watches with a GPS compass… and Magellan I assume you’re just wallowing in the shallows not really bothering to fight the war against Garmin anymore.

Oh well. Looks like downloading RoadTrip and seeing if that works any better than BaseCamp. Another morning lost.

So, step one, instead of guesstimating my maximum heart rate, the guy recommends doing a Lactic Threshold Heart Rate test. This is pretty simple – cycle full pelt for 30 minutes and (using a heart rate monitor) get your average heart rate for the last 20. Then there’s a massive table for working out a set of heart rate zones. Haven’t really started using the zones yet, but I did the test on Saturday around Richmond Park. It hurt. In case you want to know what pain looks like – here’s a graph (oh, the dips are when I got stuck in traffic):

I avoided some cycling over the weekend to build out a training plan – so let’s see how things progress on that front. In the meantime, I happened across a message on the London Dynamo forum that mentioned an Easter Classic sportive on the Monday. The weather looked good. The course was pretty flat (by all accounts). The only real pain point was a tendency for headwinds. Oh, and somebody from the club did it in 3h 20mins last year.

I set off, bright and early on Monday morning. Joined the big queue to sign on. Said hello to a couple of other London Dynamo riders who were around, but kind of kept myself to myself as I was planning on a fairly gentle run (I was supposed to be going mountain biking in Epping the same evening). As tends to happen though, I got talking to a bunch of guys some of whom had these pretty cool “skate” something jerseys on. We decided to set off together, so rolled over the timing mat and headed off up the road. It was a short while in that I realised we were going at quite a pace. It was only then that I actually bothered to read one of the jerseys (that had been right in front of me the whole time) – London Skating – Speed Team… hmmm… This isn’t going to be a gentle ride after all (thankfully, after a day off, I wasn’t feeling too bad myself). So, instead of quietly rolling round the course, we completed it in 4h (including 15 minutes while people caught back up at the halfway point, and another 15 when I hit a big pothole blowing a tyre, rotating my handlebars about 15 degrees and, as I realised a bit later, poleaxing my wheels).

A tough ride, but great company and an unexpected result. Thanks guys.

In case you hadn’t noticed, I was conspicuously absent. Sorry about that – I got caught in a trinity of project deadlines, staff sickness and maternity leave (not mine – honest). The good news is that all is looking better. The projects are back on track, and I’m looking forward to heading out to Lisbon in a couple of weeks time – both to be at and see the conference (you know – I’ve never actually attended a “big” conference) and to do a quick 20 minute lightning talk on ux/agile (a brief overview, and some thoughts around designing without wireframes). See you there (oh, and here’s the customary preview of the deck – as always, you’ll need to be there for it to make more sense).

See you there.

For those of you who just want to find out a little bit more about our experiences “doing agile” in the world of financial software, I’ll also be talking at the main event. You can catch me on Sunday morning (April 3) when I’ll be chatting about my favourite topic “Wireframes are dead“.

Finally, a confession. I am running a couple of side-agenda’s with my trip stateside.

Apparently the snow in Colorado is “quite nice” so we’re going to stop off in Vale just before the conference. The last time I was seen snowboarding stateside was back in 2005 up in Mount Baker. It was my first attempt at any snow sport and I spent a merry couple of hours falling on my butt on a sheet of ice adjacent to the car park there. Two tubs of Tiger Balm that evening, and I still wanted to go back for more (maybe that’s more revealing than I’d like it to be). Then, to round off the trip, I’m stopping by the Lab49 office in New York en route back to London. Looking forward to catching up with the cool cats near Wall Street.

So this is more about my thinking and reasoning so far.

In any agile project, the team aims to be continually delivering software. That can be through client reviews at the end of your two week, three week, or longer “sprints” if you’re using something like scrum; at the end of each task in Kanban; but usually using some sort of continuous build as the foundation. From a UX point of view, you are working on the functional design and creative execution of individual features that you will share with the developers to get built. Exactly how you actually do this doesn’t matter right now, but I will write and talk about it in the future. It is, however, important to remember that what gets reviewed and signed off is the software. Anything else you create along the way is transient ephemera.

As part of this feature focussed sign off process, how do we ensure and maintain an appropriate level of quality for the functional design and creative execution? I know if I talk to a creative, then anything less than their idea of perfection is not good enough (I say “their idea” because this varies hugely according to the talent of the individual). I know some product owners would also aim for perfection. I also know some who don’t care.

In a developer-land without UX you can quite quickly and quite easily decide whether or not something is suitable for release. Let’s be slightly simplistic here, Good Enough to release is usually described in terms of number of bugs. For example, this can be anything from no priority one bugs and x% of outstanding priority two bugs resolved, to zero bugs at all (say for healthcare or military applications). So Good Enough is completed functionality with a bug constrained definition of quality.

In the world of agile software development, the product owner is king, but even if you have a number of stakeholders you face the same problem. We need to manage expectations of creative and functional design quality with the product owner (based on time and resource availability) and the corresponding creative and functional design ambitions of the UX people. We have a process that delivers chunks of an interface in incremental stages. However, one poorly (or excellently) executed but prominent piece of work can completely define (destroy) the perception of the product.

It seems to me that we need some kind of benchmark to evaluate the finished software as Good Enough from a UX perspective. And that needs to be locked in on day one, agreed across the whole team as the expectation for “Good Enough”, and unambiguous enough to actually be useful, usable and constructive. It may change (up or down) and if the standard goes up, then there will be a trigger (and justification) to refactor.

There are several ways you could measure quality after the fact. You can do usability tests on the finished product. You can plan to “refactor” the look and feel at periodic intervals due to design evolution. You can check that things match the definitions of intermediate artefacts (wireframe documents if you do them, Photoshop files etc). But how does this help you when you are in the flow of producing the product?

I’m struggling with defining an answer. I think there’s interesting mileage in The Kano Models that Andrew Harder was talking about in the session after me. Right now, I’m just trying to frame some thoughts around how product designers work to differing standards of “good enough” and how, from the outside looking in, I perceive those. The first angle is thinking about the value properties of different types of products:

The Farm Tractor: Supremely practical and functional. Versatility and performance completely override traditional notions of “beauty”, but there is still a sense of style and visual impact that they manage to create.

The Toyota: Pragmatically well constructed, but doesn’t excel in any particular arena or feel particularly special. Definitely not going to be winning any beauty pageants, but similarly not horribly offensive to the eyes.

The Dyson: Stand-out functionality but with a unique, innate beauty – but with a love it / hate it twist.

My second slant, is thinking about multi-brand manufacturers. The diversity of the VAG group is interesting here. They seem to have a spectrum of quality of engineering / monetary value / beauty / performance. Skoda is your basic, functional brand. Seat is a bit more performance oriented, but still not expensive. VW is solid engineering and quality. Audi is the crown jewel of exclusivity, beauty and speed.

Now, how do you apply this to Software Experience Design. That I need to think some more on…

Garmin‘s Connect website for uploading and browsing all the pulse, hardware and location data their devices collect when you’re running, cycling, walking, is down for maintenance right now.

The visuals and messaging around a normally negative event is really quite nice for a company that doesn’t always excel at design and customer centricity.

The Talk

Two years ago, I joined a software development consultancy (Lab49). We’re specialists at creating bespoke software for human based trading, algorithmic trading and risk management within wholesale or investment banking. Most of the projects there are run on agile principles – typically “Lean Agile” and Scrum, but lately we’ve been exploiting the benefits of Kanban and investigating Srumban. Previously, I worked in advertising.

To say I had a hill to climb is definitely true. I was the first UX employee in the company, and I had to figure out capital markets, consultancy and agile PDQ. Happily I’d already had some exposure to all three – but not all at once.

We’re now two years further down the line, and I’ve learned a lot. In my talk at UX People, I’ll be sharing with you some of the ideas and processes that we decided weren’t effective enough, the concepts we’re trying next and some attitudinal and practical ideas that you can take back to your own business and apply if you work in an agile environment.

For now, as a tiny sneak preview, here’s my presentation. Don’t expect to get the speech from the slides. I might follow this up in the coming weeks with short posts on some of the topics that explains my thoughts and learnings.

The Workshop

The afternoon workshop is going to be very exploratory in nature. All the headline agile methodologies (RUP, Scrum, XP) have been originated from a software production / development point of view with a tendency to assume that each individual is an expert generalist at everything needed to complete a task (UI design, coding, testing).

We have the rare treat of some space and time. Let’s think about what a UX originated agile process might look like. What would we borrow from the existing techniques? Do we like time boxing or pull? How do we construct a simple and effective team of specialists to complete a complex piece of software or a website?

The Take-Away

It’s very difficult to get even vague information on who the audience is at many events. Unless you know them personally it seems many conferences recruit from a broad spectrum of the populous (to ensure they sell out). So don’t expect detailed personas and profiles to target, but do remember that people can self-select if your description of your topic is appropriate and accurate (more about that later).

Most importantly, it’s worth remembering that everyone will have invested something to attend – their personal time, their own money, political capital convincing their employer (boss, colleagues) it is worth spending some budget to send them on a jolly and they deserve to go. So, whatever you’re going to do, there has to be a point… from an hour’s session in a pub after work to holding court in a hall of 200 people – your audience must have a clear idea as to why they are there. Even more important, they must have an absolutely clear idea of what they learned and why they would come back to you for more.

If you’re not sure that people are going to learn, where the “value” is or you’re not sure why it’s important, then think twice about your topic. Is it genuinely something a broad spectrum of people are going to want to learn about, or is it so niche that you know the other 3 people who work in the field. Is it truly valuable, or just showboating…

Form needs to follow Function

Think about the form that will best suit what it is you want achieve.

Are you looking to explore something that’s relatively new, cutting edge or innovative? Do you want collaboration and collective input to improve the idea you have? If so, then a workshop is probably the appropriate mode of delivery.

If you are talking about something more established, or a particular experience you’ve had trying a methodology, technique or even just the peculiarities of a particular industrial vertical, then a presentation is more appropriate.

Engagement

Tricky. Especially when you’re embarking on a presentation. How do you avoid it becoming just another lecture? We’ve all sat there, frantically making notes, but not really taking anything in. How do manage to maintain some level of audience participation especially if there’s 200 of them? Oh, and a Q&A session at the end doesn’t count.

Schedule

This was an interesting idea. Rather than starting with a deck of slides, think about how much time you have, what you want to talk about and turn it into a schedule. How long are you going to spend introducing the main topic, what aspects of the main topic do you realistically have time to discuss, when are your audience interactions going to occur and how long (really) will they take. 60 minutes goes really fast when you’re talking (but not necessarily so when you’re listening) so how are you going to keep it meaningful, maintain a narrative thread and get the balance right between detail, time, and coverage of your topic? The simple idea of creating a schedule (maybe broken down into 10 minute blocks as a reasonable working unit of time) seemed a very constructive way of chunking a session and simultaneously ensuring narrative flow (because as you schedule you build your story).

Structure

Not a lot to say about this point – just remember you need a beginning, middle and end. If it’s going to be a long session, maybe think about using the 3 or 4 act play as a helpful construct.

Submission

When you’re creating your submission for selection at a large conference, it’s worth remembering that the audience for your submission is very different to the one that’s going to participate in your presentation or workshop.

Think about what a time-poor reviewer of 100s of submissions is going to need. A memorable title (but one that is meaningful to your ultimate audience). A more descriptive subtitle if one is permitted. A detailed and descriptive abstract that talks about the session, not you.

For both the reviewers and people attending the conference, think about what people will learn, where is there value, why it’s important and remember. Even better, if the abstract for selection is different to the one that appears on the website inviting attendees, then you can change the focus and terminology. It’s a fairly safe bet that reviewers will be slightly better informed than many of the attendees (maybe).

Other Useful Resources about Talking at Conferences

How I Approach Presentations: David Armano recently wrote an interesting piece based on a discussion between himself and Russ Unger about presenting at conferences.

Slightly older, but also useful, is Cameron Moll’s post in the now established “20 best…” style, but this ones: 20 Tips for Better Conference Speaking

Plus there’s lots of people talking about the do’s and don’ts of PowerPoint (or Keynote, which is my preferred tool): @jessedee offers some good food for thought in a no-nonsense manner in Steal This Presentation, and Presentation Zen’s musings on What is good PowerPoint design is always a good reminder and a quick read.

Fast forward a year or so and I was pretty confident on-piste, but every time I ventured into the back country (with guides) I seemed to end up in situations where I was very, well I guess the polite term is “uncertain”.

So, when I got the chance of 4 unbroken weeks in the mountains in winter (aka a sabbatical) I thought I’d spend some of it going back to snow school. I had a week on my own in Morzine, then a week in group lessons in Tignes (where I learnt that confidence doesn’t equate to skill) and, well, that’s how I met Neil and splashed some cash on more focussed, private coaching. Within days he had me riding terrain I thought I’d never do. Hiking off into the backcountry to places where you can’t see the lifts (and not just because of a whiteout). Riding through (relatively gentle) couloirs, and generally having a spectacular time whilst continually improving.

I’ve been back to Tignes for a winter break every year since. There’s not many photos ‘cos we’re usually having too much fun on-piste, off-piste or maybe even in the arse-end of nowhere. I thought the time for being taught was over, and the time for new pistes and environments would come – but I love spending time with Neil, learning more as he coaches me to be better, going further and into more challenging terrain. He has a knack of knowing just how hard to push you – so you grow and develop but don’t scare yourself rigid (well, mostly).

So why am I writing this reminiscence now, especially as it’s the middle of summer… Because, after damaging my sciatic nerve earlier this year, I made it back onto a snowboard last week – which was such a nice feeling. Also, Neil’s now struck out alone. So if you want to learn, develop and go be excited by the multiple possibilities of a single plank of wood and some bindings – Tignes has the terrain, and Neil has the know how, and has just set up his own venture in the place he calls home.

mcnairsnowsports.com