UX Design, Wireframes, UCD, Agile


What is a consultant to do ? Here we have this wonderful new client with pockets full of lovely cash and then the dreaded query comes out – “I expect you will running this in an agile manner?”

Sheesh! The immediate response you would like to make is – “Yes of course, just sign over the magical pot of gold that never empties here, and we can start immediately. The project should be complete on the 27th of mumble mumble”

Agile software development is a group of software development methods in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change.

Ok, so to any agency with a fixed time or money budget, a.k.a. all agencies doing any digital work, this spells disaster in the making. Not because it can’t be done from the team perspective, I don’t know a single developer who wouldn’t love to jump on a truly agile project. No, it’s the clients we fear. Agreeing, disagreeing, sending things back, changing their minds, Lions and tiger and bears, Oh my.

As a purist concept, Agile cannot fit within the realms of a fixed budget with any guarantee of delivery. Equally, it cannot fit into constrained time budgets with any guarantee of delivery. So why, oh why are we still working under the illusion that our process is agile, just because the client attended a half a day seminar on the subject.

What we do need is better terminology, to describe the best way forward given time and money constraints, to deliver a story generated project. And UX should be the champion of this process.


I am going to describe a process which I have used for years and which simply works. It is not a static workflow, it changes to meet the needs of the project and this is the crucial aspect, most methodologies are all wonderful on paper, but they need to adapt to the project.

My preferred workflow does require several items from the client and these are time boxed decisions which are either set in stone or will incur a penalty. It needs responsible stakeholders who are not going to be overridden by a director who really holds the purse strings. It requires timely access to run requirements interviews and access to assets and data. And it requires some flexibility which is hopefully born through trust and honest communication. With these items in place we can hopefully deliver a happy solution.

Most other problems (resourcing, resourcing, resourcing) can be handled, but what we need throughout a project is a collaborative partner in the form of the client.

My process starts with a generic RfI and RfP. This should be written by knowledgeable technical, UX, marketing and strategy people. It should outline three concepts with an MVP (minimal viable product, a.k.a ick), a middle of the road solution with some whistles and an occasional bell, and a HUGE all singing and dancing solution which costs about the same as a small diamond mine. We want them to go for the middle option, maybe with an occasional bell from the top option but never, ever, the MVP – this spells disaster, it means the client is tight on the purse strings and we will not end up with joy and happiness.

Any RfI or RfP estimates should be real, we shouldn’t be knocking off 30% in order to catch the client, real money for real work. Or, if we are going to “pull down our trousers, from a budgetary perspective” then we still need to ensure that internal budgets reflect reality and will not incur the wrath of the titans when we inevitably sway over and under the thin red line. Just because you want to catch the clients does not mean numbers change. They are static. If I went to a pizza shop and asked for a 40% discount based on the promise of more pizza business IF I happen to like the first really cheap one AND I am going to be even ever planning on eating pizza in the near future, I am sure much hilarity would ensue from the pizza shop management. And let’s face it, with the amount of agencies out there all vying for my pizza order, it would be criminal of them not to at least explore the other shops. Secondly, cheap work sets expectations for a cheap future.

After winning, the first step is usually a requirements workshop. This is a 2-5 day affair with all relevant stakeholders and knowledge bearers. We need to fully understand the business in order to present a solution. The workshop is driven by a UX architect, i.e. someone who will be able to bring pure UX, technical understanding and business analysis to the the party. We need to have the senior design there in order for them to fully get what the client needs and wants. We may need other specific technical bods if the UX allocated consultant is not capable of translating wishes into effort and time/cost. The UX architect must understand that this is not his/her pet project, instead it is a collaborative effort and whilst it is OK to have a broad outline in the agenda for areas to be covered, they should be spending most of their time listening and not dictating.

Keep the workshop grounded, it is important to not lose all the effort spent on the RfP to be lost. If the client suddenly mentions having a plugin on the site to read minds, gently steer them back to the original budget or as a minimum suggest a new number for them to consider when aspects are introduced that exceed the initial scope. Scope creep is a. good, because it implies an excitement and b. bad because it can very easily become unmanageable and unless controlled create disappointment or disillusion.

What areas are covered:

  • General overview just to set the scene for the agency
  • Current situation – good, bad, ugly
  • business analysis overview
  • competitor analysis – what are they doing well, badly and areas we can improve on
  • Persona identification – who is going to be using this site (backed by analytics)
  • Persona focus, who do we need ?
  • Persona ideal journeys/stories – high level – including the business analysis of said stories
  • Journeys/stories summarised and detailed step by step [logic diagram]
  • Entity identification
  • Flow diagrams of the journeys
  • Wireframes annotated

At the end of each day it is important for the UX architect to collate the information and be prepared to lead the next section, again with always the thought that they need to gather rather than dictate the requirements. It’s collaborative!

The output of the workshop is a series of stories and hopefully key entities and some wireframes. At this point there is a break of 1-2 days where the internal reaction to the workshop occurs. The home team will be present, so UX, along with the technical lead and maybe extra developers, test/QA, design lead, infrastructure and PM. The workshop output now gets analysed by the team. Each story is broken down into actual digital architecture and processes and budgeted. Areas within epics and stories that can be broken down further into areas of nice to haves are include as separates. ALL this information is collated onto cards with a budget of 1,2 and 4 to indicate complexity.

The result WILL be over budget significantly and the client will need to have this demonstrated to them. For this I really like the pocket money game. Get a load of coins which represents the agreed budget. Next lay out on a large table all of the story cards and allow the client to “spend” his budget. This really shows off the internal prioritisation of items and also makes them really do the MoSCoW analysis themselves. Quite often we will make undertakings that, depending on how each sprint goes, we may have the option to include some of the lower scored elements, but if they want to exceed the budget, they can and it will cost and may involve extra sprints (this is the agile perspective). What we do need here is agreement from the technical team as to what is feasible within each sprint including management and test overheads.

After the game we have prioritised stories – each with a technical summary and detailed non-functional requirements (test criteria). We can now look at resources and start planning the project into dates and sprints. With UX research (if you are lucky), prototypes (design + tech), functional planning and documentation, main design and technical sprints in a staggered array, test/QA, infrastructure and launch. There are more steps in each area, but you should get the gist.


For those argumentative types out there, they might be asking why this is different from any standard workflow. The main differences are that the design is UX driven i.e. for the people, not the business, the development team gets involved early to assist with realistic expectations of time versus requirements, the design team is coming from a much fuller empathy driven perspective. The client gains a full understanding early on about effort and consequences as well as providing them the option to go back and extend the budget.

Of course there are going to be disasters, no digital project I have ever seen does not have at least one. But if you have a project planned like this, you stand a pretty good chance of success as well as having and keeping a client.