Can we use game design to better explain what designers do?

Is game design a better example for explaining user experience than productivity applications and the role of designers? With games, a designer is concerned with the details, performance and responsiveness but a shiny game with no soul is worthless. Game designers care about the game mechanics, the rules, the constructed reality, carefully balancing challenge with feasibility – and some of these attributes cannot be designed without feedback from players.

I was thinking about the Redeemer weapon in Unreal Tournament (one of the last games I played before resigning myself to the fact I could no longer use a mouse) and how everything about it would have to be tweaked and dialled in to the correct settings to make it valuable yet also defeatable. The size of the missile and visibility, its velocity, maneuverability, susceptibility to damage, whether homing missiles could lock onto it, whether the controlling player would be completely vulnerable and unaware of their surroundings while operating the missile, the blast radius, respawn time etc. The Redemeer surely would have been tweaked dozens if not hundreds of times before the designers were happy with it.

That’s all quite detailed designed; there are levels above and below that; what is the point of this game? Why might it be attractive to players? Will they stick with it for months or years? Will they lose interest and why? Will it become too hard over time for new players to break into the game against players with hundreds of hours of experience?

Some game designers might prefer to work down in the weeds designing the graphics and physics, others might be more interested in the strategy side that’s almost more marketing than programming. They’re all designers.

If you enjoyed this article please share it with your friends and colleagues.

Let’s talk about gamification

Some painful truth for designers from game designer Eric Zimmerman on Mark Pesce’s podcast The Next Billion Seconds:

Eric: I’ll just be flat out: For me, gamification is generally not a positive thing.

Mark: Is that because it’s trying to get you to do something you generally wouldn’t do on your own? Is it depriving you of your agency?

Eric: Well, it’s because gamification generally means strip-mining superficial aspects of games, right? Rewards, points, the kind of the behavioural psychology of games and leaving behind the soul of games.

Mark: The wiggle room.

Eric: The kind of deep, playful innovation. So part of it is, every design – I’m a designer – and every game that’s designed, every chair that’s designed, every urban plan that’s designed implies a sort of model of what it means to be human in the design.

Mark: Well, there are assumptions that are baked in about the way you’re going to behave and approach and all that.

Eric: Exactly. So if your idea of designing a casino machine or a mobile app for behaviour change or social change is a Skinner box where your model of a human is a rat being given rewards or punishments …

Mark: For pressing the bar.

Eric. That’s right. Then that’s a very impoverished idea of your audience and what it means to be human.

Mark: Does it impoverish the audiences playing that game?

Eric: Well you can have short-term benefits from behavioural modification, there’s no doubt about that, so if what you want to do is assessment and research you can manipulate people into changing their behaviour but there are other behaviourists that have written about this idea of being punished by rewards.

So for example, if you have a kid and you want to reward them for cleaning up their room. If you start rewarding them for cleaning up their room the danger is that they will only ever clean up their room if they get a reward; they don’t learn the positive intrinsic value of having a clean room – in fact, it’s sort of the opposite. They learn that the standard is to have a dirty room and they’ll expect a reward for cleaning it as a special case.

You can actually educate the opposite of what you’re trying to do in terms of deep and lasting change, in terms of people learning values and deeper ideas than just a kind of manipulation of their surface behaviour.

So that’s the problem often with gamification that it’s really about human manipulation that implies a very shallow and impoverished idea of what it means to be human.

If you enjoyed this article please share it with your friends and colleagues.

Live-tweeting of Genevieve Bell’s keynote at Web Directions Summit 2017

9:19 AM Strap yourselves in, I’m live-tweeting and it could get wild

9:22 AM Where is technology, public policy, and humanity heading? The intersection and trajectory is interested in

9:29 AM  talking about ethnographic interviewing leading up to AI-human research; descriptive questioning, understanding conceptual and mental models

9:31 AM What might we have called AI if we were naming it in 2017 instead of 1956? What does “artificial intelligence” mean to us, then and now? Fake? Constructed? Unnatural?

9:35 AM AI was spawned by a group of mathematicians and logicians as an attempt to mirror human behaviour, with input from BF Skinner who had a great mechanistic model of humans based on operant conditioning (machine learning?)

9:40 AM Politics, fear of socialism etc all played a part in the inception, shaping and curtailing of early conversations about AI, cybernetics, and intelligent machinery in the 50’s onwards

9:43 AM Asimov’s Three Laws won’t save us from the machines. It’s a nice idea, but we’ll never have such laws hard-coded into all CPUs

9:46 AM Algorithms are trained on data … a biased, incomplete set of data … information about stuff that has happened, not things that will or might happen

9:51 AM Talking about marked and unmarked categories in feminist theory, and relevance to AI, constrast (what AI is and what it is not) and marking … belonging, nationality, heritage, selfhood etc

9:53 AM Why are only Watson, DeepMind etc the few considered “true” artificial intelligences? Why are “lesser” machine-learning algorithms considered not intelligent? Does that mean only true AI are worth ethical analysis?

9:58 AM How have people, societies, economies, governments responded to “waves” of industrialisation over the past 250 years? What did steam engines really do for and to us? Mass production? Automation?

10:07 AM We created engineering schools in response to industrialisation, business schools in response to capitalism, computer science curriculum in response to computers … so might that imply that we need something other than CS to see us through the coming AI revolution?

10:08 AM I don’t know why I used “AI revolution” there but I did, what does that mean and imply? Is that how you see it? What will be different about our world in 30 years?

10:10 AM Why would we be okay with autonomous technology if we don’t even permit autonomy within our societies? Are you an autonomous employee? Consider “robot” is derived from Czech word meaning “serf” or “slave”

10:11 AM We in the room at work with algorithms and AI, we are feeding these things data, building apps that feed them other people’s data … so we’re all involved (and complicit if things go pear shaped)

If you enjoyed this article please share it with your friends and colleagues.

Don’t politick. Use data.

From Work Rules! by Laszlo Bock

Relying on data – indeed, expecting every conversation to be rooted in data – upends the traditional role of managers. It transforms them from being providers of intuition to facilitators in a search for truth, with the most useful facts being brought to bear on each decision.

In a sense, every meeting becomes a Hegelian dialectic, with presenters providing a thesis and the folks in the room providing an antithesis, spurning opinion, questioning facts, and testing which decision is correct.

The result is synthesis, a closer approximation of truth than if we had relied on mere pronouncements. One of the core principles of Google has always been “Don’t politick. Use data.”

If you enjoyed this article please share it with your friends and colleagues.

Design enhances the way you look at the world

From the opening chapter Uncertainty: Your Secret Weapon from Design a Better Business: New Tools, Skills, and Mindset for Strategy and Innovation (Wiley, 2016)

Design is fundamentally about enhancing the way you look at the world. It’s a learnable, repeatable, disciplined process that anyone can use to create unique and qualified value. Design is about creating the conditions by which businesses thrive, grow, and evolve in the face of uncertainty and change.

As such, better businesses are ones that approach problems in new, systematic way, focusing more on doing rather than on planning and prediction. Better businesses marry design and strategy to harness opportunity in order to drive growth and change in a world that is uncertain and unpredictable

If you enjoyed this article please share it with your friends and colleagues.

Why you must decide acceptable quality early

If you look at the surface of a cycle path and a road they look remarkably similar. The same crushed blue metal embedded in bitumen, rolled flat, white painted lines to designate lanes.

Comparison of surface of tertiary road and cyclewaySurface of road compared to surface of cycleway – can you tell which is which?

But the fundamental design and architectural decisions that went into the cycle path versus the road are very different; one is intended to carry cars and trucks and costs significantly more whereas the other is for pedestrians and bicycles only.

Everything below the surface is different: the depth of excavation and preparation of the bare earth, the laying and compacting of base material and the type and size of machines used to do it, the inclusion of shoulders, the schedule for maintenance and repairs and tolerance for defects and damage.

You can’t lay a cycle path and then decide to use it for heavy vehicular traffic as if it were a road even though it looks like a road (though narrower). You could re-purpose a road for cycle traffic only but that would be an incredible waste of money to lay a road if not for use by heavy vehicles.

Likewise with technology, you should make decisions about quality at the beginning and meet those quality criteria at every step.

If you start with relaxed criteria and a lower threshold for accepting software and technology and want to raise the bar later there’s a good chance it’ll be cheaper and safer to throw out everything out and start again.

There are misconceptions that iterative development as done with agile methodologies permits starting with a quick and dirty prototype or MVP and then gradually improving quality whilst also adding features, allowing the design and architecture to somehow emerge organically with little forethought.

This is foolish and will impede your agility; it absolutely is not a practice implied by the Agile Manifesto or Principles, or Scrum, or XP, or any methodology I’m familiar with.

I’ve always said that prototypes are fine, as long as you understand that the outcome is not the code but the learnings. There should be a permeable barrier between project stages so that code isn’t carried across into what is intended to be a production-ready, secure, stable, reliable, usable, and useful product.

Don’t be tempted to dilute and compromise your product with lower-grade code, design, and infrastructure.

Don’t build a cycleway and then drive a 5-tonne truck on it.

If you enjoyed this article please share it with your friends and colleagues.

Space Invaders analogy against dual-track Scrum

I have an idea for an analogy for iterative design and development that doesn’t slice off the designers as a run-ahead team within a dual-track process; it’s just a brain dump and I’m interesting in your feedback and suggestions.

I’m a strong advocate for a properly integrated design capability in Scrum teams, not sitting outside in a dual-track team where the designers work a week or more ahead of development and hand-over specifications to be implemented. The dual-track approach breaks the desired cyclical nature of agile into mini-waterfalls, excluding non-designers from the design process and reducing the impact of feedback and learning into refining the backlog. A dual-track approach puts designers in the pole position which is not ideal (though as a designer it can be comfortable, but not effective).

Problem is, dual-track is wildly popular because it’s easy. I’m not interested in what’s easiest. I’m interest in what’s efficient, effective, utilises the full collective capabilities and expertise of teams and adheres to the cycle of planning, doing, studying, and acting rather than merely rolling out a pre-determined backlog regardless of impact and benefit.

Space InvadersThe central idea is Space Invaders; every shot wears down an invader, some invaders (level bosses) require a lot of firepower to bring them down and you don’t work sequentially left to right; you might be working on shooting down a dozen invaders at a time.

Of course, an invader is still operational until you completely destroy it, but that doesn’t mean non-fatal shots are wasted.

The parallel with agile is that a team doesn’t have to work sequentially; think of an undamaged invader as an undefined problem or opportunity, the very beginnings of a user story or product backlog item.

The team can choose to focus their “firepower” on one story at a time but more than likely they’ll have a bunch of stories in various stages of destruction, or delivery as they progressively refine the backlog, discuss and workshop epics and stories, thrash out and test concepts.

Varying cascade of features from inception to ready for sprintSome features and user stories might require more discussion, research, testing, prototyping, and technical attention to get them ready for a sprint. Some are straightforward and can go from inception to development in an hour, others might need to be kicked around for a few weeks or more before they’re sufficiently detailed and able to be estimated, delivered, and tested.

The design “requirement” for some user stories might be satisfied with a quick sketch on the back of a metaphorical napkin whereas others – the level bosses – might require an extended game to go deep, research and prototype.

This doesn’t imply dual-track Scrum; like Space Invaders there is one defensive gun, one team. The team chooses what to focus on and where to allocate time and effort. Note that the effort expended on refining a user story or breaking down an epic may not be proportionate to the effort required to deliver those stories.

There may even be some rhythm to how they work; spending time on the closest, most urgent, and nearly-defeated invaders (user stories to be delivered in the next sprint or two), then some time on the middle tier of as-yet untouched invaders (proposed new stories), and some time on the bosses at the rear (the hairy, complex problems and opportunities).


What do you think of this analogy? Is it relevant? Useful? What else is there in this parallel? Are you a supporter of dual-track? Do you think designers should – or shouldn’t – be part of the Scrum delivery team?

Do you think there should be a designer working in the sprints at the point end of delivery and another outside the team working on the longer view product roadmap? One designer doing wireframes for the developers, in turn informed by other designers doing user research?

Or do you think that the design-development mini-waterfall within Scrum where designers work ahead of developers and handover specifications is silly and can be addressed through creative and collaborative approaches? Is dual-track a symptom of teams who don’t quite get it?

If you enjoyed this article please share it with your friends and colleagues.

Three main types of people encountered in attempted disruption

When it comes to disrupting organisations, I’ve found there are three main types of people:

A) Those who embrace change – regardless of personal discomfort, temporary loss of certainty, and sense of competency – who participate optimistically but can reinforce your own beliefs about what is the correct path. They give you confidence and momentum but don’t do much in the way of challenging your assumptions.

B) Those who think there’s nothing wrong with the status quo or who are diametrically opposed to your vision with no common ground. They may argue or sit on their hands, exclaiming “Don’t fix what isn’t broken” believing everything you do is compromising their well-oiled machine and should be rejected, and perhaps they’re right! You are seen as a liability and nuisance.

C) Those who recognise the need for change but don’t agree with your vision for it “Let’s do something, but not that”. They might get bogged down in details depending on how far their idea deviates from your own but they can helpfully calibrate your own sense of direction in case there’s a more optimal route or destination.

Change vision alignment radar chart

If you enjoyed this article please share it with your friends and colleagues.

Business must embrace Agile alongside IT

From Jason Little’s book Lean Change Management:

The introduction of Agile amplifies the complexity of interconnected organisations. When IT adopts a radically different way for implementing projects and focuses on earlier delivery and cross-functional teams, the business  must change their strategy and structure to match. When that doesn’t happen, friction between IT and the business is amplified.

That friction leads to more separation between IT and the business and ultimately leads to the organisation sliding back into the old way of doing things.

If you enjoyed this article please share it with your friends and colleagues.

Design vs implementation, from Marty Cagan

An excerpt from Inspired: How To Create Products Customers Love by Marty Cagan (a founding partner of the Silicon Valley Product Group and previously senior vice-president of product management and design for eBay, vice-president of product at AOL and Netscape Communications):

One thing that many teams try to do in parallel – but should not – is user experience design and implementation.

There are several reasons for this:

First, there is a dynamic in software teams that is important to recognise; once implementation begins, it becomes increasingly difficult to make the fundamental changes that will likely be necessary as you work through your user experience design ideas.

Partly this is technical – engineering teams must make some early architectural decisions based on assumptions about the requirements and designs in order to make progress. These early decisions are important and have big consequences.

Partly, this is psychological – there is a mindset that takes hold once the team shifts into implementation mode, and it’s demotivating to go backwards.

Partly, this is practical – the clock is ticking, and rework and churn just compounds the pressure the team is under. So even though methods like Agile advocate embracing change, you quickly find that some changes are much more welcome than others.

Second, user experience design deals with the very difficult question of both usability and value and, in order to come up with a product that is both usable and valuable, you will need to try ideas out – early and often.

One common response is “We’ll get feedback in beta,” or with Agile teams, “We’ll test the idea out at the end of the sprint.” Unfortunately this is far too long to wait to test out an idea. A good user experience designer will want to try out dozens of ideas and approaches in a matter of days, and the thought of waiting even for a two- to four-week sprint would be debilitating as the frequency is an order of magnitude too slow.

[…] Fourth, while it often makes excellent sense to break up a release into several iterations to implement (this reduces risk, improves quality, and eases integration) a user experience is often not something that can be designed in pieces. You have to look at the user experience holistically – it has to make sense to the user at each release. While it’s easy to “stub out” software that’s not yet available, it’s not so easy to do the same for the user experience.

If you enjoyed this article please share it with your friends and colleagues.