Skip to content

Agile, blasphemy & burning bridges – UX Design Day

UX Design Day speaker Phil Fierlinger

Last week I managed to stir things up a bit during the UX Design Day conference. I did a talk about our design approach at Xero and got a bit…passionate…about some topics near and dear to my heart.

I ended up letting a few f* bombs fly, captured for posterity on the twitters.

F* lorem ipsum! F* style guides! F* agile sprints!

We design the dream solution, but it’s only a f*ing dream until you ship.

At Xero our philosophy is to build bridges – while we’re running across them…but we also burn the bridge behind us, to make sure we’re constantly innovating.

I stand by my words. We’re constantly challenging conventional wisdom and challenging ourselves to do things better at every turn – we can’t stagnate and we can’t let ourselves be held back by any ideological or technical dogmas.

One issue I raised more than any other resulted in a flood of feedback, like this email I just got…

It seems to me that agile isn’t being used because it is a good or bad tool, but because people think they need it like a security blanket and a dummy.

When we started Xero, we deliberately avoided following any particular development methodology. But as we grow, our dev teams are in various stages of Agile adoption and doctrine.

We’re still negotiating how Agile fits with our design & development workflow, but as you can tell I’m definitely challenging Agile’s place in our design process.

Don’t get me wrong. I don’t necessarily think Agile is all bad. I love the underlying spirit of Agile. I just question the dogma. And more than anything this sums up my biggest issue with Agile…

Creating big ideas isn't really compatible with agile... It doesn't think about the entire flow

(the meta-awesome thing about that tweet is Benjamin Humphrey is a designer working on JIRA, the Agile development tool…that we use at Xero!)

Unlike most software companies, we don’t code anything until we have a complete design solution. You can run after me with a pitchfork and call me a witch who practices waterfall, but design is truly the start of everything we do and that’s our major competitive advantage.

Our design team invests time understanding and solving people problems, not technical problems. It’s much much harder to solve people problems. Tech problems are comparatively simple to solve when you have a group of incredibly smart & talented engineers.

Our approach to solving people problems is to say “if we could wave a magic wand, what would we do?” And that’s what we design. We look at the big picture, the workflow beyond our software and we think about everything that has preceded and will flow on from the problem we’re solving. That’s how we discover ways to change the game, to change people’s lives, to change the way people think and behave.

However, we can’t build the dream solution all at once. It would take too long. Like I said, it’s not a dream come true unless you ship. So we scale things back and re-design our solution for a v1 release, an MVP, or to borrow a beautiful metaphor presented at UXDD by Thomas Bauer – we create the first triangle of the snowflake.

That’s when Agile kicks in.

That’s when we can collaborate with the dev team to adapt our designs to work within their sprints – AFTER we solve the people problems and have a design for the dream solution. That’s when we have something that can be broken down into small sprints.

UX Design Day was a brilliant event to share these ideas and get the discussion going. There were so many other great presentations that also challenged conventional wisdom and practices. Ruth Brown talked about data driven design and made the great point “If you’re right, you learn nothing” – we’re all prone to confirmation bias, so we always need to challenge results, especially when they confirm our existing beliefs. Anais Adrid, a design researcher, shared her epiphany that there’s not much value in personas and wordy documentation. Wes Yun challenged the foundations of design by asking…

Your design is good, but what good is it doing?

It was a great showcase of talent in the community. I got to meet so many new people who are just as passionate about questioning and challenging conventional approaches, coming up with new ways to solving big problems, with great design thinking. And if that describes you, I’d love to meet you.

Xero accounting software flyer designs

 

Read more about Technology, Design

 

6 comments

Steve Shepherd
17 October 2013 #

I love this approach.
I have used the services of a company called http://www.cooper.com which have been really focused on User goal oriented design.

Their approach was to work out what the goals of typical users are Day to Day, Weekly and then Important but Infrequent.

They explain good design like a car.
The steering wheel, gear shift, accelerator are all finished to a high degree and are very functional because we use them very often.
The interior of the car is nice to be in and functional.
The engine is not finished to the same level but is still very functional.

Goals are also different to how we get there. For example in 1860 to go from Vegas to San Fran was the same goal as it is now. However in 1860 the HOW was by horse or train. Now the how is by Plane or Car. The goals is the same the how is different.

With software we need to stand back and always check the goal.

We use these principles in our solutions all the time…

Johannes
18 October 2013 #

Nicely summed up. Especially agree with “solving people problems, not technical problems”, along with build what’s designed not design what can be built.

Andrew Tokeley
18 October 2013 #

Must have been an interesting talk – pity I missed it! I think one of the reasons an upfront design phase can work, as opposed to the anti-pattern of a large upfront business analysis effort, is that it’s a lot quicker to iterate over and at a higher level. Our design effort isn’t going into the minutiae of every business rule, it’s exploring and defining the paths and experiences through a workflow or experience. Designs can (and do) change through the development phase as part of the more traditional agile process we follow but I’ve not yet felt any regret about thinking about design upfront.

Romeo Rabina
19 October 2013 #

Must be what sets you apart from the rest of us where our Project(s) are started by the Dilbert methodology run by numerous Project managers not knowing anything about the Application.

John Reed
8 November 2013 #

Sounds great that you love the design side so much and sounds hopeful for me as a user for Xero.

What I dont get is why there are some real usability “no they didnt” decisions in the product that ships at the moment.

One common one that effects me the most is when you drill down and cant go back, you have to start the process all over again [i.e. Home Page > Aged Receivables > Customer Name > Value of Invoices for a Month > Invoice Itself and then once Ive added my note or checked what I wanted to check that's it. No back button. No breadcrumb to safely get you back, You have to risk the browser back button, will it work, will it unpick something I have done or cause me an error. Who knows. So now I right click and have windows open all over so I don't have to keep re-tracing my steps.

There is another one which comes up enough when I am doing invoices, I will add a post when I am next doing it. I cant recreate it at the moment.

I love Xero and hence why I am taking 5 mins to write to someone who loves design as much as I love using good design. Xero makes some part of my life so easy, but some others [Mainly the basic things I take for granted] sooooo annoying. Right now after 9 months of using it I would say they balance each other out equally. But 10% extra polish and it could really really be so good.

Richard
20 December 2013 #

I think agile is interesting, but for it to work if you’re following the dogma you must accept the possibility of complete refactor at any time, and refactoring is likely to be a frequent part of doing business. Companies are not willing to accept that. Think of the cost, and the re-testing! It takes a lot of effort to have auto-tests you can be confident in, and that are not coupled to implementation in a way that makes refactoring impossibly expensive. So decisions made in early sprints are stuck, and growing can become harder.

You can try to mitigate this at the architecture level by having software architects who are (perhaps against the dogma) thinking ahead a little and making sure you really follow solid design principles. You have to strictly isolate concerns. You have to make code that is easy to change and protects modules against changes in other modules. You need good developers to make it work.

I’m not sure how this plays out in UX/UI, unless you can make your UI layer easy to change so refactoring cost is low. This could again come down to strict adherent to good practice with separation of UI and logic. Doing it properly up front saves again and again down the line.

Add your comment





We welcome all feedback but prefer a real name and email address.