Product shearing layers and the "double-diamond" approach to design | April 26, 2015
The organising principles of agile are based around the needs of developers. So processes and systems are broken down into units of functionality and fed to development teams along a pipeline of delivery.
We all know that estimating big tech projects is a crap shoot, so the focus with agile is on just in time decision making, problem solving and optimising through-put. With so many unknowns this is a much more rational and realistic approach than trying to plan and estimate everything up front.
Unfortunately, while this organising principle performs well for developers, it can be problematic for designers who need to tackle things as part of a coherent system, rather than a series of functional chunks.
Agile allows for iteration, so one way of tackling this problem is to give in to the inherent uncertainty and allow the design to emerge over time. So you slowly end up aquiering design debt, with the hope that you’ll have time at the end of the project to bring all the disparate pieces together. Sometimes this happens, but often this gets relegated in favor of more functionality.
I believe this is one of the reasons why so many established tech companies struggle to produce a holistic user experience and end up creating a disjointed UI instead. Lots of small pieces loosely joined rather than a coherent and considered system.
Lean ux has attempted to add a layer of design thinking to the process. However the minimal shippable unit is still based around features rather than systems and stories rather than journeys or experiences.
With this method experiments are run in the wild on real users rather than on paper. This has the benefit of giving you real rather than aproximated feedback. However it can also lead to significant amounts of technical debt and a poorly considerd product in the hands of your users for longer than is absolutely necessary. This probably doesn’t matter in a new start-up with just a few users, but can be much more damaging for an establish company with millions of customers expecting you to deliver of your brand promis. How often have we seen the MVP end up being the final product?
By comparison, the traditional UX approach sees problems iterated on with paper and prototypes rather than live users and working code, allowing you to iterate in a faster and more cost effective way. The trick is for these sketches to remain as recommendations rather than specifications, which is often not the case.
Of course these two approaches aren’t mutually exclusive, but I’d like to see Lean companies do more of their learning with prototypes and less at the expense of real users. Not everything has to be deduced from first principles, and there is a huge canon of design knowledge to draw upon here.
The tension between design and development reminds me of the famous shearing layer diagram which Stuart Brand used to explain the different speeds at which buildings evolve - the interior moving faster than the shell.
While developers find it easier to break off pieces of functionality, encapsulate them and then tie everything together as they go, designers require a higher vantage point in order to map out the entire system to do their jobs well. The business often appreciates this vantage point as well.
In typical, highly functionality agile environments, a single product will be broken down into multiple product teams with their own product manager, design lead and team of developers which they are tasked with servicing. These smaller “products” will usually focus on “slices” of a user journey rather than the whole experience - another reason why many products feel somewhat disjointed.
The speed of progress is dictated by the speed at which the developrs can ship products, forcing designers to operate at a pace which they’re often uncomfortable with. This also forces them to focus their talents on production and delivery rather than strategic thinking, which may be fine for junior designers but can be both isolating and demoralising for more experienced practitioners.
Ironically, a small group of designers are usually better able to service the needs of a large number of developers by working as a team across the whole proudct, rather than being separated out into individual product teams. However this approach is often branded as “waterfall” and dismissed by many agile proponents.
Now if you have a fairly unreconstructed design team who are more comfortable dictating rather than collaborating, they may have a point. The goal here isn’t to hand a spec document to the Dev team in the form of a set of wireframes or working prototype and simply get them to build what you’ve specified without question.
However I do believe we’re entering into a post agile world where prouduct can adopt the best parts of waterfall and agile, without having to pick one or the other and stick to them dogmatically. Instead, let’s be aware of the differing shearing layers and adopt and approach that works for all parties.
In his recent IA Summit talk, Peter Merholz spoke about the “double diamond” approach, which is the method I personally favour.
At Clearleft we typically undertake an initial definition phase where we talk to the business, interview potential users, develop a product strategy, sketch out the key user journeys and create the basics of a design system. This system isn’t set in stone, but provides just enough of an overview to set the general direction and avoid us aquiering too much design debt.
During this initial phase of the project, the team can be fairly small and efficient. Maybe just one UX designer, one UI designer and one creative technologist. We can test ideas quickly on paper or with low fidelity prototypes and discard work that proves ineffective. We’re iterating, but at a pace dictated by the needs to the product, rather than the artificial tempo of a “sprint”. We’re not looking for perfection, but hope to get the main design problems finished to a level of fidelity all parties (business and tech) are happy with.
Once the plan is fleshed out, we’re more than happy for the tech team to work in whatever way best suites them, be that Scrum, Kanban or some other variant of agile. With a better understanding of the whole, it becomes easier to break things down into chunks and iterate on the individual stories. Designs will change, and the language will evolve, but at a pace that works better for both parties.
This “double diamond” approach places the needs of designers at the forefront of the first “diamond” and sees them leading the initial strategic enguagement. The second “diamond” flips this on its head and sees design servicing the needs of development and production.
I’m sure some people will claim that this to be part of the agile canon already, be that “iteration zero”, “dual track agile” or some other methodological variation. For me I really don’t care, just as long as design gets to dictate the process during the formative phases while development drives production.
On Habit and Self Reliance | March 10, 2015
I learnt to dive the PADI way, safe in the knowledge that my “buddy” would be there to help if I needed them. So if I was struggling to get my fins on they’d steady me, if I got caught in some fishing line they’d untangle me, and in the unlikely event that I ran out of air, we could breath from the same source. The “buddy system” provides a great comfort blanket and makes recreational diving that much safer.
Society often feels like part of a giant buddy system. If something goes wrong there’s usually somebody nearby to help you, whether it’s a parent, a teacher, a work colleague or a friend. However while support networks are a necessity, it’s all too easy to become dependant. This is most starkly reflected by the number of trivial calls placed to the emergency services.
I see this thinking a lot. People automatically looking for external solutions, rather than looking internally. Maybe they think it’s somebody else responsibility, maybe they don’t fully grasp their part in the problem, or maybe it’s just quicker and simpler to ask somebody else for help.
I recently undertook a cave diving course while on holiday in Mexico and was fascinated by the difference between recreational and technical diving. Sure, you still dove as part of a team, and would double check each others equipment, gas calculations and tie-offs (to ensure an uninterrupted line back to the surface). However each person had a specific role to play, whether that was setting the line or leading the team back to the exit.
Furthermore, there was a real focus on problem solving and self rescue. So if you got yourself into a tricky situation, like one of your tanks blew or you got tangled up in the line, you were encouraged to fix it yourself rather than immediately turning to your teammates for help.
As such a lot of the training involve being blindfolded (to simulate zero visibility) and trying to find your way out of a cave, while the instructor simulated various emergency situations like your regulator failing, one of your tanks suddenly emptying, getting your hoses caught on obstructions or losing contact with the line, all while trying to remain calm and fix the problem.
This may sound pretty challenging, and indeed it was. So there were times when I felt my instructor was being unnecessarily critical or harsh. However if you find yourself lost in a cave, 30 minutes from the surface with your air slowly running out and no sign of your team members, the habit you’ve formed by constantly being forced to solve your own problems, may just be the difference between life and death.
The Death of the Agency Has Been Greatly Exaggerated | March 10, 2015
If I lived and worked in San Fransisco, the current “death of the agency” debate may have slightly more poignancy than it does in the UK. San Francisco and the wider Silicon Valley is undoubtedly living through a huge tech bubble, and has been for some time. The slew of new tech businesses quickly hoovered up the local talent, before starting to ship them in from around the country and the rest of the world. This includes dozens of Brits I know who have left these shores for a better life in California.
The tech giants have started to reach their local hiring event horizon, which is one of the reasons they’ve started setting up outposts in London - to gather up all the local designers and developers they couldn’t (or wouldn’t necessarily want to) relocate.
They’ve also started poaching local agency staff or even buying out whole agencies for their talent. So I know at least 4 agency founders who have been bought by the likes of Facebook, Twitter and Google the last few years. It would seem like design staff are now valued at around $1-2m per head as part of an acquihire, similar to their developer counterparts.
Does this mean the end of the agency? Well if I was running an agency in San Fransisco, I may start to worry. It’s a hostile hiring environment and a difficult place to recruit. After all how do you compete with 6-figure salaries, free staff canteens, company climbing walls and a host of other perks?
However that presumes that everybody at an agency want’s to go in-house. Working for an agency has a number of perks, not least the ability to cycle through a whole range of different problems and challenges during the year, rather than focussing on one single product. So maybe you’d prefer to use your design skills to help a charity, rather than optimising ad placement for a wealthy-beyond-belief tech company. Or perhaps you’d like to help improve the digital services offered by your local council, rather than inventing a new way to poke people online?
Not every design or development role at a tech company will be rewarding, even if the salary and environment are. Several friends on mine have described the acquihire scenario as retirement. Getting off the difficult design or development treadmill and settling for a gentler pace of life.
This rings true when you consider that most of the recent agency sales have been companies who are 10-years older or more. Many of these agencies have seen co-founders leave to work with large tech-companies or follow their own entrepreneurial ideas. If this is the environment you’re working in, I can definitely understand some agency founders wanting to get off the merry-go-round and have a more stable existence.
While some of these sales have been a graceful exit for agencies struggling to find business, the majority have been agencies at the peak of their careers, with big order books and companies falling over each other to work with them. So I hardly think that’s a sign of difficulty. If anything I think it demonstrates the ability of agencies to hire great talent, build brand and create demand.
After all, not every company is able to hire a kick arse team, so need to turn to agencies for help instead. Outside the Silicon Valley tech bubble there are all kinds of organisations that need our help, from online retailers to household brands, from universities and charities to museums and public bodies.
Some of these organisations are waking up to the need to upscale and bring some of their digital capabilities in house. As such agencies like ours are as used to integrating with in-house teams as they are working on their own. In fact a lot of clients come to us to help them improve the skills of their digital staff and set a standard, patterns and working practices they can follow. So we augment, extend and provide external perspective, rather than simply offering outsourced delivery.
The skills and resources required by digital transformation are vast, and I believe it’s going to be impossible for every company that has a digital component to resource it completely internally and maintain quality. So while monocultures like Silicon Valley may turn into agency wastelands, large and diverse cities like London, New York and Tokyo will always need a healthy and robust agency culture to both supplement and extend their digital capabilities.
Now this doesn’t mean that agencies won’t struggle. With services like SquareSpace and Shopify eating into the lower end of the market, I think many smaller agencies or individuals will find it difficult to complete. As such I think it’s even more important for agencies to work their way up the value chain than ever before. Otherwise they may find their market slowly eaten up by self-service products and white-labled tools.
On the positive side, this means that agencies will inevitably be forced to get better at what they do, raising the quality for everybody. This can only be a good thing in my books. Sure, a few agencies will wobble along the way, while others will sell their studio and move on. But for every large agency that exists, I see dozens more waiting in the wings, and boy, are some of them good.
So is the agency culture dead? Far from it! If anything it’s the healthiest I’ve ever seen it.
My Concerns about Value Pricing | February 5, 2015
While I think the argument for value pricing has a logical constancy, and sounds great in theory, I worry how it will end up being applied in practice. My main concern is the effect this approach will have on the practice of design and our relationship with clients, although I have a number of practical concerns as well.
The ultimate goal of value pricing is to tie the amount you charge to the value you deliver, rather than the time you’ve spent. After all, the argument goes, the client only really cares about achieving their goals, and not the time you spent getting there. Clients aren’t buying time, they’re buying results.
On first inspection this feels like a perfectly reasonable argument. After all, if your car breaks down you really just want it working again, irrespective of how long it’s going to take. In fact what you really want is a fixed price, rather than the fear that your mechanic will present you with an ever expanding bill you have no choice but to pay. So from the customers perspective, value pricing feels like a good deal.
Value pricing advocates will often say that fixed pricing take the risk away from the customer and put it in the hands of the supplier. So in our car example, the mechanic quickly determines that the problem is most likely a broken exhaust, and gives the customer a fixed price based on all the times they’ve done similar projects in the past. If this job ends up being especially tricky, it’s not really the fault of the client so why should they pay extra? While if the mechanic finishes the job quicker, they can squeeze in an extra job that day and make a bit of money.
Of course this also means that the customer won’t get any benefit if the mechanics realises they can patch the exhaust rather than fitting a whole new system. The customer may also feel a little hard done by if they thought they were getting a new exhaust, only to find that the car breaks down again a few months later. However that’s part of the risk of a fixed price contract that focusses on results rather than approach or methodology. As such I suspect there are ways to structure a value priced contract that helps mitigate this issue.
The problems with fixed price contracts are fairly well known in our industry, so I won’t go into too much detail. However there is a tendency for value-pricing advocates to pick relatively simple examples like that of a mechanic to illustrate the benefits of their approach. Now I don’t think this is a surprise, as I believe value pricing works best for problems that are relatively simple and replicable, like fixing a car or doing a tax return for a small company. Sure there will always be some variance, but it’s usually not that great, and is likely to even out over time.
Design and development services aren’t like fixing a car. Often we’re dealing with very complex problems, the full scope of which only comes to light when we’re half-way through the project. In fact a big part of the project is usually figuring out what the problem is in the first place, making accurate estimation almost impossible. We’re also dealing with problems that vary immensely depending on the companies involved. So the same problem in a large and bureaucratic business could take five times as long as with a small and highly engaged team.
It’s issues like these that prompted the agile movement, and especially agile pricing. While I’m sure it’s possible to blend the two, most of the value pricing advocates I’ve spoke to still adopt a relatively traditional approach to contract negotiation, locking down the scope in order to prevent scope creep. As such this feels like a bit of a backwards step to me.
Up to this point we’ve talked a lot about the fixed nature of value pricing, but we haven’t tackled the issue of price setting. Going back to our car example, our value-pricing mechanic would start by asking the owner a range of questions to determine how important the car was to the driver. So they may ask how much the car was worth, what sort of job the owner had, whether there was a second car in the family, whether the driver had any important meetings coming up, or any commitments they needed the car for that week. If it turned out that the driver needed their car for a big meeting tomorrow the mechanics would price the job higher than if the person was going on holiday for a week and was happy to wait.
This all seems fairly reasonable so far. The fat cat executive gets charged a bit more while the family man has to pay less. However what happens when the mechanise decides that they only want to work for fat-cat business men and women who can afford to pay more?
This is my main worry about value pricing. It used to be that agencies would choose projects based largely on the design or technical challenge. Sure the clients would still need to pay, but a metered rate provided some level of fairness and democracy. Like hopping into a taxi, as long as you could afford to pay the fair, the taxi driver doesn’t mind whether you’re on the way to a business meeting or just seeing the sights. Everybody is treated equally. However with value pricing the driver will ask you a bunch of probing questions to decide whether they can make more money off of you, or wait for somebody more profitable to come along.
As such, there seems something inherently unfair and mean-spirited about value-pricing. Like when a hotel charges you five times more for something from the mini-bar than you’d pay at the corner store. You understand that you’re paying extra for the convenience of not having to leave your room, but it doesn’t feel especially nice being taken advantage of that way.
This brings up one of the big issues of value pricing, which is transparency. If you’re a customer buying digital services, you’re probably dealing with other agencies who charge by time and publish their day rates. As such you probably have a pretty good understanding of what the market rates are and what different agencies of differing abilities, experiences and reputations charge. This allows you to compare one proposal to another, based on how much they charge and how much time they are proposing to spend.
By comparison, companies who engage in value pricing typically refuse to give a day rate or detail how much time they will spend or how the proposal was put together As such you simply have to believe that they will do as good a job as the other companies who are more transparent with their approach. Because of this I can definitely see why some clients would struggle with the concept of value pricing and fear they may be being taken advantage of.
The main approach to value pricing is to figure out what the client values and charge accordingly. So some clients may value a quick delivery while others may value deep engagement. Some may value an immediate spike in traffic while others may value the lasting power of good design. Putting a figure on esoteric values like brand or engagement is difficult, if not impossible, so I worry that value-based agencies will priorities easy to track metrics like profitability. This may encourage them to chase projects that offer quick wins and big payoffs, over projects than deliver harder to track but no-less meaningful value.
I’d hate to live in a world where the best design and development agencies priorities working with banks, oil companies and large retailers, over arts institutions, charities and local government, purely because it’s easier to quantify the value you deliver to these types of organisations, and charge them more. As such this new interest in value pricing does somewhat worry me and I hope it doesn’t signal a slide into a more money focussed and less caring era of design.
Introduction to Value Pricing | November 25, 2014
I think most designers would agree that design has a huge amount to offer businesses in terms of differentiating products, solving complex problems and delivering increased value to consumers. I think most designers would also agree that this ability is often ignored or seriously undervalued by those same businesses.
Value pricing is an attempt to redress the balance by pricing work based on the value it delivers to clients rather than the time it takes to create. The argument goes that the value of a logo, like the Coca-cola logo, is often worth more than the hours that went into its creation. So whether the final creation took a team of branding experts 6-months, or was sketched on the back of a napkin during the first meeting, the value to the client-and hence the cost-should be the same.
This can be best illustrated by the fable of the plumber, who when asked to fix a boiler, pulls out her hammer, hits the boiler in exactly the right spot to get it working, then asked for £100. When the homeowner questions how she could justify such a high charge for so little work, the plumber responds by saying “that was £10 for me hitting it with the hammer and £90 for knowing where to hit”. The implication of this story is two-fold. First off the plumber wasn’t charging for her time on the job, but for all the years of training that led up to that point, and ultimately the customer wasn’t paying for the time either, bit for a working boiler.
It’s a great story and one that makes a lot of sense. After all, there are plenty of circumstances where you care more about the output than the time it took you to get there. In fact with time being so precious, getting there quicker can often be worth more. This is one reason why Concord was always more expensive than a 747, and why some people will pay more for an abridged audio book than the full version - because they value their own time over completeness.
Designers often struggle to price projects based on the value of their work, so typically sell their time instead. As such, the only way to earn more money is to increase their day rate or sell more hours. So when you see news stories of that latest multi-million dollar rebrand, you can’t help but wonder whether all that time was strictly necessary to come up with final logo, or whether it was the agency trying to justify extra revenue through unnecessary focus groups and consultation.
By contrast, value pricing takes elapsed time out of the equation and tries to focus on outcomes instead. That way it doesn’t matter if it takes one month to solve the problem or six if the problem still gets solved to the clients satisfaction. If you’re good at what you do (read “efficient at solving problems”) you’re able to generate much more profit than simply billing on time alone.
Value pricing seems to require a little more work up front as you need to spend time understanding what the client values before you can come up with a figure. For instance, are they willing to pay more for the project to start sooner, or for access to specific experts. Are they looking to hit specific revenue targets by a certain date, or are they more interested in developing out the capabilities of their team? Do they need every page designed and built, or would some kind of pattern portfolio deliver more value? Now none of the questions are exclusive to value proving, but you do need to spend more time uncovering these issues when you take this approach.
Value pricing also seems to imply fixed scope contracts, as you need to define exactly what value you’re proposing to deliver to what price. So there’s an interesting question as to whether value pricing can work alongside agile practices.
On the whole I think value pricing is a very interesting concept and one that I’ve seen come up more frequently over the past few years. Possibly because designers are feeling ever more squeezed to produce more for clients on less. So I can definitely see why people are attracted by the concept. However I also see a number of challenges with this approach, not least that fact that it’s not how the majority of agencies price their work.
In my next post on the subject of pricing I’m going to flag up some of the issues I see with value pricing. Then I’m going to look at the more traditional approach of time-based pricing, paying particular attention to agile pricing. Finally I’ll end things up with a short summary and a list of places you can go to find out more information on this subject.
Craggy Island: The climbing gym that hates boulderers? | September 25, 2014
Over that last year I’ve got really into bouldering. I’m not especially good, but I enjoy the mental and physical challenge of solving bouldering problems over the tedium of a regular gym. I tried rope climbing once, but wasn’t keen on all the equipment or the need to climb in pairs. So I much prefer the freedom and flexibility that comes with bouldering.
When a work trip took me to Guildford, I decided to head down the evening before and check out Craggy Island. I’ve met a few people who climb there and highly recommend it, so I was looking forward to my bouldering session the whole drive up.
I’ve been to mixed climbing and bouldering places before, and have never had a problem. However when I arrived at Craggy Island I was turned away at the door. You see, despite only wanting to go Bouldering, the folks at Craggy Island won’t let boulderers into their gym unless they also know how to rope climb. I tried to explain that I only wanted to use the bouldering wall, but it fell on deaf ears.
Having been rope climbing once before, I decided to try my luck and give it a go. However without the necessary muscle memory I hit a mental block and couldn’t remember how to tie a belay knot. As each successive person passed by on their way into the gym, I began to feel more and more humiliated.
I tried to reason with the guy on the front desk. After all they were asking me to prove I could do something I had no intention of doing, just to get in. A little like asking for proof you can high-dive, when all you wanted to do is a couple of laps of the pool.
I asked if he could jog my memory as I was almost there, but he wasn’t willing to help. Instead he suggested I came back another time to do a refresher course - something I obviously couldn’t do because I was only there for a day, and didn’t want to do because I was only interested in bouldering.
Rather than trying to help, or give me the benefit of doubt, there was a real “jobsworth” mentality at play here. What if they let me in because I said I was going bouldering, but I lied and actually tried to scale the climbing wall not correctly tied in? This would make sense had I not been to mixed bouldering and climbing gyms in more litigious countries like the US and faced no such problem. Instead you just sign a waiver, hand over your money and are trusted to do the right thing.
Walking out of the gym I felt angry, humiliated and dejected. What should have been the highlight of my trip turned out to be the low point, and put me in a bad mood for the rest of the day. Instead of a great climb I left with the feeling that boulderers aren’t welcome at Craggy Island, and I most defitly won’t be going back.