The importance and irrelevance of design

So design is important right?  You wouldn't want to just build something without a bit of thought going in to it first.  Problem is that 'design' can and often is very important, but it's also kind of irrelevant in the end.  Okay, so that explains the blog title without really explaining what I mean (hey, otherwise it would just be a really short blog post after all).  Now I'm all about learning and so naturally I'm thinking learning design in the main here, but this applies all round.  Let me give you a learning example because that's where I'm most comfortable (I was going to pick buildings but with laws and codes of compliance I'm sure I'd fall foul of something).  A company approaches me (very wisely I must say) to build them a course for customer service training.  Six weeks later I deliver them the world's finest customer service training module and they are delighted, it gets rave reviews from their staff and has measurable impact on their business.  Great.  But what about the design?  Did I do it at all?  Say instead they'd gone to company B instead of to me (why, why?).  Company B is very process driven - the plan for the learning piece is extensive and covers every angle it seems and is the plan itself is part of the deliverables and very well received.  Six months later (no coincidence but I'll come back to this) the learning objects are grandly unveiled and the result is massively disappointing, but how can this happen with such great design?

The answer to 'did I do the design' question was yes, I did.  I'm an educationalist at heart so that was important to me, but not as important as the learning piece.  What I mean is that you need to put the work in on design without doubt, but it's not actually the deliverable that your clients need (even though they may want it).  The answer to the 'how can this happen..' question is that it does and it happens all the time - the main reason is that people worship the design and lose focus on the deliverable and, perhaps most importantly, close off ideas too early.

The problem with design is often that we put enormous effort into design to make it complete and then match the development to the design just like in the old models of ADDIE and the like.  The issue I have with this cyclic approach is that the iterations take too long in the rapid world we develop in and by the time you realise what you had in mind and what is delivered are two different things it's already too late.  It's also kind of crazy in a way to think that you know exactly what you want at the start of a project.. often when developing projects you come up with a better way of doing things, what sort of design won't allow for that kind of flexibility?  Bad.  Good design is always able to respond to change - yes budgets and timelines mean at some point you have to settle on certain aspects, but if you work in a live 'evolve' mode the end product will be far more likely to meet and exceed expectations.

Evolve I've talked about before, in design it means working in a live state rather than a 'published' state.  Some people call this working in perpetual beta and it's akin to Working out Loud and even Learning out Loud that I've talked about before.  What it means in a practical sense is that rather than designing in a Powerpoint type presentation or Word docs (no, not anti Microsoft here honestly!) you work in an environment that is live.  By this I mean you work using a wiki style approach to design using web tools where changes can be made by all parties at any time and it's all recorded and live to see for all.  The simplest of these tools can be a Google Doc or Google Sheet or using some of the great collaborative note taking software like Evernote or OneNote (see MS is here!), but the tool I like best for this is a really simple collaborative post-it type tool called Trello.  I can make comments and move things etc and it lets everyone know as we go.  You can still set deadlines etc, but it means when things change or you have an opportunity to improve or a better way of doing things you do this rather than settle for a dated design.

Hopefully you've understood from this that I do value design but I think we need to remember two very key points:

1. The design needs to be live, collaborative and able to change
2. The design output is not the end product

but I also think there's a third point that I haven't mentioned

3. The design phase is not a phase at all - it's part of every phase

by this I mean that don't worry that your design isn't perfect before you start building.  You can design throughout the build as well and in fact this is likely to make your end product that much better by staying on top of changes and requirements and always being on the look out for better ways of doing things.  If we try and sign-off a perfect design we'll take three times as long and the perfect design never really exists.

Practically when working with clients I try to not get too heavily into the finer parts of design too early, I think it's an artificial situation to get in to and you'll end up with a stilted design and final product.  What I do try to do is get the overall concept and then start the build, from there we can work the design collaboratively as part of the build process.

Remember again that learning is more of a journey than a destination - design is there to support your journey.

And of course as always feel free to disagree with me if you want to - just do it out loud :)