The first ever Generate Sydney was held at Doltone House, 2016.09.05.

Disclaimer & Image Credits

These notes were hammered out very quickly because doing so seems to help me remember them. Note: always assume I’m paraphrasing – if you need an exact quote, check a definitive source such as a recording or slide deck.

Photo credits as per the social media embeds.

Predict The Future With This One Weird Old Trick – John Allsopp

John “I’m a bit older than a lot of people in this industry…” You realise you can’t get your time back. It’s your most precious asset, so where and how should you spend your time? How much would you pay to get three years of life back? Youth is wasted on the young, but wisdom is often wasted on the old.

We love to make predictions, of varying degrees of accuracy. The further ahead we try to look, the worse our predictions get. There are many great bad predictions as well… people didn’t think the phone would be a success, online shopping would fail, computers might get as light as 1.5 tons and nobody will want one in their home anyway.

So why do we get all these predictions wrong? Broadly we are trying to predict what people will do, as well as what technical disruption might be possible. Predictions are often more like acts of faith than real extrapolation or expectation. We do love to pick on the wrong calls made by fallible humans, though… like Ballmer predicting the iPhone would get zero traction in the market.

Very early in the web’s history, people tore the web apart – servers were wrong, HTML was wrong, giving it away for free was wrong wrong wrong.

The lesson in general is that we predict the future by thinking about today… with jet packs added.

Our ability to predict the future is much better than we think, we just don’t think of things as predictions.

I skate to where the puck is going to be, not where it has been. – Wayne Gretzky

Asimov talked about psychohistory, trying to handle massive time frames and massive scale… using sufficiently large amounts of processing power, we should be able to predict far, far into the future.

Reference: StarFire, a video predicting the future of technology and UI (and hairstyles). It’s particularly poignant in that it was predicting the future of tech, but used Princess Diana as an example of breaking news… but she had passed away between the time the film was made and 2004 (the year it was projecting).

When we predict the future, we focus on what changes – forgetting to account for things that don’t change. Or things that change very slowly, then all at once. Human nature, for example, doesn’t change quickly.

What are some rough rules for predicting the future?

  • Humans tend to spend either far too much time on something, or far too little time.
  • Humans are really bad at understanding exponential growth. Exponential changes happen gradually, then all at once (Mark Twain quote about going broke). Moore’s Law has held for 50 years, even though Moore himself only thought it was certain for 10 years.

Consider the 1.5 ton computer concept… people didn’t imagine putting the computer in your pocket.

The Jetsons is perfect jetpack futurism – none of the social structures had changed, despite profound changes in technology. However it still predicted things like voice activated UI and videoconferencing. But we’re still making those same 'predictions’ now, where we treat video conferencing as thought it was still magic.

Koomey’s Law – predicted the rate of battery life, which is even more interesting than Moore’s Law in many ways. ARM used Koomey’s Law to look to the future and bet on low-powered computing. So did Apple, being a founder of ARM; and went on to benefit with the iPhone many years later (even though it sold its share of ARM).

Metcalfe’s Law – predicted exponential growth of value as you add nodes to a network. Although Metcalfe also predicted the internet would catastrophically collapse in 1996… so nobody’s perfect.

Sarnoff’s Law – predicted linear growth of value as you increase the reach of a broadcast network

Butter’s law of photonics – price of delivering packets on a network halves every 9 months. This is how Netflix predicted streaming would become a great business model, even though it wasn’t viable when they started.

Christiensen’s Law – Clayton Christiensen gave us the term 'disruption’ as we (mis)use it now; and also wrote the Innovator’s Dilemma. He observed most changes in technology occur by things being 'worse but different’. The telephone wasn’t replacing message boys, but that’s what people understood so that was their frame of reference.

These laws aren’t laws like the laws of physics, they are not hard laws.

The best way to predict the future is to invent it. – Alan Kay

Where are these trends taking us? What we will be doing in that world?

John suggests…

  • The disappearing browser – the idea that our web content lives in a browser will change.
  • Disappearing platforms – the days of the OSX vs PC Guy are past. The platform used to be paramount, but this will disappear. As platforms proliferate and also become less important, we (web publishers) will need to reach all of them.
  • The disappearing screen – we have so many screen sizes already, but we are getting more without any screen at all.
  • The disappearing app – apps are an artefact of our devices, a concept from the disconnected world when devices needed to be self-contained. They are a local maximum.
  • Emerging data platforms – everything we do could produce massive amounts of data. Cars get this wrong – they sense all kinds of data, but it’s locked away and not revealed to the user or as a platform to innovate on. We stick screens on washing machines, when we really want a “notify” button so it doesn’t beep at us, it sends us a message on our phone (the screen we already have and will upgrade many times during the life of the washing machine).

So what is that one weird old trick?

We live in a world of exponential change. The trick is to look for the tipping points where growth stops us doing the same thing a little quicker; and makes start doing something really different. Look deep into the future along known exponential curves and you can see where companies like Netflix and ARM made their predictions (and subsequent business bets).

So take on Alan Kay’s one weird trick: to predict the future, invent it. Go from thinking about the future, to making it.


Crafting A UX That’s Fast & Rich – Mark Zeman

How do we deliver a rich and engaging experience that’s still fast? The process is more important than the specific techniques or tech.

The fastest page is a page with nothing on it. ...we can blame a bit of this on Steve Souders with his points about things to remove! But we need to avoid total reductionism. Minimalism is great, but gets boring.

Controversially, Mark misses Flash. It wasn’t bound by layout issues, it was also time based. You had to think about timelines and not just where to position things. He acknowledges that Flash also led to some atrocious sites. But we have lost the richness and creativity that it encouraged.

How do we create a rich experience without making it so slow that users get bored and leave? People want content in less than a second, on all devices – people no longer accept the idea that mobiles can be slower.

Example project: Shihad website with heaps of video (slow motion capture of people being blasted with air and water canons). Streamed two videos – one with a background grid and soundtrack; and a second over the top if you popped out a 'frame’. The slow motion video allowed very high compression, in turn making it possible to stream two videos at once – even on broadband as bad as Australian broadband.

Example project: Erky Perky game website. Had huge challenges trying to get enough content at high enough resolution, without making it too slow to engage kids (fans of the show). They worked out the best compression systems, then briefed the animators how to animate according to those constraints. They made animations that created a great effect but was still sympathetic to technical constraints.

Example project: tourism New Zealand video and site where you scrolled through the video. was criticised for being 23 megs, but the brief to the devs was 'no loading bars’. They did this by creating a sprite sheet and using canvas to pull out the frames – they were super blurry, but they gave the user a cue that things were loading without spinners or loading bars. Then the high resolution frames loaded over the top.

Performance and user experience are guiding principles throughout. What are you trying to achieve and how long will users wait for what you’re trying to achieve?

Like any good craftsperson, understand your tools. Understand the mechanics, understand deep details like latency and TCP slow start. Embrace the browser-critical rendering path and slow devices (the Next Billion will probably be on slow 2G connections). Embracing these boundaries encourages creative solutions.

Take a time based approach.

We need to move away from the idea of the web being a static medium. We think of opening a site much like we think of yanking an unchanging book off a shelf. This starts from the beginning when we pitch with wireframes and mockups. We show the end result of loading and nothing about the experience and reality of loading it.

We should stop talking about pages. We’re not making books.

Change your language to change your behaviour.

Take these questions into your next meeting:

  • How will this experience flow over time?
  • What happens first, then next?
  • What does each moment look like as it loads over time?
  • How does it play?

Focus the team on a timeline. Draw some inspiration from the filmstrips in performance testing tools like SpeedCurve and WebPageTest. Use the film strips to communicate the concept and challenges of performance. Show managers their website versus a competitor website… they wonder what all the blank frames are. They want less blank frames than their competitor. The New Zealand client looked at this information and decided to switch off third party ad code that was killing the load time.

Yes, Flash used to make us think about the timeline!

Think timelines not pages. Think of mouse clicks like hitting a play button. Use movement to add narrative – use transitions as a feature to guide the users attention and also give some time to load content. Can you get a skeleton screen down in the first request? Give the user something that tells them they are in the right place and content is coming.

You’re not making pages, you’re making movies!

(finishes with Looney Tunes that’s all folks!)


Motion In Design Systems – Val Head

Val really loves the web and animation and the potential of it all… but hears lots of stories about the reasons why people don’t use animation. No time, too hard, client won’t pay, nobody makes my stuff…

So how does animation usually enter a project? A project runs for a while, but then people want to add some oomph and they decide to put animation in. They mock up some videos and throw it over the fence to the developers. The devs didn’t have that in the spec and what goes back to the designers isn’t what they hoped for… nobody’s happy and they decide animation is out.

Improve animation communication:

  • shared vocab, shared understanding
  • establish animation values
  • document things so future you doesn’t have to make decisions all over again

Talk about animation early, often and as specifically as possible.

Deliverables can be made far more clear. Explore with storyboards and sketches… Don’t get hung up on doing Pixar-worth storyboards, where every frame is a work of art. Just do rough sketches – just enough to get the point across and nothing more. Everyone can draw well enough to sketch a UI idea. Also people will give more feedback about a rough sketch – they don’t feel it’s too far gone, too finished to say it should change.

Questions that come up about storyboards and sketches:

  • where is the potential for animation?
  • how do the elements load into view?
  • how could we animate between views logically?
  • “I have this crazy idea…”

What to draw? (Credit to Eva-Lotta Lamb)

  • Trigger – what makes the action start? Draw or describe it.
  • Action – what actually takes place? Draw just as many frames as needed to illustrate it.
  • Quality – how does it happen? How do things move, how fast..? Describe in words.


  • anything you can draw with! just pick up a pen and draw.
  • yes Sketch and Illustrator are ok as well, if you’re fast enough with them.
  • for higher fidelity: motion comps (actual videos, hi fi but not interactive) – After Effects, Flash/Animate CC
    • How should it look, exactly?
    • How do we guide the eye through the sequence?
    • Does the animation reflect our brand?

Handoff details to include

  • Duration and delay values (don’t make people guess)
  • Details of the easing used
  • Repeat values, iteration counts (don’t make people count)
  • Notes on how animations interact or are triggered

This should tell you how things will feel, what they’ll be like to use. What personality does it have. How will animations interact with input or real data? Does everything still hold up when you move out of ideal cases?

Interactive prototype tools – Framer, (one I missed), or just use a screenshot with one button animated over the top.

Make as many prototypes and deliverables as you need, but get feedback and input along the way.

Define & Document – save Future You lots of time and effort!

Shared animation values and rules create a greater sense of choreography and cohesiveness.

Defining your brand in motion:

  1. Brand personality – is it cartoony? smooth and serious?
  2. Prototype, explore, iterate
  3. Extract values – what do you iterate, why and how

Example set of values:

  • Animation should have a reason to be there
  • Animations should be living, lively and considered
  • Animations should be cohesive, but not homegenous

Building blocks:

  • Durations – ranges, rhythm
  • Which properties do you animate?
  • Easing values
  • ...

Document the good decisions and capture what gives the right brand personality. Show the code if you can, make the documentation practical. If people can copy and paste they are far more likely to follow the rules!

Consider the animation spectrum, from a static web site through to “A weee! Look at me! app”. Errors and repetitive tasks want to be at the static end of the spectrum, with more expansive animations for achievements and milestones.

Define the 'physical’ space – gravity, distance between layers, etc. Define any named animations – the key animations you use, with names people relate to. Define what those animations can be used for (eg. a fade in/out might only apply to opacity). The key is to use the same words, not to be super formal with those words.

Keeping it real – how to really make it happen:

  • Be an undercover animation hero – show people the value of animation, show exaples, model the right discussions
  • Make small changes over time
  • You don’t have to ask for permission


Responsive Web Apps With Container Queries – Jonathan Snook

Even though the title mentions code… this is a talk more about process than code.

Mister Snook works for Xero, whose tagline is “beautiful accounting software”. The reality is the design could be better, so they set some goals:

  1. Evolve the design
  2. Support multiple devices

These goals have been a common theme for Snook’s career – same goals at Yahoo! back in 2009. but people were still in the habit of building a whole separate application, each separately and specifically designed for the device. This was where SMACSS was born. They needed designers to see a feature through all platforms.

Then Snook moved to Shopify and … yep, same two goals! The code base was a monolithic application with dev-accessible templates. They could quickly and easily make changes to the UI, which really helped. The UI was centralised and design changes could be rolled out across products really quickly.

Responsive web sites are usually relatively straighforward. Each page can be art directed and the content is structurally similar and in consistent contexts.

Apps are different – the same component will be shown in lots of different contexts and sizes, with lots of variations. A single view can have dozens of variations – empty/no data, large data sets, error and success states, etc. This makes it hard to manage components across the whole system.

With container queries, you only have to know the interplay within a single object. They let you work out how a component should respond in real life.

But… there is no spec for container queries :( We can use JavaScript. Actually you can declare it in HTML, CSS or JS. There are lots of polyfills for the imaginary spec (eg. eqcss, elementQuery, eqjs). Wherever you declare your queries, you are basically creating an API that your devs need to follow. Shopify chose a JS API.

Going responsive meant a consistent feature set across all devices. New features automatically have cross-device support.

There were some challenges of course – some areas of the product couldn’t easily be converted to a mobile experience. There was a discernable delay in execution – about half a second – which was accepted as a tradeoff.

Design things to purpose, not the properties. Most designers immediately define a huge grid system which is mostly unused. Shopify really only had about 4 layouts… so they made classes to support those. Instead of dozens of classes to handle every possible layout, the single-purpose classes required much less code.

Tables are extremely difficult to handle responsively. They had to come up with multiple approaches and work out which one was right in each case.

You can’t do all this stuff alone! Talk to design and dev, work together to come up with solutions. Product design is a team sport.

So, back to Xero…

Reframe Goal 1: Allow anybody to make product-wide design changes quickly and easily.

Xero had different tech stacks from page to page, so this was a bigger challenge than it might sound! That was not obvious to the user, but it was hard for dev. They decided to unify on a single tech stack – they happened to choose React.

Make the right things easy and the wrong things hard. By creating an API in React it was easier for people to just use it.

Time passes…

  • Yahoo still does a custom experience per device
  • Shopify is removing element queries
  • Xero… time will tell!

The challenges of going responsive are often more political than technical. Success depends more on people than code.

Last thoughts

  • Designers should think responsive before they actually have to
  • Container queries do save time
  • There are techniques that will avoid the need for container queries

Go to to push for element/container queries


Mini Workshop: Mobile Sites And Accessibility – Gian Wild

Unusually my laptop needed a mid-conference charge at the time so I didn't get notes - see the slides:

Beyond Measure – Erika Hall

(Relates the story of Deep Thought from Hitch Hiker’s Guide to the Galaxy)

Why was 42 an unsatisfying answer? It would have been simpler to know the question! Douglas Adams knew that humans craved mathematical certainty in an uncaring, complicated universe. People were so keen to calculate their way out of all human problems. Adams knew that all the computer power in the galaxy would not really give us the answer to what things mean.

Humans have a terrible problem: born sentient and wanting to feel special in a massive galaxy where we are not special.

We have to work together to solve problems. Maths and measurement seem defined and solid, but they are still subjective. Quantitative approaches often feel better while actually being worse. We are imperfect humans, designing things for other imperfect humans.

DON’T PANIC. Don’t give up on data just because it’s imperfect or because humans are illogical.

Example of a problem solved: the iron fish to stop iron deficiency in Cambodia. The problem seemed so simple – just whack a piece of iron into the cooking pot. But it turns out a Canadian guy turning up in Cambodia with an ugly rock… it didn’t convince people. When he went back and talked to people some more, he learned about a particular river fish that was considered lucky. So he made the iron pieces into lucky fish shapes – and people were more agreeable, they adopted the fish. Villagers who used the fish saw health benefits (or at least that problems stopped) and started recommending other people use the lucky fish as well. The science didn’t work, but folklore did. Understanding the human experience made a bigger impact than the scientific data on its own.

A good story gives data greater meaning. People can relate to a story more easily than qualitative research.

Humanity now produces more data than it can handle. We now have to track the data on how much we talk about data. 90% of the data ever produced was created in the past few years. Is it leading to great insights into our existence? History suggests that the great advances came from human insights into data, so shouldn’t we be making better decisions with all that data?

Visual trick image with two copies of Batman facing each other, but overall the image looks like Wolverine.

Our brains are always trying to trick us. Without a lot of training, we will find patterns in data that match what we expected to find there. This is easy, our brains like it and it feels right. Simple explanations feel like they should be true.

Data doesn’t change minds.

Research is actually showing that bombarding someone with facts makes them believe their original position more strongly. We read the terrible nutritional information on junk food, then eat it anyway. We do what the CEO demands.

It’s interesting to think about the things we “know” that we couldn’t actually prove. We believe science, but could we prove it? Our access to data has evolved, but our brains haven’t.

We have more data than we know what to do with.

There are two types of data that are useful: qualitative and quantitative.

Qualitative data can be described in words; quantitative can be described with numbers. The numbers are always affected by the social context (words, ultimately) around them. To analyse qual data you need good critical thinking skills; to analyse quant data you basically need to be a statistician.

Our desire for control creates methods of capturing data that aren’t valid. We put people in strange situations and ask them about normal situations. We do research that confirms our own bias. Fishing trips, not research.

What are you trying to do? What outcome do you want to optimise for?

This is the fundamental question of design: how to get from WHAT IS to WHAT OUGHT TO BE. We need a clear goal, and a clear understanding of where you are starting from.

Projects are just a series of decisions. Using data suggests we are making these choices by evidence, it comforts people who want mathematical certainty.

Surveys are the most dangerous research tool. They frequently represent the worst flaws of data collection and analysis. They are easy to do and provide small data sets… and easy feels true. Creating a good survey is hard. Bad surveys don’t seem bad.

Don’t ask people what they like and don’t like; don’t ask them to remember things; don’t ask them to predict future behaviour (“how likely are you to…”).

Ask yourself: will the people I’m asking be willing and able to provide a truthful answer to my question? If not, it shouldn’t be a survey.

Only when you know the question, will you know what the answer means.

At its core, all business is making bets on human behavior. – Ben Wiseman, WSJ

Last thoughts…

  • Define success first. Start with what’s meaningful for your business. How do you make money, or define success?
  • The most measurable data is not the most valuable.
  • Make better choices. Ask better questions, choose better metrics. Do things that meet your goals.

book: Just Enough Research


Using Flexbox Today – Zoe Mickley Gillenwater

Questions to ask deciding to use flexbox:

  • Browser support? actually no, browser support doesn’t really matter; support is good enough to use it as a progressive enhancement. Browsers that don’t support flexbox have usually been getting a fairly poor experience, so they won’t 'miss out’ if you give a better experience to newer browsers.
  • Do I want to create a layout in 1 dimension (row OR column) or 2 dimensions?
  • Am I concerned with whole pages or the components within? Flexbox is great for components.
  • Do I need my content to determine layout (flexbox), or should the layout define space for content (grid)? Content-driven design is very different to layout-driven design!
  • Am I working with unknown content, eg. UGC? Or do I control the content?
  • Does flexbox offer me anything I can’t get from an existing layout method?


  • tweaking a form layout so there was no uneccessary truncation
  • tweaking a booking availability module to show a message in a variable space, or push down below when too small
  • lots more (see slides for code!)


  • Flexbox is really good at dealing with variable content.
  • The layouts you can create are often about things that look natural instead of broken.
  • In many cases you won’t need media queries to do things with flexbox.
  • Layout should not be exciting! It should be simple.
  • Beware of reordering content. Do it only for good and not evil. It’s very easy to break accessibility.

Tech tips:

  • Skip the ’09 syntax – let those browsers get the fallback option
  • Let tools add browser variants, don’t do it manually. Autoprefixer, Bourbon, Compass, or just sets of SCSS mixins (arguably the best option).
  • Modernizr and suports@ are good options for isolating flexbox, although IE10 and IE11 are excluded by supports@
  • Flexbox will not override absolute positioning. That means you can choose floats, table-cell and inline-block as base styles under flexbox enhancement.
  • Write out the full set of flex values – it avoids a lot of bugs from default behaviours.
  • Really pay attention to getting flex-basis right. Use flex-basis:auto wherever possible, it avoids IE10-11 bugs.
  • If using Modernizr: use Too Flexy bookmarklet
  • If reordering, test in screen readers to make sure you haven’t created problems.


Flexbox is not for the future. You can use flexbox today!


Building RocketshipsCreating Products – Cameron Adams

(Cam felt the rocketships were perhaps grandiose… so products :))

The rise of “product”. We used to have Pro_ject_ Managers, but somewhere along the way PM became Pro_duct_ Manager. Cam first encountered Product Managers at Google.

The rise of design. Design has become part of how you decide what product to build and what market you will seek, instead of just making things look pretty. Design has a seat at the table and the responsibility that goes along with that. Product design has replaced “web design”. A lot of web designers made that transition, stepped up and took on bigger questions than how things should look.

Web design was perfect for people who understood design and technology. Product design adds business as well. So you have the goals of the user and the goals of the company to bring together.

What’s going to help you ship a great product? Every word is subjective! What does 'shipped’ mean? MVP, final, a huge release or a quick prototype? How do you measure 'great’? The bar will change depending on scale and business. What is a 'product’? Is it a physical thing, software?

Cam’s own transition has reflected the industry, which has gone through a few job titles: Mac operator → Graphic designer → Web designer → UI designer → Product designer…

On the Wave project they had a 50:5:1 ratio – 50 engineers 5 product managers and 1 designer. Everyone probably had their own idea what Wave was meant to be.

[slide: spectrum – "design is a coat of paint" through to "design is everything"]

Things learned on wave…

  1. (gah missed the first one, my phone rang at that exact moment)
  2. startups in big companies are hard
  3. UX 101
  4. “jazz isn’t about the notes you play, it’s what you don’t play” – product design is about the features you do or don’t build

After the Wave project was closed, Cam worked on Google+ for a while. It was an interesting situation with a product trying to get to market quickly to deal with competition.

Cam feels SlackHQ has done a good job with combined communications. They didn’t rip off Wave they just did a good job bringing the pieces together.

Since this period, design has changed a lot at Google.

Cam learned that specialisation wasn’t his specialty, his passion was making things. He and some others left and created Fluent, another attempt to revolutionise communiation – this time, email. They spent about 9 months making a product that users loved, looked good. They were all the way to the “everything” end of the design spectrum and every detail was perfect. But actual business got in the way.

A journo accidentally gave out the beta signup page. They got 40k people on the list at a time when it cost $6/month/user… but they also got a bunch of VC enquiries. But two months later they’d done a ton of pitching and no product development, and they didn’t land VC. They returned to Sydney tail between the legs, broke and had to shut down.

Lessons learned from Fluent

  1. scratch your own itch – it makes it amazingly easy to build something
  2. if you’re after funding, do it with a purpose – they didn’t know how to raise or use funds
  3. build a company, not a product – the product can’t live by itself, it has to live in a framework of people; customer support; finances; having enough hours in the day to actually see your family

At this point he met Mel and Cliff and they formed Canva. That was 4 years ago. They have 10k users, 120 employees.

In the early days they were all generalists, they all had to wear lots of hats. As the company grew, Cam’s involvement in the company became less direct – you have to be able to step back and let people do their jobs – and that’s a real challenge. The temptation is to get in and do the work, but it can’t scale.

Lessons learned from Canva

  1. go the shortest distance from idea to reality – know where you want to be in five years, know where you need to be next week
  2. spread out, focus in – focus on the core value of the product
  3. ruthless prioritisation – you have to be doing this constantly all the way through the product development process. Anything is possible, so how do you get down to the ones you actually ship?
  4. small teams – keep groups small and independent enough to make decisions and focus on one problem
  5. launches don’t matter – big launches, big parties… they don’t really matter. The day you launch is the beginning, not the end.
  6. the role of design changes with scale – in the early days it was all just a mad rush, with growth has come more time to think ahead and provide a vision to work towards.
  7. communicate – you can’t communicate enough at a company. Cam’s a bit of an introvert so it doesn’t come naturally. When the whole company sits around one table it’s easy to stay in sync, when you’re sitting across whole floors it’s much harder.

Being a designer is like having a superpower that allows you to show other people the future. – Julie Zhuo


UX For Change – Nick Finck

(hilarious intro with The Final Countdown… also a warning that there are some coincidental similarities with other talks!)

Technology – we tend to think of tech as things like the phone in our pocket.

All kinds of old analog media are being replaced. Big, bulky, inefficient formats replaced with ipods, kindles, media centres and scanned photos. Behind the scenes we’ve replaced sheds full of archive boxes with sheds full of servers.

But globally less than 50% of the world has internet access, even less with broadband.

There is a cost.

We’re in a technology tsunami… ultimately we have to figure out how to survive it and make it work for us – Peggy Klaus

Photo of the pope being announced in 2005 vs 2013, in 2005 it is a crowd of people and in 2013 it is a sea of phone screens recording the moment.

Everyone now has a device in their pocket with huge amounts of processing power and an internet connection linking to other machines with even more processing power.

It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change. – Charles Darwin

We are not surviving, we are barely existing. We don’t have a work/life balance any more, we have a work/life/technology balance.

The age of understanding.

The naked transparency movement marries the power of network technology to the radical decline in the cost of collecting, storing and distributing data. – Lawrence Lessig

DIKW – Data-Information-Knowledge-Wisdom …then A for AWESOME

The future isn’t about finding information, it’s about making sense of it.

All this information coming at us has a cost.

The death of lies – there is no escape, public data shows so much information about people.

There can be no faith in government if our highest offices are excused from scrutiny – they should be setting the example of transparency. – Snowden

Innovation – people tend to think about innovation, they think about doing something new. But few innovations come from nowhere, they usually stand on the shoulders of giants. The innovation is melding existing ideas or products.

We’re not designing for the future; we’re making things that belong in the world we want to live in. – Brian Eno

(also quoted Gretzky again!)

Disruption – displacing market leaders. New companies tend to be the ones to seriously displace established business models and technologies.

Being first doesn’t always mean winning. The Newton and the Zune preceded the iPad and iPod. Customers may not accept the product, it might not work first time, you might be misunderstood (people think Uber is a cab service, but it’s an MVP for when the car is self-driving), there will be push-back.

The first electric cars were shut down by the auto and oil industries (really – they bought out patents and did all they could to shut down EVs).

Failure – a lot of people talk about 'celebrating failure’ but do we really? Do we learn from failure? Do we do the next thing better?

Failure is an option here. If things are not failing, you are not innovating enough. – Elon Musk

Failure is not falling down, it is not getting up again. – Mary Pickford

It’s our duty… act two of the talk!

It’s not enough that we build products that function, that are understandable and usable, we also need to build products that bring joy and excitement, pleasure and fun, and yes beauty to peoples lives. – Don Norman

There’s no mention of a screen! It’s not the UI. Experience is everything, the whole experience and we don’t control all of that. Our work is not just about evoking emotions, it’s about life.

Facebook has the mission to connect everyone. In places with no power or mobile signal, to talk with other people you have to walk for miles to physically be there. People don’t own cars or bikes, they walk.

Facebook is looking at long-flight drones to bring networking to remote areas where current solutions don’t work. What would happen if people could contact each other in seconds? They’ll probably still go and hang out with people when they can, but they could get in touch the rest of the time.

We can’t solve problems by using the same kind of thinking we used when we created them. – Einstein

We must not think of our job to design for someone, we need to think of designing for humanity. We need to craft experiences that create a better future.

We can change the world. This is where the puck is going. We have an opportunity to design the future we want to see.

Impact – Nick has done many things over the years to give back; but he has been doing things 1:1 while looking for ways to scale.

Introducing – … matches people to mentors and gives them charity projects to work on to build an experience portfolio. If you can spare a lunch one a week or even once a month, you can mentor someone who’s earlier in their career than you are in yours.

How are you going to make the world a better place?