Email iconarrow-down-circleGroup 8Path 3arrow-rightGroup 4Combined Shapearrow-rightGroup 4Combined ShapeUntitled 2Untitled 2Path 3ozFill 166crosscupcake-icondribbble iconGroupPage 1GitHamburgerPage 1Page 1LinkedInOval 1Page 1Email iconphone iconPodcast ctaPodcast ctaPodcastpushpinblog icon copy 2 + Bitmap Copy 2Fill 1medal copy 3Group 7twitter icontwitter iconPage 1

Quick links

Introduction

I’m going to preface this article because it’s the first of a two-part series and whilst it focuses on upfront design, part 2 will focus on the equally wasteful exercise of upfront development. If you don’t read much more than the opening paragraph I want you to understand and take with you the following statement:

Upfront activities involving a single discipline within a multi-disciplined project is a waste of resources and shows a lack of appreciation for the range of skills required to deliver exceptional work

I’ve emphasised part of the statement above because it defines the type of work we do and thus influences the nature of what we are and how we do it.

What we are: A multi-disciplined team comprising specialists and generalists, highly experienced at working together in order to make the most of our shared, accumulated knowledge and expertise.

The point I’m making is that doing swathes of upfront anything (design in the case of this article) is crazy because design is a single discipline within a project which will only be successful when making the most of all the disciplines required. And it undermines the importance of all the other disciplines such as consultancy, project management, business analyses, frontend development, backend development and system architecture to name but a few. The team members with the aforementioned skills have a combined expertise and experience far outweighing any single discipline within the team and therefore, it’s simply not smart to expect valid, useful and innovative design work to be done when the designers and creative lead go about their work in a vacuum. Ultimately doing so risks huge waste.

And when I say waste I mean doing huge amounts of mock-ups (usually of a homepage and/or other ‘key’ templates’) where design, UI and UX decisions are being made without a user story in sight and without any justification for doing so other than it’s simply ‘the way we always work’.

Some good reasons why it’s best to avoid doing upfront design

  • Designers/creatives shouldn’t make decisions on their own when the decision has an impact on other disciplines within the project. Without a common understanding between all stakeholders (and a developer IS a stakeholder) the designer doesn’t have enough information to be able to produce valid designs
  • Given the chance, designers love working within a team of multi-skilled individuals because it enables them to get a much deeper understanding of the whole project, thus taking their work to another level
  • Designers will care more about their work, take ownership of the project and find it more rewarding if they’re working closely with everyone in the sprint team to regularly deploy the user stories they have designed (as opposed to designing, handing it over to a developer and walking away)
  • Designers are much more capable of creating innovative and exciting designs which work when having the opportunity to discuss what they’re designing with everyone else involved in the delivery of the story they’re all working on. Ideas, theories and practices cross-pollinate throughout the whole team making use of a wealth of experience to help better solve problems and make the most of their creativity. Note: this is about opening horizons for designers, helping them to understand what they can achieve and not putting a lid on their creativity by telling them what they can’t achieve
  • Developers have a greater understanding of what it takes to design and build intuitive user experiences that look great. And it’s important that everyone has an appreciation and respect for the expertise of the other team members
  • It cuts out wasted effort designing complex UI and UX based on business requirements that are not validated at the time the upfront design is being done

So why do people still insist on doing upfront design?

The simple answer is because that’s what they’ve always done and it’s baked into their process. It also stems from the origins of digital, pre-dot.com era, where most things in the commercial world were an offshoot/brainchild of a marketing, advertising or publishing company with roots firmly in design and ‘creative’.

During the heady days of 1999-2000 I worked for several start-ups and they were all big on creative, visuals and design but weak on usability and technology. As a consequence, no one at management level was capable of keeping a lid on budget, most of which was blown in Photoshop or at creative ‘workshops’. The expertise to do things differently didn’t exist and people focussed on what they were comfortable with (creative) and not what they were weak on (everything else). They used creative as their comfort blanket. I saw a lot of companies fail as a consequence and many other advertising, marketing and publishing companies pull out of digital altogether having had their fingers badly burnt.

This problem continues to manifest itself two-fold today: firstly in many so-called ‘digital’ agencies where, if you scrape beneath the surface you’ll find they’ve spawned from the traditional creative industries noted above. And secondly from the companies hiring said agencies, their perception being that design is required first and foremost, it’s the be all and end all and the only stage where key stakeholders need be involved to sign things off. Too much emphasis in these cases is placed on upfront visuals to impress senior management in both the agency and client companies as opposed to rationally thinking of projects as software first with design as an integral part.

How do we do it?

I’ll start this section with a couple of essential points for making this approach work. Firstly, you need to write user stories. I know it sounds obvious but this article only really applies if you’re already using Agile to define stories and run sprints. If you’re not, then I can’t speculate how you’re going to achieve this and you probably need to invest some time re-thinking your internal workflow. Secondly, it’s important for YOU to be able to differentiate your design services because this approach is not necessarily applicable to everything. See my final comment for how we determine if design should be treated this way.

Maximise design within user stories

As we know, user stories are the lifeblood of an Agile project. Everything we do is designed to aid the continual and efficient delivery of quality assured user stories. They’re the food that we all consume, enabling us to reduce waste by postponing decisions until necessary and to deploy quickly and often. It therefore makes complete sense that our designer should do as much of their work against a user story too. Therefore, at the start of every week, in our user story workshop, we identify what user stories are going to be done during the sprint and what resource/s are required to complete them. Once we’ve done that, those assigned to the stories move onto the planning phase and discuss between them what it will take to complete the story and how we might go about designing and building the ‘solution’ for that user story.

My next post ‘Designing for user stories‘ describes in more practical terms how we achieved this with one of our biggest clients.

Design one sprint ahead if a lack of design is going to be a blocking factor during a sprint

If we know the design effort is large and not having designs is going to become a blocking factor during a sprint it’s sensible to do the design one sprint ahead. This may sound like upfront design but it isn’t because the design is still done against a user story that is pulled onto the sprint board in the sprint workshop at the start of the week and discussed by EVERYONE identified as being involved on the user story. It’s just that only the design portion on the user story will be done during that sprint but importantly, the designer will work closely with the other team members and their work will be subject to the same QA rigour during that sprint. The rest of the delivery of the user story will then take part during a subsequent sprint.

To understand the bigger picture think ‘Epic’

An Epic for us is a collection of user stories that fullfil a greater goal than a single user story. For instance, for a site that sells a range of cakes, assorted boxes of cupcakes being one type of product, you could write a user story such as ‘As Jennifer (PA), I want to be able to purchase a box of pre-made assorted cupcakes, in order to quickly purchase cupcakes for an office party’. But this is no user story because it’s MASSIVE. It’s a user goal needing to be broken down into several other user stories. The Epic is therefore the umbrella for these stories and serves as the context for everyone including the designer. We’ll work through the user stories in an Epic which when complete will enable a customer to complete a goal such as in my example buying an assorted box of cupcakes.

Educate your clients

Think of it as follows, clients come to you because they want your services, they’ve seen something you’ve done or someone else has told them how good you are. Your reputation precedes you and therefore you’re in the driving seat. They want you to do similarly good work to what they’ve seen or heard you do and therefore are asking you to run their job in a similar way using the expertise and knowledge you’ve learnt on all previous projects. Have the courage of your convictions and explain to them that you’ve got these fantastic results because of the way you work and you’ll run their project in exactly the same way. Re-iterate to them the benefits and question why they would want to change a process that has drawn them to you in the first place.

But what about the client who insists on seeing ‘stunning’ visuals before allowing you to move on?

Simply put, this means you don’t understand the benefits of maximising design within epics and user stories, you haven’t seen the benefit of doing so and/or you don’t currently have a framework for making it happen. And thus, currently, you’re unable to put together a compelling argument for why it might be appropriate, save time, minimise waste and ultimately get fantastic results.

So you are the biggest barrier to your clients’ misgivings because when it comes down to it, if you have the confidence in your own ability to design within stories and to integrate the design team within the sprint team your work will be the convincing argument. It isn’t easy I know because some clients can be driven by ulterior motives to satisfy senior management and some larger organisations are used to dealing with design first, present second, build third in a linear fashion because that’s what they’ve grown used to. But there are so many persuasive arguments you just need to be clear what they are and then use them to convince your clients.

Oh, and just because I’m talking about designing within user stories and not doing upfront design it doesn’t mean we can’t deliver a fabulous design early on in the lifecycle of the project development. If you like, you can pull user stories into an early sprint knowing that those user stories will require the bulk of design work. If your client demands a homepage design, well that can be treated as a high priority business requirement and handled in a sprint workshop at the start of the week. We’ve done this on sprint 1 before: at the end of the week we’ve delivered a working CMS, homepage, navigation and search facility all being required to satisfy several high priority user stories and including the visual design of the homepage. Now what’s better at the end of the first week, delivering a photoshop file of how you think a homepage might look or delivering a working homepage of how it looks and how it works?

Come on, not all design work can be done as part of a user story?

That’s true. Design is multi-disciplined in it’s own right consisting of many different specialists from illustration, animation and branding through to user interface and information architecture (I’m going to try to avoid the term ‘User Experience Designer’ as I think it’s a misnomer of a job title which is a conversation for a different time). We don’t classify ALL design to be user story driven and therefore sometimes it can take part as a set of separate activities. However, the rule of thumb is as follows:

Design outside of a user story is only acceptable IF the design work in question has no relationship to any other ‘development’ activities

This can be the case (but isn’t always) with branding, market research, mood boards, logo design, 1DayBanner printed or online media, creating personas to name a few. For these, there are sometimes (but not always) separate processes and creative workshops.

Further reading

http://www.amazon.co.uk/Agile-Experience-Design-Designers-Continuous/dp/0321804813

http://www.hackerchick.com/2010/02/are-we-agile-yet.html

Share: