Prototyping as an ethos
When car manufacturers design a new automobile, they develop requirements, conduct research, draw designs, make scale models, test scale models in wind tunnels, computer model their ideas, build full-scale prototypes, test them, and iterate the designs – all of this before putting them into production.
What they don’t do is go right from drawing them on a piece of paper or having some ideas to putting them into production.
So they don’t base their decisions on a paper prototype or a list of words. Why? Because a car is a 3 dimensional experience. It is an experience of the senses. It is an interactive experience. You really need to understand it before you put it into production. Mistakes would be costly.
Most people, if you asked them to draw a picture of a car would do so. And the exercise would result in many different shapes, sizes, features, etc. However, if pressed, most people don’t actually believe they could design a car for production.
So why, then, do so many people believe they can design a website?
When done properly, websites go through a process of understanding requirements (those of the business – and the users), which can mean conducting research and workshops with all constituents to understand needs, desires, etc. All of this informs design and function. We sketch, we wireframe, we prototype, we test, we revise, we design, we build, we test, etc. There is a process that we follow, not because we want to be difficult, but because we are often delivering something, that in todays world, can sit at the core of a business’ strategy.
We wouldn’t want to take our responsibility lightly, because to do so could be catastrophic for the companies for whom we work.
So if we take our responsibility seriously, why don’t our clients? Why do they so often try to cut corners, cut out research and prototyping, shudder at the idea of iteration (which will equal cost now but provide potential benefit later), and railroad us down an agile path that promises iteration, but so often delivers linear, scaled-back development with no opportunity to evolve already built functionality?
Prototyping and testing gives you a real opportunity to test, iterate and re-test. It allows teams to incorporate learnings (other than their own) so that the end results more closely resemble the type of result that users might actually find useful.
If I could I would present a counter argument to this process to try and give some sense of perspective, but through all of the prototyping and testing I’ve been a part of throughout my career, there have always been a set of beneficial learnings that have come out the other end, and a set of clients (marketers, tech teams, stakeholders) who sit back and think ‘we didn’t know that before’.
I’d love to see more time built into projects for prototyping and testing because I enjoy it when projects are given a chance to be successful and clients are given a chance to shine when their results bear fruit.
And isn’t it better when we share our work while it has a chance of being improved than after when it is too late?
Agile as the process
Over the last year or so I’ve come across quite a few people – technologists mostly – who keep asking the question – why can’t Agile be used as a methodology for both UX and development? Having spent some time considering it, I’ve put down a few thoughts below. Apologies in advance for the use of overused clichés.
So to begin, if you think about the differences between what we do as the differences between Architects and Construction teams working on buildings it might help.
Additions and renovations
Analogy: Think of this as modifying the interior of your home or building a small addition to an existing home.
In this instance you will likely need some kind of planning permission and therefore some designs drawn up for the planners to review. Once you have permission you will engage contractors to do the work. They will of course want to utilise the plans, but you can work with them side by side throughout the process. As the end customer you will have to live with the output of their work, and therefore any changes and modifications you make along the way will affect the outcome of YOUR project, affecting YOU as the user.
From a web or software development viewpoint, on small projects, where something already exists, and you understand its structure and use, adding something new or making modifications means working with known technology, design, users and a history of analytics. You may, at this point, even be working from a wish list provided by your users.
The Agile process can work very well here, where you are talking about iterative design and development and you have teams who understand the environment in which they are working. Many projects fall into this space, and I can understand why people might simply jump right into the Agile (development) process, running mini-UCD cycles either in, or slightly in advance of the development sprint.
Significant failure is low in this circumstance, and the ability to iterate or retract work should there be a problem minimises project risk. However you do run the risk of people not fully understanding, interpreting or developing things in the way you would have liked, and therefore may have issues with the quality or output of the work carried out.
Building a house
Analogy: Think of this as building a house from scratch. You start with a plot of land, planning permission and architectural blueprints.
On these projects, you are best served by putting process and structure in place. More to the point, before you engage a builder, you should understand – as much as is possible – what it is you want them to build. You likely engage an architect who you will work with throughout the process to get the best out of your budget and ideas.
The more you know about the build before it starts, the more potential you have for success – and the more possibility you have to efficiently build what you set out to build. We’ve all watched those shows on television where the owner went ‘off-piste’. What ensued was runaway costs, layouts that didn’t suit, missed opportunities and homes that, in the end, were livable but may well not have met the expectations or desires of the people who set out to build them. In essence, they began and ended with the Agile process, throwing User-centred design out the window.
From a web or software development viewpoint, on these medium sized projects, where nothing exists, you need to understand what problems you’re solving, who you’re doing the work for, why they want it, who else is doing it, and how what you’re doing will be measured to better understand success or failure.
In this instance you really need to understand the requirements of the business and the users. You need good prioritisation and clarity around the requirements. And because you are now building something new, with no pre-history, you really need an understanding that exists beyond that which Agile will give you. It is no longer enough to carve up what you perceive as the work, and then jump right into Sprints. You need to understand the shape of what you are building, what the major interactions are, and if there are technology constraints or technical architecture issues.
In short you need a set of blueprints to work from so that you don’t end up with something that no longer meets the needs of the business or the users, but satisfies a technical need to develop something. You need to do a larger portion of the product design up front, understand workflows and understand what a successful build will look like – and then engage development teams and work in an agile process.
Significant failure is high in this circumstance, and the reality is that most agile teams – even though they are supposed to be iterative – are often only given time and budget to develop new functionality, with one of the foundational aspects of agile – the ability to iterate – falling by the wayside.
Raising the skyscraper
Analogy: Think of this as building a large multi-story (say 40 floors) office building.
These projects are all about getting the planning right. From understanding the location and impact on the environment, to structural design, understanding how people flow and move about the building to how you integrate necessary function (elevators, stairs, electrical, heating and air conduits, power plants, plumbing) in a way that is people-friendly.
You simply wouldn’t jump right into construction of the building without understanding all of these things – it would be a disaster. In fact, understanding how these sorts of things are so important that companies like BAA – whom I worked with several years ago – go to the extent of setting up prototypes of bathrooms in warehouses and conduct user flow testing to understand how people use bathrooms and how to build them more efficiently for the people who use them. Even they don’t just say ‘Hey, we need a new bathroom’ hire a bunch of contractors and just start building.
You would engage with architects, planners, experts in construction, clients, and a myriad of other stakeholders, develop your plans – to a very detailed degree – which you would then use in a RFP to construction companies so that quotations would be as focused on what you are attempting to develop as is possible.
In the same way, with large web or software development projects you wouldn’t imagine kicking off with ‘just enough’ requirements to get going. There isn’t enough context at this stage to know if your starting point is appropriate, if what you are doing is even relevant, and how what you are doing interacts with the rest of what you are building.
Failure on this scale of project is catastrophic and costly.
So why do so many companies do just that?
Agile is too often being sold as the entire methodology, when in reality it is a development – note, development, not design – methodology. For that, we have a User-centred design methodology.
These things don’t work in opposition to one another. They should be complimentary. And yet, often you find people saying that UCD is too much like waterfall, and because they have bought into the idea that Agile solves all of their problems, they see Waterfall as antiquated and Agile as the new kid on the block, shiny, new, better.
The truth is, that in the latter two examples above the potential for catastrophic failure is quite high – and can be accomplished quite quickly. When a team hasn’t taken the time to understand what it is building how can they know that what they are building answers the needs of the business – or the users – for whom they are developing? And when – as is so often the case – the agile process itself is compromised and iteration isn’t allowed to occur how can you expect success?
I think of UCD and Agile as working together on a sliding scale. To the left we have the known, where UCD and Agile are in the trenches together solving problems as they go and adding incremental functionality. On the right side of the scale we have UCD and Agile working in a different configuration where Requirements and UCD provide more shape and detail before the development process begins and Agile delivers the output once everyone understands the shape and function of the application. The fact that this doesn’t often occur doesn’t mean it isn’t the right process to follow.
More open conversations need to be held between the Agile and UCD communities to ensure there is a process that works for everyone. And more recognition needs to be given that there is significant differentiation between small incremental projects and large-scale web or software development projects.
I hope the two communities continue to work together to understand the best implementation of these two methodologies.
Walking the line between Skunkworks and Business as Usual
Several times recently I’ve heard the word ‘skunkworks‘ mentioned. Most recently it was in a Guardian interview with Mark O’neill, the ‘leader of the government’s IT ‘skunkworks’ team – as well as CIO of two prominent UK Government departments.
I have to admit to being fascinated by the idea of a skunkworks capability in Government. Ideally, a skunkworks team is untethered from organisational rules and structures, and allowed the freedom and flexibility to focus on solving problems and pursuing real innovation – which often means failing a good number of times before (potentially) achieving a measure of success.
I’ve made the argument in the past that innovation could be as simple as taking the practice of one sector and applying it to another, bringing about change and introducing a new way of achieving something. This often requires people who work across sectors and have the ability to spot latent needs in one sector that can be met by standard or best practice from another. This is briefly alluded to in the afore mentioned article when Mr. O’neill speaks about what Government could learn from its engagement with London 2012.
Skunkworks have historically been used to come up with solutions where normal business practice has failed or where significant leaps in technology are required, the success and output of which may later be put into production using Business as Usual (BAU) methods of production.
All of which leads me to ponder what kind of leap is Government trying to make?
It strikes me, from my brief sojourn into Government a couple of years back, having worked for commercial organisations across multiple sectors for more than twenty years, that Government departments could do with more exposure to how businesses plan and manage their IT, develop their digital services, and have an imperative to find a balance between the needs of the organisation and the desires and goals of their customers. Indeed, even the Government itself has gone down this route by engaging people like Sir Alan Sugar and Martha Lane Fox.
On the other hand, if the idea of the skunkworks team is to be a rapid prototype development unit – that doesn’t get too bogged down in coding, and spends more time achieving some of the balance I’ve referred to – then they could possibly introduce more rigour into the process of developing their IT and digital services, introduce the people who design these services in departments to their users, and look to build ‘just enough’ to accomplish a specific set of tasks, then possibly there is some educational value.
However, with a large proliferation of open source technologies on the market, and project management and user-centred design methodologies that many in Government fail to understand or embrace, I worry that what many will think of as innovation, is already so imbedded as BAU elsewhere that BAU will get mistaken for innovation (I recognise a degree of my own hypocrisy here).
One other thing the article mentioned was the use of Agile development. I’ve had the distinct ‘pleasure’ of working with agile in projects that range from quite small (new builds and enhancements) up through major software development programmes. The one thing I’ve learned is that it’s rarely applied the same way twice, and that people rarely follow its basic values (see link above for source):
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Skunkworks teams, by their very nature, should be agile. However, how the work that comes out of a skunkworks effort is then rolled into the organisation can be another matter altogether. As you can imagine, a skunkworks team can roll out some small live applications, websites and enhancements, but when it comes to large-scale services development, the best it can hope to achieve is to do some proof of concept work, prototype, and inform the larger project that will follow. And that is where the many varied applications of the Agile process will show varied results.
Still, though I’m quite baffled by what a Government skunkworks team hopes to achieve – and from the looks of it in quite a public way (keeping in mind that most skunkworks projects are secret with some percentage of the ones that succeed becoming a product we might one day see, and the rest buried deep in a basement vault never to be heard from again) I fully intend to watch this space and see what comes out of it.
I also wonder what roles the Parliament skunkworks team, Directgov | innovate, dotgovlabs, and the shadowy Alphagov team might play in the short to medium term in working with Mr. O’neill’s skunkworks team in the digital space.
I think it promises to be an interesting next twelve months for UK Government digital.
Hack Days: What expectations do they set?
I love Hack Days.
I love them because of the anticipation, the spontaneity, the community and the creativity. They generate energy – if for a short time – around the issues they are organised to expose, and for a brief moment overcome the inertia that most people come to dread within large organisations – like Government.
I say ‘expose’ because in my experience of Hack Days often people come to ‘show off’ their skills, ‘show’ the organisations or sectors whom they are targeting ‘how to do things better’, and ‘show’ each other what they are capable of.
None of which is bad. But all of which worries me slightly.
While those coding and participating in the coding teams, at some level, understand that not all digital development projects are the same, not everyone who attends a Hack Day necessarily ‘gets’ it.
I think Hack Day participants break down into several categories. These include (but are not limited to):
- The organiser. These are the people who run the events. They are often bright, dedicated, and clever. They also often have an agenda. This agenda can include trying to show up the organisations or sectors at whom the Hack Days are targeted. This is fine, but is not always clear to the people on the street.
- The hacker. These people vary in age, are often male, are sometimes a bit disgruntled with the idea of ‘large agencies’, and almost always feel they can develop better than the organisations or sectors they are targeting for their Hack Day.
- The business constituent. In most cases, representatives from the organisations are in evidence to view the proceedings. They vary from the technical to Marketing and PR types who want to be present to understand the outcome of the event. Not all of them want to be here – they were sent to observe.
- The public. Individuals from the public range from the inexperienced, to the professional – they are all linked by some desire to come and view and see what this thing is all about. They do not always fully understand what is happening.
- The press. Many Hack Days get little to no coverage. Some Hack Days, particularly ones focussed on the Government, get more press coverage – the angle is usually ‘hackers outshine Government…’
My worry really centres on the business constituent and the public. These are often the ones who come away incredibly inspired and often believe that if hackers can do it in a period of 1-5 days (depending on the length of the hack sessions), then why can’t their organisations do it?
I say this because in my experience, having run a successful digital product design agency, these prototypes – and that is often what the applications developed are – can give the false impression of fully developed, functioning and robust services.
They create a sort of illusion that feeds the myth ‘if it’s digital, it must be fast to develop’.
I worry that many inexperienced people who attend Hack Days may:
- Expect that ALL digital services can be built quickly, and cheaply
- Be ill equipped to differentiate between simple standalone development/enhancements and large-scale systems integration
- Perpetuate within their organisations a false sense of expectation
- Drive forward projects without understanding the needs of the organisation and the users
- Simply fail out of ignorance
These may seem like harsh things to say. And they are not exclusive to Hack Days. In my twenty-two years of participating in and running technical and digital projects I have seen these issues occur all too frequently to believe it is a limited phenomenon.
However, with respect to Hack Days, I hope that as these types of events progress and mature that they will find some balance between showing spontaneity and creativity, and informing those attending that there can be a vast difference between what they see and the digital service or product idea manifested in the real world.
It feels a bit too much like the pendulum has swung from projects taking many months to several years, to whacking something together and launching it.
As with most things, there is a happy medium that will ensure digital services and products are developed in a way that meet the needs of the organisation and users, and can also take advantage of technologies and methodologies that ensure we are not constantly building more or taking longer than we need.
In the interim, I do believe that Hack Days are an important and vital step in the transition we need to make from ALL technical and digital services needing to be large-scale infrastructure projects, to developing a more discerning view of building ‘just enough!’
I welcome your thoughts.
The 80:20 rule of Agile and UCD
I want to tackle the intersection of User-Centred Design (UCD) and Agile. I’ll start by saying I am fundamentally not an Agile detractor. I respect and appreciate the need for process to help shape and deliver complex projects.
When it comes to UCD I am a strong believer in designing the ‘right’ thing for the ‘right’ user – of course, I also strongly believe the most successful UCD projects find a good balance between the needs of the user and the business.
In my experience, whether intended or not, Agile has typically promoted the technology team to the front of the pack, with the consequence of producing the product through the eyes of a team focused on what it can do in the time (Sprint) and with the team (capabilities) to hand.
The needs of the user and the business as a whole are minimised and the view of the overall product becomes lost. In fact, instead of a product comprised of functionality and workflow, it becomes functionality and workflow that define a product – and one that you may never have intended to build.
With a rule of thumb of 20% of the product design done in advance and 80% done within the Sprint, highly complex projects run the risk of delivering functionality that meets the needs of the stories but not the final needs of the product, business or users.
I believe that in the rush to kill Waterfall and move to Agile – ostensibly so businesses could deliver incremental functionality to their users – we threw out the baby with the bath water. At a time when the competing methodology of UCD was gaining traction and helping give shape to digital products and software, and a stronger voice to the business and users, the zealous deployment of Agile derailed the process and the product.
The end result is a process that is driven to deliver – but what?
I think that we need to regain balance in the system. The pendulum has swung from using a methodology (Waterfall) that people felt took too long to get to a deliverable, to one (Agile) that gets there quickly and incrementally, but may never give us the product we wanted.
I think we need to consider 3 things:
1. Is the project itself about an incremental addition to an existing site or application, or is it a small to mid-sized piece of development?
Knowing the answer to this will help determine whether the 80:20 rule is relevant, as the more complexity is involved, the more time must be allocated to up front requirements and product design – perhaps making the split as much as 50:50.
This helps determine whether you dedicate the bulk of your product design resource to the Sprints, or you require an advance team that provides an overall shape to the product allowing those working in the Sprint to provide the detail.
2. Where are the users and stakeholders in the process?
There needs to be a clear plan that incorporates stakeholder reviews and user testing. There should be real user testing on prototypes or development sites prior to any releases, with enough time planned into the process to make real changes – and test again if necessary.
All too often this is lopped off, along with any thoughts of making the applications accessible due to lack of time to develop. Stories to fix designs languish in the backlog and never see the light of day and the end product delivers something – but is not the piece of brilliance it could have been.
In fact it might not even be fit for purpose.
3. Are you designing with the thought that there will be ample opportunity in future Sprints to make changes?
We’ve all gotten stung by this one. Consider the very real possibility that what you are developing now may well be the final product. As a UX person, fight your corner to get the most out of the process to ensure that users and the business can live with what will be deployed.
Don’t allow anyone to compromise this and don’t believe that the backlog will one day magically equal zero and all stories will become reality.
I think that we have to be pragmatic about what can be achieved in the Agile environment and need to encourage the business to understand the risks involved in letting it become a fully technology-led approach.
It is meant to be a methodology for delivery. Ensure product design is represented in early discussions about the project and in the plan and that we don’t mystify it to the point of becoming marginalised in the process.
I’d love to hear your experiences.
Project Management
If User Experience from its infancy to now has figured into the last 17 years of my career, project management at all levels has figured into my entire career.
Starting out as an Engineer 24 years ago, I provided the project management on all of my projects. When I moved into digital in 1994 I project managed much of the work that I performed, and the teams I was involved with.
I have done everything from act as a sole project manager to work at Management team and Director level overseeing project management and operations. Nearly 10 years ago I took on the role of Head of Project Management at Zentropy Partners (now MRM Meteorite), and over the last 10 years have provided a mix of Project Management and User Experience services for my clients.
I understand the time-scope-budget triangle, have worked in Waterfall and Agile environments, and get the importance of User-Centred Design. In nearly all of my roles I have worked at the nexus of technology, internal stakeholders and customers.
I’m good at working with and understanding the needs of teams. I’m personally very organised and am really passionate about employing my diverse, but relevant, experience to projects and teams.
Think of me as an organised but creative thinking project management professional who can work at Director level.
BBC & BBC Worldwide
Over the last five years I’ve had the pleasure of working with the BBC on a number of occasions. These included when I was Managing Director of phunQube and we worked on Top Gear and Lonely Planet. In the Top Gear project my team and I worked on everything from requirements capture and prioritisation, to UX Strategy and Tactical UX.
I later contracted for the BBC through Digital Optimist on the Digital Media Initiative (DMI) program where I was Head of User Experience. I built a team from the ground up and ran teams in Agile and Waterfall environments on the development of a digital television production platform, the BBC digital archive and rights management system.
The project continues to roll out in stages and has a long term vision to replace several legacy systems and become the digital work platform for the BBC, supporting its move to Salford and other regional locations.
Lonely Planet
In 2008, while Managing Director of phunQube, my team and I worked with BBC Worldwide, Lonely Planet and Poke on the re-design of the Lonely Planet website – after BBC Worldwide’s acquisition of Lonely Planet.
Our work initially entailed myself and one of my Senior UX team spending nearly a month on-site in Melbourne, Australia working with the BBC Worldwide and Lonely Planet teams to define the scope and requirements of the project. The entire project, which took several months and involved the entire phunQube team, involved requirements capture and prioritisation, customer engagement strategy, strategic and tactical User Experience, prototyping and user research.
Lonely Planet went on to win the Best Travel site in the 2009 Webby People’s Voice Awards.
Built in 2 weeks – the Pendulum swings
Q: How long should it take to develop a new digital product?
A: As long as it takes to get it right – within the limits of time, scope and budget (oh, and don’t forget the needs of the user… and the organisation)
I am a long-time believer in the User-Centred Design process. For me (and to most people in the business) this means (to a greater or lessor degree):
- Gathering and understanding both user and business requirements
- Developing personas, site maps, wireframes, content strategies and taxonomies
- Creating and refining rapid prototypes for iterative testing with real people
- Developing functional and technical specifications
- Creative design and user feedback on design
- Development and UAT
- Launch – with the proviso there will be post-launch testing to ensure how you thought people would use your tools or transactions is in fact how they are using them in a live environment.
Of course it’s not just me who feels this way. Many commercial organisations, for whom web represents a significant means of generating revenue or reputation, follow these practices.
They know that there is value to be gained through increased revenue, decreased costs and customer satisfaction and retention when a digital product works well.
When it comes to developing digital products in government, there is a growing perception in some quarters that government isn’t capable of developing them in a cost effective, easily modifiable, user-centred way.
To counterbalance this issue, the development community holds hack days (i.e. Rewired State: National Hack the Government Day held at the Guardian) where they get together developers and data and spend a day hacking together solutions to address user needs.
Now, let me first say that I am a firm believer in open crowd-sourcing of ideas and solutions, allowing for innovation to occur by supplying people with data, inspiration and space, and looking for truly inspired ideas to float to the surface.
Where my optimism changes to concern is when the proverbial pendulum swings the other way.
To their advantage, the external developers have decreased development time (in most cases with simple services that do 1 or 2 simple things) and cost. Do they have durable, usable, sustainable services? Quite probably not. They have somewhat working prototypes. But this is not to say they couldn’t be developed into something sustainable.
It’s not the speed or cost that concern me.
It’s the quality.
In many cases, both the government and developer community approaches fail to utilise a proper UCD process. Neither will readily admit this.
Rushing the process and slashing the budget won’t provide a better service…
…just a more easily disposable one.
I would like to see more digital product development in government take into account the sometimes quite disparate needs of the organisation and the users – and the potential size of the audience.
This will allow for the scaling of robustness and a focus on quality – after all, if a site has 15 million users but only 2% of that audience are potential users of a specific digital product then the scale of product development should take this into account and a level of quality should be ascertained at the outset.
Ideally, I would like to see more collaboration and less mud-slinging between government and external developers. It creates division, not collaboration.
I think there are great people on both sides who really do want to develop with the best possible interests of users in mind. And together, I think that the outputs of such collaboration will ultimately lead to better digital products for everyone.
Recommended reading: The Inmates are Running the Asylum by Alan Cooper.
