Redesigning Design
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The design process is stuck in the antiquated view of the old print world: a world of the super conglomerate agency, tangible artifacts, deadlines, ego-driven elitism and tribal mentality. Design needs to be redesigned.
Currently design is spurred by deadlines. The deadline is the point when ideas, drafts, blueprints and prototypes are printed, manufactured and launched. Designers use the time before the deadline to conceive, produce and finesse designs. Once the deadline has passed the designer can breathe a sigh of relief and declare the design finished.
This model was born in the Industrial era when we needed large machines, production lines and production schedules to produce tangible artifacts. We are now in the information age, yet we still apply some of the same thinking and processes to create digital products. For example, we create a project to develop a new digital product or service, which is considered done at launch. When something new transpires, about the customers or the market, we undertake the whole process again from scratch and produce the next generation in exactly the same way. Yet we know that change is a certainty in life. Change is constant; a self-perpetuating cycle. Human needs change. Changes in technology then add to the mix of social, environmental, and political influences. This cycle of change is an indomitable force.
As “digital engineers,” we need to embrace change: it is the lifeblood of a digital existence. We need to stop fearing change, accept it and work it into everything we do.
The Current (and Historical) Design Process
When a client recognizes the need for design input, they create a design brief and invite design agencies to pitch for the work. The appointed agency might begin with some analysis activities that are summarized in a written report. Having completed the analysis, the real design work begins. The design team retreats into their creative space and creative magic happens. Some time later they emerge with a fully baked design. There might be a short period of feedback and refinement, but eventually the satisfied client signs off and the designers head to the pub to celebrate.
It seems like a fairly good process, and it certainly works for the designers. In fact, at this stage the client is probably fairly satisfied too, having been impressed by the creative environment of the agency, convinced by the creative team and wooed by the creative budget that included cocktails and dinner at the venue-du-jour in town.
The issues start to arise after the design honeymoon is over and the design team has left the project. The pain comes once the client gets down to development, and a couple of weeks in the development manager explains that the amazing designs that everyone is so excited about can’t be implemented.
The client could be forgiven for thinking “IT people are idiots. Why can’t IT just build it for crying out loud? How hard can it be? Just work harder, longer, faster! Throw more people at it if you have to! If you don’t have capability within your team get someone in who can do it!” Eventually, the project is delivered, much later than expected, with a massively expanded budget and with an execution that is only remotely related to the original shiny presentation boards delivered by the design agency, who exited long ago.
So what went wrong? From the business point of view, IT went wrong. The conventional wisdom was that IT was notoriously bad at delivering on brief, on time and on budget.
How IT Fixed What Was Broken
That might have been the case once, but IT is full of analytical brains who spend their time trying to make the impossible work. When something doesn’t work, they spend their time trying to figure out why it’s not working and if there’s a way around the problem or another way of arriving at a solution.
IT was fed up with being the scapegoat. They wanted to figure out what was broken in the delivery process, why it was broken and what they could do to fix it. Having looked at the process from start to finish, they recognized that there was a problem in the way that software was developed. However, root cause analysis pointed to the fact that the problems started much earlier in the process before any code was written. The problem lay in the way that analysis, requirements gathering, and design were done long before IT were involved. Invariably, the business dreams up a vision for their product or service and sets expectations with stakeholders and shareholders. Then the design team spends a heap of time and money on detailed design, without necessarily checking to see if the concept is feasible. Much later, when the IT guys get involved, they plough through the specification documents and are then forced to deliver the reality of the situation: that either the product cannot be built in the way it’s been designed or it will take much more time and money than originally expected.
One way IT tackled the problem was to spend a lot more time and effort up front doing technical design and more detailed estimation; however, this method had its own drawbacks. So a bunch of smart guys got together and came up with an alternative approach, known as Agile. The approach was articulated in the Agile manifesto, which suggests that in order to build software better (and build better software), there should be emphasis on “people over process, working software over documentation, collaboration over contract negotiation, and responding to change over sticking to a plan.” The simple philosophy of Agile and its derivatives, coupled with elements of Lean manufacturing, rocked the IT and project management world.
IT focused its efforts on improving the process for delivering software. IT continues to improve how software is developed. From service-oriented architecture, cloud computing, data visualization, and open-source, IT has proven that it’s not reticent and has embraced the notion that to collaborate is to succeed.
Design (Exists) in a Vacuum
By comparison, design as a functional discipline has had very few pivotal changes. While some techniques have changed as a result of the advent of digital technology, the processes remain the largely the same. Perhaps design has not faced the same challenges as IT, or perhaps it’s because,as designers, we are blind to the challenges because we’re at the pub celebrating, having left IT to pick up the pieces.
Design has become so wrapped up in its previous successes that it has become ego-driven, elitist and exclusive. Design is traditionally done in a vacuum of self-importance where no other factors are considered. At best, end customers are considered, but sometimes to the exclusion of everything else, resulting in biased designs. Once the design is done, the outputs are mounted on foam-backed presentation boards or described in biblical-sized tomes of a design specification. These are then thrown over the wall for someone else to deliver.
While design has been behaving in such a self-centred way, IT and the Business have been getting cozy. Now design, and to a certain extent the end customer, have been left out in the cold. The business are enamoured with Agile, this new inclusive way of working with IT, which delivers working software every few weeks. These Agile guys even write their software requirements as “user-stories,” which state who the user is and what their goals are, so the business trusts that IT has their customers in mind.
Life and Time Have Moved On
The “ubiquitous web” is having an unprecedented impact on modern life. Access devices are converging, high-speed wireless networks are almost omnipresent and the internet has become a virtual neural network. The digital nature of the web means that even time itself has a different meaning. In the offline world, we strive to meet deadlines driven by the industrial and mechanical production processes of tangible artifacts. On the internet there’s no such thing as deadline. Instead there is a notion of a “use-by” date, whereby something is hot or not depending on the groundswell of the virtual tribal trend at that moment in time. The web is ubiquitous and at the same time organic. It is dynamic, emergent, and continues to evolve inline with Darwinian theory. If a website is no longer fit for purpose, it mutates into some enhanced version of its predecessor, otherwise a new cell emerges to triumph.
So if the way we design no longer fits in the real world of business and Agile IT, and design no longer fits the organic framework of the internet, then what is the future for design? Surely this is the kind of design challenge that most designers thrive on. After all, designers are also by nature analytical problem solvers; we just use a different side of our brain to solve problems. There are certainly a great number of design minds that have spent time in the capacity of mental and visual thinking about this problem. There may not be a single irrefutable answer just yet, but in this article we propose a straw-man for consideration.
We There’s no need to reinvent the process wheel. The Agile luminaries have done a good enough job of that. As designers we just want to get (back) on the bandwagon and come to the party. We need to reinvent the way we do design and integrate it into the Agile process so that we bring design up to date and in line with the information age.
A Design Manifesto and Continuously Delivering Value
Design needs to be:
- inclusive rather than elitist
- emergent with direction rather than up-front
- integrated rather than handed-over the fence
- collaborative with customer, business and technology rather than biased towards one single factor
To start with we’ll take the Agile project framework and combine it with all the best bits from the most influential design disciplines such design thinking, service design, product design, graphic design, and user-experience design. We’ll make design explicit, yet integrated, so that everyone knows it’s a critical part of software delivery. Design cannot be left to chance and should not just emerge as a by-product of software development. In order to deliver a compelling, valuable and desirable customer experience, which hooks, converts and keeps customers coming back, we must design the experience a different way.
The aim of Agile is to get to code as quickly as possible. However, through the inclusion of design, we want to ensure the software produced adds value to the business and is desirable to the end customer. There’s no point in working software if it does not deliver any value. So throughout the product development lifecycle we need to constantly check every decision, every action and progress and ask “where’s the value?” This means that while we want to get to code quickly, projects should not start with software development. We need to take a little time to understand why we are doing the project, what value means in context and create a vision of what that value looks like. Then we decide how we are going to deliver and measure the value.
The Why? “Just Enough” Understanding
In order to understand the context of value there is a short period of “discovery.” This consists of parallel streams of activities conducted by functional experts looking at the technical context, the business context and the customer context. The aim is to get a shared understanding as quickly as possible. The team has daily checkpoints to share what they’ve learned. The point here is this is not months of detailed research. Instead we take a leaf out of the Lean manufacturing book and do “just enough” analysis to get started and make informed decisions about the direction of the project. The project landscape will change any number of times, before launch. So we should not create “waste” by building inventories of knowledge that we know will change.
The What? Creating a Vision of Success
Having grasped an understanding of the project landscape we now need to carve out a vision of what we will deliver. There is always a customer experience, but as a project team you can choose whether it will be a good experience or a bad one. To choose a good experience you need to add a bit of rigor, focusing the team on the “minimal desirable product.” The term “minimal viable product” (MVP) has been bandied around for a while, but viable does not equal success. Viable and feasible contribute to success without a doubt, but to be a success the product also needs to be desirable by the end customer; and desirable does not happen by accident.
To do this we use “design thinking” techniques to rapidly generate multiple uncensored conceptual possibilities. Ideas spark other ideas, and using creative thinking, you will generate some great ideas, often far from your original starting point. Once you have a plethora of ideas you can begin to cull the weaker candidates, dismissing concepts that don’t deliver business value, don’t provide a compelling experience or aren’t technically feasible.
With a short list of candidate concepts it’s now time to test the market. You need to get out from the office and on to the streets. Before investing any more time and money in product development you need to get some feedback from the target audience. You can use this kind of exercise to “fail fast.” It is much better to determine that your idea is not going to work at this early stage than spend 1-2 years and a lot of money on an idea that ends up bombing in the marketplace. These kinds of “guerrilla” research techniques yield quick results and have proven to be very effective in directing the success of product or service.
The How? Collaborative, Intensive and Time-boxed
After discovery and prior to development there is a period of “elaboration” where a cross-functional team comes together to get down to the specifics about how the vision will be delivered. Members of the cross-functional team might include stakeholders from the business, lead technical representatives, senior designers and customer representatives and a project manager. Again this is a fairly short and intensive period of collaborative workshops.
The aim during elaboration is to explore just enough detail to get to development. We don’t want to design every detail prior to development because things will change during development. Technology in some instances will limit what is possible, and in other instances it will enhance what we thought we could do.
The designs are directed by customer goals to ensure there is always value. By designing in this way we ensure there are no arbitrary features and functions that will bloat the project unnecessarily. We do this in collaboration with the other team members. This might sound like “design by committee,” which would have most designers running for the hills, but managed properly, this is not the case. As the lead designer your job is to drive out the key customer journeys and a more detailed design direction, while soliciting input about the technical feasibility and business viability as you go.
The design detail and the user-stories (requirements) emerge together throughout the process. Some stories might emerge first, and the designs are based on those stories. Equally, the design direction will influence some of the stories that are written.
By the end of the elaboration period there will be a comprehensive list of user-stories mapped to the designs and tied together by goals. These stories are then prioritized by the team and estimated for development.
Continuously Developing the Design Detail
Designers continue to build on design detail throughout development. While the product is being built, designers work closely with the business and developers on the detail as user-stories are played out. With a comprehensive design vision in place the design detail can emerge.
On an Agile project the build phase is divided up into very short chunks, usually 1-2 weeks, known as iterations or sprints. Designers aim to work 1 or 2 iterations ahead of the developers in order to think holistically about the stories in the context of the overall design and also to solicit regular and timely feedback about the designs from the end customers. The aim is to test with customers during every iteration, to ensure that the emergent designs are value-based, useful, usable and desirable.
Design Is Responsive
Testing with a sample set of customers during design development is essential; however, we accept that design is never done. When a digital product or service is launched, it’s the start of a new understanding of how customers interact and how they feel about the product. The live environment is the perfect place to measure and analyze how the digital customer experience is performing. With the right tools it is possible to quickly assess what’s working and what’s not. Then by using techniques such as A/B testing and multivariate testing, designers can experiment with alternative design variations and use the results to optimize the digital customer experience. With the right deployment process in place, changes can be made to your digital service multiple times a day if necessary. This is how technology is making design truly responsive to customers’ needs, and together with the Agile process, it is how we are seeking to redesign design.