Web Directions Summit 2017 was held at the Australian Technology Park in Eveleigh.

An old school jump menu

The Vibe

Break time at Web Directions Summit 17 #wds17 #summit17

A post shared by Jason (@ssofnosaj) on

There was a great vibe and buzz, with excitement in the room and live VR sketch noting adding a dash of future weirdness (check out Matt's blog for more info).

Summit 17 Day 1

Thanks to MessageMedia we could SMS our coffee order and get a message when it’s ready. Not surprising to those who know us (and our coffee obsession), the Ansarada crew won the 'most caffeinated team’ prize (a Golden API Key) for consuming the largest amount of coffee.

The Adobe XD challenge teams presented their solution for enrolling to vote – certainly a big topic with low engagement from young people in Australian politics. All teams produced great solutions, although it quickly becomes clear that privacy and identity verification remain an uncomfortable challenge for government services.

The Meetup Muster was a cool addition to the event, introducing people to a range of Sydney’s tech meetups (SydCSS, SydJS, React Sydney, SydTechLeaders, SydPWA, Tech Talks). Many people come to conferences but don’t tap into the amazing meetup scene in between, so hopefully the Muster will encourage more people to join their local communities. Or, if there isn’t a meetup that scratches their itch, perhaps they’ll be the ones to start them!

My take on the unofficial themes:

  • Openness, inclusivity, empathy… how do we design and create a better future with our work?
  • Algorithms, AI and data are deeply changing tech; with huge social impact. Design and development decisions are ethical decisions, whether people are prepared for that or not.
  • SMS isn’t going away. It’s still a ubiquitous channel and enjoying something of a resurgence with SMS chat bots.
  • Walk-by high fives. Not sure what prompted this trend, but I love it!

Disclaimer & Image Credits

  • These notes were hammered out very quickly and paraphrase what speakers were saying. If you need an exact quote, use a definitive source such as a recording or slide deck.
  • Photo credits as per the social media embeds. Special mention to JJ Halans for his WDS17 flickr set.

Day One

Chris Messina – Lessons from the Death of the PC

Chris Messina

The death of the PC fits into a much broader cultural context. It’s a chance to leave behind some old ideas that have outlived their time, a chance to forget about things that hold us back.

First – how do you define a personal computer? How would you describe a computer to someone who’d never seen one? In 1983 Steve Jobs talked about a new machine with electrons moving around instead of pistons moving around… using the combustion engine to explain the new idea to a room of designers.

Computers deal in pure information, allowing calculation at great speed – far higher than any machine that had gone before. But as the era of the electron comes to a close, many of our assumptions are wrong about what comes next.

Book: Marshall McLuhan – Understanding Media

In modern computing it’s less about the environment and more about the apps. Our experience changes.

Look at the impact of TV on sport. The instant replay turned sport broadcasting into a form of analysis, not just a linear broadcast. Time was no longer linear and unreachable. If you missed a moment, you could look up and see it – from different angles.

In the same era (the 60s), the cold war created the notion of an information war. You didn’t just need bombs, you needed to know where to drop them. Spy planes gathered a great deal of information, which needed to be shared between military sites. ARPAnet was the precursor the web.

ARPAnet map from 1971

This is the era in which Doug Englebart delivered The Mother Of All Demos. His report was entitled “augmenting human intellect” – making humans more capable of dealing with large amounts of data quickly. The information and systems were designed for highly-trained military and academic specialists. Most computers were thin clients connecting to a large, shared server or mainframe.

It was the 70s and 80s that brought in the idea of self-contained/independent computers for the general public – or at least in business. Many common UI paradigms like “folders” persist from this push to normalise computers in a paper-based workplace. This persisted for an unusually long time.

It was 2007 when Apple popularised the next big leap in UI – the small touch-screen device… the iPhone. It broke away from other smartphones with their tiny fixed keyboards; and went back to the old idea of a variable screen and a pointing device. A screen, and your finger. Ten years later this is ubiquitous. Children learn it during infancy.

The massive rise of social media and messaging came along at this point.

Now in 2017, with the Next Billion coming online, what will the first device be for people as they get online? A PC? A mobile? Ambient voice-controlled devices?

We need to look at apps. Apps pushed businesses to create APIs, to understand their own business in terms of API endpoints. Instead of connecting a thin client back to a mainframe, we connect a heavier client to a data endpoint.

Voice control and voice processing are on the rise. Computers will have better speech processing capability than humans.

A side effect of voice search is that Alexa users are not specifying brands, or going to Google to do their searching. It’s not “Alexa, Engergizer rechargeable batteries” it’s “Alexa, rechargeable batteries”.

The importance now is to have a device present at the moment of desire, the moment someone wants something. This is why we have Apple airpods, Pixel buds, etc. Companies are trying to literally get into our heads.

Steve Jobs once described the need for difference Apple devices due to “a difference of emphasis”. Cars, trucks and sports cars share many similarities (engine, wheels, seats) but their purpose gives them a different emphasis.

We have devices now that we touch and talk to; or they listen and watch us. Amazon Look takes a selfie and analyses your outfit…

Now let’s take a little leap, forget a few things, blur our vision a moment.

Children have greater access to mobile devices and spend more time on them than ever before. What does that do to us? ...so how many of you have seen the movie “Her”? (plays a clip from Her where the protagonist’s niece meets his virtual girlfriend)

Kids are growing up experiencing relatives through 2D screens (video chat). They are used to talking and interacting to people through screens. So… what does this mean for human connection? When AI gets sufficiently advanced, how do people truly know that grandma is real?

Kids are growing up with all of this and they’re adapting to it. They communicate in ways we don’t really get.

We have the rise of virtual celebrities. Miquela is big on Instagram, despite not being real. The people commenting don’t seem to know or care that she doesn’t exist. Even if we find it odd at first, this sort of tech will also create new art forms like emoji kareoke.

So what about the responsibility of creators? Making CGI so good it’s undetectable means we can’t trust any image. How do we convince someone an image is real when they know it can be easily faked?

In the early years of the web, we tended to believe that simply connecting everyone in the world would create understanding and harmony. It turns out that’s not true.

Are we really prepared for what comes next?

“We shape our tools and thereafter our tools shape us.” – Marshall McCluhan

The next generation is much more open, more malleable, more plastic. They bring less assumptions, they are more open to what comes next.

There is hope for us yet.


Richard Rutter – 13 Golden Rules of Typography on the Web

Summit 17 Day 1

Richard’s day job is UX designer, but his passion is typography.

In 2006 Oliver Reichenstein wrote that 90% of web design is typography. Why don’t we have better reading experiences? Why does the web have such a same-ness to its typography?

Microsoft’s research showed that while great typography didn’t enhance comprehension, but it did increase engagement.

Good typography induces a good mood!

  1. Learn to relinquish control – the history of print was one of designers having control, but this is not true on the web. The reader can override anything you do. (reference to John Allsopp’s Dao, quoting “The sage accepts the ebb and flow of things”)
  2. Don’t trust computers – don’t trust browser defaults. Use your own judgement. Question what’s there by default, don’t assume it’s solving the problem you have to solve.
  3. Use the default font size for paragraph text – the paragraph is the shortest unit of thought. Your reader should be able to absorb them without interruption. Readability comes from the trio of line spacing, measure and text size. The user will often change this default to something that works for them (photo of someone using a kindle at maximum font size).
  4. Adjust type size according to reading distance – desktops are read from further away than books; and we hold phones even closer. The further the user is from the screen, the larger the text needs to be. Look into 'arc minutes’ for the way this perceived size is measured (http://sizecalc.com). However we have no definite way to measure how far the reader’s eyes are from the screen… so some derived rules: body text – 16px for mobile, 18px for tablets, 22px for large screens.
  5. Adjust the font size if the typeface requires it – typefaces vary signifcantly in x height which changes the perceived text size. Helvetica at 16px will look about the same as Futura at 20px. (good slides about calculating this)
  6. Set tables to be read – tables are neglected, particularly on the web. Tables should be readable and support understanding of the data they contain. Avoid centre aligning text in tables. Left-align text; right-align numbers so the prescision is always the same. Match headings to their data. Sadly HTML4’s character alignment never got supported; CSS4 has a character alignment method which is also languishing. Use whitespace! Don’t bung everything into a full-width, tightly-spaced, zebra-striped, over-coloured nightmare… (full list of tips in slides)
  7. Set text at display sizes, even on small screens – 'display’ sizes are very large. At least three times the size of body text. At that size, readers see the text and react to it before they actually read it. It lets you set the mood. Can you really do this on mobile? Yes! Back to sizecalc… you can find the same perceived size and create the same effect.
  8. Resize display text as you would an image – scale relative to the screen size (eg. using viewport units, you don’t even need media queries). Use vmin to avoid issues with different aspect ratios.
  9. Influence the way people feel through type – create an ambience for your reading. Even if people are not consciously aware of good typography, they are effected by it. Sarah Hyndman spoke at TEDxBedford about typography affecting taste perception of people eating a jelly bean. People looking at round text reported a sweeter taste, while those looking at jagged text reported a sourer taste. Type can affect the senses.
  10. Don’t be reverential, dogmatic or ordinary – don’t opt for inoffensive blandness. Typography is the 'clothes that words wear’ (Beatrice Warde). Do be appropriate – how should your content feel?
  11. Reduce your payload – think about your bandwidth budget. Web fonts are big; but probably smaller than an image or JS framework… but they definitely add up. Ensure you’re using WOFF2, subset very carefully.
  12. Optimise page render timing – Beware the flash of empty pages while fonts load. Use font-display:fallback to display text in fallback fonts while the web font is downloading. You can pre-load a critical font with a link element in the head; although again use with care.
  13. Learn to use variable fonts – this is a new technology that will hugely reduce the size of fonts. They allow huge variation (via a small amount of axes) but any combination of settings can be used as a “named instance” (that is, works as though it was a whole different font).

If you want 168 more guidelines, check out Richard’s book! wbtyp.net

Slides: webtypography.net/talks/summit17


Lauren Lucchese – Designing Conversations

Summit 17 Day 1

How do we build trust with chat-based UI?

Lauren works on the 'conversation design’ team at Capital One, focused on using words to deliver the right message, to the right person, at the right time. To create a natural conversation. A challenge in a big financial institution!

Content IS design.

Lauren’s team uses three pillars:

  1. Is this natural language? Does the language make sense? Is it accessible?
  2. Which use case are you designing for? Where did the person come from, where are they going, what problem are they trying to solve?
  3. Is this content relevant to its context? Are you aware of the implications of the action at hand – eg. if you’re paying a bill, you need to know if there is an impact like a late fee.

The team kicks off new projects using Word docs (“yes… Word docs!”). It helps track changes and enable collaboration (mostly by talking to each other). Then the content of those Word docs is user tested – early, light testing. Only then do they make a real UI.

The beaty of the three pillars is that they are platform-agnostic. Desktop, mobile or conversational interfaces (anything that mimics chatting with a human).

Chat bots need great UX combined with data and UI. None of these pieces alone create a great experience. Get the balance wrong and things will feel wrong.

So how do you get started designing a conversational UI?

When they built the chat bot “Eno” they found it was important to go to the user… meaning SMS! Yes it’s not going away.

Have empathy, think about what people want. Don’t boil the ocean – start with the pieces that drive meaningful value. What concerns do people have? Constantly take on user feedback and learn as you go.

Screenshot of Eno text messages

At Capital One they found the greatest value was to do a few things well, not a lot of things poorly. Fail gracefully when your bot can’t do something – because it’s going to happen a lot, particularly when it’s new! Understand how your customer speaks. Yes, it needs to deal with emoji. Yes, it should respond if you say something nice.

With AI you can make conversations that feel predictive instead of reactive. “You might need to know this right now” instead of “tell me x”.

Design with a character people can connect with.

The sustained appeal of SMS/texting is the connection with the person on the other end. It’s fun and deliberate. You know who’s on the other end. This can make SMS powerful for things like fitness coaches or bots to help people quit smoking. Users of the Lark app 'trust and love’ their coaches!

So why do people respond to characters? eg. Wall-e? When we feel we can relate to something, we feel understood as well. They 'get us’. In life we turn to people who know us the best, who are less likely to judge.

Creating a character for your bot gives you an opportunity to make it more relatable. It’s not a new thing either – it’s anthropomorphism (ascribing human traits to non-human entities).

People get attached to anthropomorphised things. Many soldiers are upset (angry or sad) when their bomb disposal robots are damaged or 'killed’. Not to the point of impacting their ability to do their duty; but they were attached to their bots.

How might we achieve a true connection between our AI and the customer? We can use the natural human tendency to anthropomorphise bots. This helps build trust… but also makes it critical that your bot is predictable and reassuring. People are turned off very quickly when it gets it wrong.

Decide which character traits to explicitly show in interactions; and leave the rest to the user’s imagination. They can fill in the blanks in ways they find comfortable.

It all starts with a back story. Characters have back stories to set the scene, to explain their personality, motivations and responses. What are your bots emotional boundaries? What will stand for and against?

With Eno, they intentionally chose a gender-neutral identity (it’s a bot!) and it responds to questions like 'where do you live’ with honest answers. It does not pretend to be a human, it’s happy to say it’s a bot that lives in the cloud. Its humanity doesn’t come from pretending to be male or female, it comes from its interactions.

Sometimes Eno can be a bit too eager, too keen to be liked. They need to keep improving it.

Eno doesn’t do everything, when it can’t do something it simply tells people who can or where to go to get started.

Eno has boundaries – when to speak or listen, when to ask or tell, when to open or close, when to act or wait. People tend to try to mess with a bot, to see what works. People can be impolite, aggressive, even creepy… it’s important to set a better tone. Kids used to barking “alexa, tell me the weather” need to be reminded not to talk to their parents the same way!

Ethical design matters.

Why are we designing for connection? To instill trust? Do we deserve that trust? Do people feel safe when interacting with your bot?

Use guiding principles:

  1. humanity – demonstrate empathy with appropriate emotion. Use proper grammar even if you accept emoji back, because competency is very important for trust in a bank.
  2. clarity – keep people focused on the important information, put the answer first. Be concise first, playful second (when appropriate).
  3. transparency – be clear about the benefits and limits of interacting with the AI, be up front about where the data goes and how it’s used.

It helps to have a team that is diverse, so they bring different perspectives to the debates required for designing an inclusive AI. Build the strongest, most diverse brains trust you can!

Do watch out for indications that people are liking your bot. They don’t need to say 'thanks’ to a bot. People also often start an interaction by asking how the bot is feeling. It should respond naturally.



Q: How does Eno respond to people who are rude or offensive?
A: They’re constantly exploring ways to deal with it. It currently responds very strongly against sexual harrassment – it will shut down to pure informational transaction, emphasising that it’s not ok.

Q: Is there a limit to how big or long an interaction can get with a bot? eg. completing a full form?
A: There are a lot of limits with SMS, both social and technical. So there is definitely a limit, they try to keep things short; and give the customer short answers like yes/no.

Q: How do you gain empathy, given most people start with a negative attitude to a bank in the first place?
A: This came out of the research that led to creating a chat bot. Creating the character was in part a way to change that overall negativity towards banks.

Kyle Simpson – Keep Betting on JavaScript

Summit 17 Day 1

Kyle begins with a moment to reflect on the privilege we hold; and the cultural problems we have with ideas of meritocracy – ideas over people. That’s bullshit! The people are what matters. Our jobs are to communicate and cooperate with humans. We all started somewhere, we all have different lives, we need to think more about empathy. Think about the person behind the pixels on your screen.


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

This doesn’t mean we have to just go do, do, do. Kyle feels there’s another way to frame things: what direction are we headed? What is our responsibility in the future direction of any given thing we are talking about (including JavaScript)?

Comparison photos of the iterations of Mercury rockets

A brief and incomplete history lesson on American spaceflight… beginning with the Mercury rockets. They could not go directly to fully-crewed space flight. They started with a single person in a tiny survival pod, doing very little; and each mission was designed to test out things they’d need to put together. Then the Gemini project came along, which could fit two people with a greater role to play. Then the Apollo missions came along, starting to do things while in space.

So getting to the moon took lots of baby steps. Lots of iterations. Can we take some inspiration from that, look ahead by a decade to see where things are going; then have the discipline to do the work to get there?

Brendan Eich coined the phrase always bet on JS. Whenever people bet against JS they end up being wrong. Of course that’s not how gambling really works, because in true gambling history means nothing. Your odds never change.

So Kyle says keep betting on JavaScript. The future of JS is not as certain as people might assume.

A quick history of Kyle’s journey. Like many people, he learned about cool tricks on the web by viewing source. This is one of the most fundamental reasons the web (and javascript) have won so far. When we are curious, we can find out how did they do that? There’s no closed wall – you can see the code.

Kyle wanted to know how people did funny tricks like mouse cursor trails. That particular trick wasn’t important, but view source is how he learned. His knowledge took bigger steps forward when he started doing paid work on the web. He eventually built southwest.com, which included the first exposure to a UI framework (YUI)... but right before launch they wanted it to work in Netscape 4! So he had to hack through all kinds of code trying to make things happen.

For a little while he 'cheated’ by using Flash to do stuff. Although Actionscript meant it wasn’t cheating all that much. At one point he used a Flash/JS hybrid to produce an XHR library.

Like everyone else jQuery brought him back; and he looked into the library a lot.

I didn’t even know $ could be a variable name!

But there’s only so far you can get reading other peoples code.

There’s an old joke comparing 'complete Javascript’ books against Javascript: the good parts. The problem with abridged versions of things is that you get the high points and not the full understanding. There were lots of gaps. Kyle wrote You don’t know JS to fill those gaps, largely because he realised the best way to learn was to teach others.

Kyle’s journey has been made up of baby steps.

So, to JavaScript… The first standardised versions of JS came in the late nineties; and the first really complete spec was ES3 in 1999. ES4 never really happened, it was used as ActionScript3 but never as JavaScript. E4X also died, it had a lot of problems.

ES5 came a decade later; and ES6 about five years after that. They had heaps in them, but they were things that people were trying and working on way back in the ES3/ES4 era.

Naming is tough, we have ES6, then ES2016, ES2017… yes the years are correct from 2016, but not before.

Talk recommendation: Dream big, think small @petrosalema #fronteers14 … the idea is that big things happen when people do lots of small things to progress them.

When we say we 'stand on the shoulders of giants’ we acknowledge all the work that has gone before. The best work is incremental.

So the question then – things to bet on?

Bad bets:

  • Things that assumed the web was headed towards sandboxes. Flash, NaCl, Silverlight, etc.
  • App stores. They’ve paid off in the short term, but in future we’ll think of them as a bad idea.

Good bets:

  • JS
  • HTML5
  • CSS3
  • PWA

Open collaboration has beaten closed off silos in the long run. We can look to space and see that the International Space Station was more successful than the competing projects that existed before.

We are a big fork in the road now in space… we have government and private/corporate visions for space travel going in very different directions. For JavaScript, we have a fork in the road… JS about the language; vs JS about the machine.

Small steps mean things look like they’re going in the same direction at first, but at the end the differences become much more obvious.

JavaScript the language: cdshmncmmnctn vs. code is human communication …. we have very different ideas how to write the code. JS is the lingua franca and yet it can be written wildly differently, perhaps partly because it allows multi-paradigm coding.

JS is becoming more declarative – declaring the outcome, not the steps to get there.

Backwards compatibility is a difficult issue for JS. We’d love to break away from old ideas, but JavaScript remains massively backwards-compatible. Yes we have to endure the inconsistency and odd choices from the early days, but old code still runs.

A lot of the current problems with JavaScript are not about the language. Performance, DOM limitations, etc… these are not about the capability of the language. The language itself has a heap of great features and lots of new ones coming that people will be really happy using.

JS has gone a long way from the primitive ten-day version, to the serious language it is now.

JS has been adding features designed more for compilation and frameworks than the average developer. Shared memory, wake and wait… these are features most people are unlikely to use.

Compilers are the new frameworks (Tom Dale). There is an increasing gap between the code we write and the code we serve in the browser. The biggest fork in the road is WebAssembly/WASM. It’s incredibly powerful… but wither view source?

So we have a tale of two JavaScripts: one for the language, one for the machine.

Kyle thinks the future of JavaScript needs to be JavaScript for humans.


Ben Birch & Tim Churchward – Style Guides, So Hot Right Now

Summit 17 Day 1

As Aconex scaled, they found that things that worked for design in the early days just didn’t work any more. Word docs, PDFs of design rules, etc… these were not enough. A retro on a project showed they needed a systematic approach to design.

Devs would spend time building minor variations, because six different teams with different designers weren’t aligned. The placement of primary buttons, simple things like the design of a loading spinner… none of it was aligned.

By 2015 it became almost impossible to onboard new designers. “How do I do a modal?” Well… there’s some info over there… a bit over there…

They tried to unify it with Google Docs, again in Confluence, another in Drupal… but nobody ever kept it up to date. It was essentially useless. They tried a live style guide, although it did end up being one gigantic page documenting everything, but it was not much use for designers.

It showed devs how every possible existing thing worked, but it didn’t say how they should be. Style guides were the hot new thing in 2015. Could it be the thing that sat in the middle between devs and designers?

They figured they needed to convince the business that this was what needed to happen… but then discovered the founders were saying that’s great, why aren’t you doing it already?! So it had the blessing of leadership… it needed a champion.

They use the open source model:

  • Consumers who use it and comment on issues
  • Experienced contributors who create PRs
  • Core developers who merge PRs and manage the project

This applies to design as well. There are custodians of the design, then contributors (designers embedded in teams).

So they built their first pattern library; although they did have issues getting contributions from designers, who couldn’t handle the dev aspects of the doc project. So they use Confluence to research patterns; discuss ideas on Slack; only the actuals go into the library.

Meanwhile devs had issues where they might submit a PR but it might take some time to get things merged. They resolved this by letting each team run its own local set of extensions. Teams can move really fast; but the risk of course is that they can go off on their own design directions. The core library just handles the completely shared stuff. They did try having teams run off forked versions of the library, but that didn’t go well and they came back to versioned modules.

Now when design patterns come up in a team, opportunity to make something better is pushed to Slack for discussion. When the research comes together, there’s a fortnightly check in to talk about them. Ultimately there’s a lot of trust that the designers have made a coherent decision before pushing an idea to development.

Initially they thought they’d just make Bootstrap-for-Aconex, even tried reskinning Bootstrap. But they ended up doing their own library and were really glad they did that. An illustration of that is the icon naming – Bootstrap names according to what the icon looks like, their own library names according to purpose.

When you build your own, you build it specifically for your own company.

They did think they could get to something truly brilliant very fast – thinking of the Apple HCI guide, Lightning, etc. But they found the team dynamics need heaps of work, the deliverables come after that.

The style guide doesn’t just capture how things work, they also need you to figure out great ways for people to work together.

Nicola Rushton – Designing Team Culture

Summit 17 Day 1

Every couple of months Nicola works with a new set of clients – new people, with new ways of working together. They created PostFacto – a tool for running remote retros. It is now used by around 2000 teams worldwide.

A show of hands shows most people are doing retros… but most have been in one that felt like a waste of time.

Nicola remembers her first retro, after a tough full-day scoping workshop. The clients were arguing amongst themselves, there was one person who clearly wanted to derail the project, a key person kept dropping out to take phone calls. After this day-long workshop from hell, someone said “wow…retro?”

They wrote up the usual went well, went wrong and do differently. The group was able to use this technique to figure out how to improve as a group, without blame or worry. It was a little weird to talk about your feelings at work… but it’s also nice to work with a team that can be open with each other.

The teams that communicate openly are the great teams.

There are lots of variations on the retro. postfacto.io is an opinionated version, with “happy”, “wondering” and “sad” columns. The labels may vary but that’s their purpose.

The key in the end is to do this regularly, but ensure there are actions. Things actually need to change as a result of a retro.

It’s based on research digging into both good and bad retros – lots of 1:1 interviews, observation and dogfooding the product. This showed a common set of pitfalls:

  1. The painful, awful retro. Often solved by having them more often (counter-intuitive, but works). Think of retros as scheduled maintenance for your team. Also set expectations, note the prime directive. Beware voting or skipping items – they had a 'cheese’ item that looked like an easy-to-skip thing. But when they asked 'who wrote this one?’, it ultimately showed their habitual retro snack of cheese was making a lactose intolerant team member feel a bit ignored.
  2. People not really sharing the truth. It’s a serious problem when people don’t feel safe to share. things that can help: just invite the direct team; actively work to establish a feeling of safety (be vulnerable, or be the one willing to point out an elephant in the room).
  3. The room is dominated by one or two voices. This needs a strong facilitator, who ensures everyone is heard. Watch for someone who has been talked over or interrupted, particularly if they have since shut down.
  4. Same old problems over and over again. It helps to focus on the action items. Don’t repeatedly discuss a problem without trying solutions. If there are lots of options, do a time-boxed trial. Make sure the items are actually actionable, make sure they are owned by someone specific.

Last tips:

  1. Do retros weekly, don’t skip
  2. Make it a safe space
  3. Have a facilitator
  4. Focus on action items
  5. Be kind


Rona Shaanan – Disruptive Design

Summit 17 Day 1

Rona moved from Tel Aviv to Brisbane about six years ago; and at the same time changed from being a graphic designer to being a UX designer. She thought she’d finally have more influence over projects, rather than being brought in at the end to polish whatever was already decided. But this wasn’t to be.

Rona found herself creating products that weren’t released; user groups that were then removed; did research that was ignored; scolded by managers for trying to change things; even told to stop talking to developers!

She needed to connect all the dots, to bring together the humans, technology and business. Why weren’t people open to hearing business issues from a designer? If users were telling you important things, why ignore it? This was well beyond defining UX patterns, it was part of defining what the product should even be.

She thought she needed a seat at the table, for leaders to listen. Time after time, this failed. She realised design was seen as a threat to traditional business. People who want stability didn’t like the messy process of design.

But companies can’t rest on traditional methods any more. Startups are embracing design as a competitive advantage. Business in general are starting to realise that design is important.

So how might we (designers) change the environment in which we make and deliver products?

Should we? Of course! If we submit to the status quo, design will be reduced to a service provider. People who stick pretty designs into a process but have no control over it. You can run away; but you’re just chasing that perfect unicorn job where everything is perfect… so you should fight. Change is inevitable. Businesses will transform, they can just choose whether to lead or follow.

What change is feasible? Two things need to be true.

  1. the company has to want to make successful products
  2. your organisation has to know they need design to succeed

Transformation is hard – ask big companies trying to do it. It’s hard to sustain the energy. Designers can bring bottom-up change.

What change is required? Companies doing well here have three common qualities:

  1. User-centric (but they need to actually be user-centric, with real data/metrics and not guesses)
  2. Collaborative (holistic problem solving/design thinking)
  3. Efficient (things need to flow, not be too controlled to move)

While Rona has plenty of advice, she really wants to start a conversation. Tell her what you think!


Amélie Lamont – Don’t Kill Them Softly

Amelie Lamont

Today Amélie is talking about feedback.

Act I: What is feedback?

We’re not taught how to give or receive feedback.

Our emotions kick in. We tend to have a really binary approach to feedback – it’s either good or bad. We don’t have a range, we don’t see feedback as a spectrum. We are not emotionally equipped to receive feedback.

Giving and receiving feedback is a skill; and needs to be exercised like a muscle to make it stronger.

Act II: qualities of good feedback

A definition: feedback is reactions to a person’s performance of a task which is used as a basis for improvement.

Effective feedback is constructive. It can help you. It doesn’t break you down, it exists to point out things that you are doing that could be better. The aim is to help you become a better person.

Effective feedback is consistent. Why do some companies wait an entire year to give people feedback? Don’t wait so long. Have something weekly or monthly at least!

Effective feedback is timely. It can’t wait until later, it has to be done in context, when it’s relevant, when people can remember it!

Effective feedback is specific. “That wasn’t good” is too vague.

Effective feedback is cooperative. It needs to be a two-way conversation, looking for a resolution.

Act III: giving feedback


  • What is your intention? Feedback-for-vengeance is no good.
  • Can you ask for permission? Leading with “can I give you some feedback” opens a conversation. It gives people a chance to say no, as well.
  • Are you looking at the person, or their behaviours?
  • Are you being direct and specific?
  • How are you delivering feedback?
  • Don’t make assumptions! There may be some really good reasons for the behaviour you’re seeing. Ask!
  • Are you providing positive and corrective feedback? ('corrective’ is better than 'negative’... you want to correct a behaviour)
  • Is the feedback factual or interpretive? (someone turning up late: the time is factual, “you don’t care about the team” is interpretation)
  • How will this feedback affect the organisation?
  • How will this feedback help the person grow?

For managers:

  • Think of power structures
  • People can’t grow without feedback
  • Be fair, create transparent structure

(improv on stage)

Act IV: receiving feedback

  • Receiving feedback doesn’t have to be scary
  • Be open to the feedback you receive
  • Try your best to listen and do nothing
  • Think of ways to dig deeper and find answers – if you get vague feedback, ask questions, ask for a specific example, understand what’s motivating the feedback.
  • Decide if you want to take the feedback or not. You don’t actually have to take the feedback. Not all feedback is good.
  • Managers – invite feedback from your direct reports.

Act V: crafting a culture of feedback

  • Feedback culture is necessary for feedback. If the environment doesn’t allow it, then it won’t happen.
  • Create boundaries and guidelines
  • Focus on building relationships (bonus tip: do not give feedback to anyone you do not have a good relationship with! particularly your own boss)
  • Create elements of safety and trust
  • Be open to failure, mistakes and change
  • Do your best to assume positive intent
  • Allow people to build each other up, regardless of power structures
  • Don’t feed people negativity sandwiches (good feedback, bad feedback, good feedback)

(more improv, which I will not attempt to describe – go watch the video ;))

Act VI: remaining open

(a poem to finish, again – video! :))


Day Two

Genevieve Bell – Artificial Intelligence: Making a Human Connection

Genevieve Bell

Genevieve is going to try to talk about what an anthropologist would say about AI.

“I’ve had two flat whites and a jam donut, which means I don’t speak any slower than this… keep up!”

Genevieve has spent the last few years closely watching where technology is taking humans. She’s currently at ANU working on the way that engineering needs to be completely changed to cope with the new world.

All the conversation about AI has not been setting us up for understanding it and making sense of it. Genevieve as an anthropologist wants to bring the people and tech together… but how do you do field research with an AI? How do go hang out with an AI?

How does an anthropologist unpack all this?

Went back to the basics – James P Spradley’s book The Ethnographic Interview. Asking descriptive, structural and contrast questions; with the goal of working out how your research subject makes sense of the world.

  • Descriptive – How do they describe who they are and where they’re from, how do they present themselves and describe themselves? How do they make sense of themselves.
  • Structural – How do people do things? How do they find things, shop for things? How do they make sense of things.
  • Contrast – How do people say they are different from someone else? How do Kiwis and Aussies describe the difference? How do people from Melbourne explain why that means they are Not.From.Sydney. How do people differentiate themselves.

So let’s pretend we’re breaking^H^H talking to the John Bot.

What’s your name?

  • How does an AI describe its history and context?
  • AI… even the term is interesting. How long since we used the word 'artificial’ as a good thing? These days we’d say something more like Bespoke Intelligence, perhaps organic, locally-sourced.

Who raised you?

  • AI has a lot of parents! Many had perspectives like psychology and mathematics. Wildly different ideas of how to model the idea of a human. Are they electrical impulses in and out of the brain? Are they a superego?
  • Early cybernetics were kicking off in the 1950s, looking at how humans and machines would interface. While interesting this conversation went into extremely dangerous political territory at the time, it sounded a bit too close to socialism. So to get away from the idea of social and political control, the term 'artificial intelligence’ emerged as something more palatable.
  • So AI has a lot of geopolitical influences in its upbringing. It’s not just who was involved, it’s who was written out of the record (like Turing, who was being persecuted for being gay).
  • Where the money came from is also significant.

illustration of a mechanical duck that could waddle, eat and poop

Where did you come from?

  • We’ve been thinking about bringing machines to life for a very long time. Not just machines, but think of Frankenstein’s monster – brought to life by electricity.
  • So making mechanical things look real has a very long history. AI has ancestors and heritage.
  • Most of our stories of artificial life go badly – think of Terminator, Blade Runner… they all end in tears (in rain). Aasimov at least suggested some laws of robotics to give us a chance of things going well.

What do you do every day?

  • We all have our daily rituals. Things we do every morning; then things we do on unsual days like going to a conference. We will all have used AI today already, even just because we caught a train or bus that uses systems backed by algorithms (the building blocks of AI).
  • AIs are trained with incomplete data about things that have already happened. They are trained by the past, then influence the future by presenting new data to humans.
  • What are your dreams? (it’s hard to ask an AI what it isn’t since it is based on an incomplete dataset of events in the past)
  • Can an AI truly create? Can we have an AI artist?
  • Note the term marked vs unmarked categories. eg. why the “Test Team” is the mens’ team, and the “Women’s Test Team” has to be specified.
  • AIs have issues with unmarked categories; they have problems with extrapolation. Cars that can avoid elk on the road can avoid other four-legged animals, but they run straight into kangaroos because they just don’t move the same way.

@feraldata rocking #wds17

A post shared by Ben Buchanan (@200ok) on

AI stories matter. The way we talk and think about AI changes how we deal with them… consider the linguistic slip of “self-driving car” – we give the car a self. An identity. That’s different from a car with “driver assist” or “autopilot”.

How do we remember to ask more questions about AI and what we’re doing with them? The AI behind our social feeds presents a version of the world we probably wouldn’t choose. Yet we allow them to shape our lives. Very few AIs or algorithms are being created with the user’s best interests at heart, they are created to maximise profit.

slide from the World Economic Forum showing steam power to electricity to computer/automation to cyber physical systems

There’s a lot of talk about the '4th wave of industrialisation’. The problem with that is that although accurate it isn’t including human history from the same period.

When engineering appeared as a discipline, it was a radical intervention. It was a way to give structure to a chaotic world. The school of engineering that appeared in France was a response to a lack of structure – the king was dead, religion was losing dominance. Science was a way to give order to the world.

So we can give AI a back story. What about its future?

The next big thing is most likely managing data – the mana on which all AI is built. Although the challenge isn’t really about literally managing the data, it’s the technical systems that are emergent on top of it. There are many things currently considered individual pieces – eg. IoT, machine learning, deep learning – that will eventually become a coherent system.

Genevieve said “I think we need to build the next applied science.” which is how she ended up at the ANU. “Be careful what you say you’ll do, because someone might say 'great! get on with it’.”

Three questions based on Autonomy, Agency, Assurance. These are loaded words! We live in a world where not everyone has as much autonomy as everyone else. We have difficulties thinking of something that serves us (robot is from 'robota’ meaning serf) having autonomy. We have trouble determining acceptable limits and ranges of autonomy (assuming there even are any).

Genevieve is setting out to create this new applied science. She’s given herself five years. She’s busy and she’s hiring!

For more, check out the 2017 Boyer Lectures and her interview in the Next Billion Seconds podcast.


Jina Anne – Design systems are for people

Summit 17 Day 2

Recently Jina watched The Founder, a biographical drama… and she noticed parallels with the story and her work in design systems. In the movie, the Michael Keaton character Ray uses the chicken and egg argument to sell a new machine to restaurants. The parallel is people who can’t see the value in a design system, because they’re so busy slogging along doing things the slow way.

In the movie, Ray meets the founders of McDonalds; who had a revolutionary streamlined way to run a restaurant down to its minimum requirements, and the 'speedy’ system of delivering food very fast. They rehearse the flow of a kitchen by chalking it out and testing it.

Link: airbnb.design/the-way-we-build

You can’t innovate on products without innovating on the way you build them.

Design manuals have had a resurgence recently, even as collector’s items (eg. NYC Transit Authority design manual!). The NYCTC design manual includes usability concerns like only giving information to people right at the point of decision, avoiding repetition or information overload.

A lot of people are creating design systems at the moment. These are the modern software evolution of the old design manuals.

We want design systems to help us grow our products; and that’s often the measure of success. Quality of the product, speed to market, efficiency of maintenance. But the ultimate purpose is to make things for people.

We talk about design langauges, which is a way to share language, share terminology, and help people work together to build things for customers.

With the Lightning design system there were guiding principles, but to help make decisions they were ranked. So when tough decisions come up there is an extra layer to help move forward. The idea is to avoid delaying decisions, because delaying decisions makes them more expensive.

When creating a design system, you need to consider the various users. Do internal users feel able to contribute and use it? Does this cross role boundaries?

True collaboration isn’t throwing designs over the wall. – Diana Mounter

The new buzzwords are Design System Ops and DesignOps. Not entirely agreed terms, some treat them interchangeably… the terminology doesn’t really matter.

Link: Introducing design systems ops

DesignOps has a broad view including hiring, onboarding, workflows, as well as the more obvious things like design tools and UI kits. The definition doesn’t matter, in the end it’s whatever works for your team.

We can’t lose empathy. No one tool or approach has to 'win’. We need people to feel they belong, to feel welcome, not to stomp on their shiny new ideas and tools.

A common objection is that design systems limit creativity. They really don’t. A great demo at a conference recently was four jazz musicians playing together without any rehearsal – they were able to draw on the underlying patterns that work in jazz. It enabled them to create something great, it was a help and not a hindrance.

How can we make the community better, help the world become a better place? Be open, honest, inclusive. Get involved!

publication.design.systems | news.design.systems | sfdsc.co


Chris Eppstein – On CSS Architectures, Frameworks and Tooling

Chris Eppstein

The cascade is dead! Long live style sheets!

...well you have to start with something controversial. There are a lot of strong opinions about this; and presentations about doing CSS at scale are about managing the cascade.

Why do people like CSS-in-JS? Common themes are…

  • not needing to worry about naming
  • not having to deal with the cascade
  • having all your code in one place

At LinkedIn they had some problems with CSS – heavy amounts of bloat (an SPA that had 3.2meg of CSS), specificity was out of control, designs didn’t meet the design system.

They also had a lot of constraints – dozens of apps across lots of platforms (old systems need pure CSS deliverables), needed to put the priority on performance, needed to support Ember apps (which has no CSS-in-JS solution; “..I mean I guess we could make one..”).

They set a lot of goals – including server-side rendering, enabling designers, making a great dev experience…

Concerns with CSS-in-JS (Chris Has Opinions!)

  • less approachable to designers
  • CSS-in-JS (theoretically) worse for performance
  • Atomic CSS and other declaration-oriented systems create high-perf garbage (the styles are too terse to read, you can’t easily extend or abstract)
  • BEM is awful

The plan

  • component-oriented selectors
  • build a better BEM
  • optimise shared declarations into shared rules
  • use build-time code transforms for optimisation
  • generate code split styles
  • uglify CSS idents for maximum gzip efficiency

GZIP efficiency is impacted a surprising amount by the identifiers we use. CSS-in-JS hashes are particularly bad for this as they defeat compression.

The problem with optimising CSS by mergine rules is that it messes with the cascade, by reordering declarations. The problem then is you need to know what the components are doing before some optimisation decisions can be made.

So they made CSS Blocks and an optimiser called OptiCSS (that reads the HTML and CSS and optimises it accordingly).

Seems too good to be true? Does it handle dynamic changes, what’s the overhead, is it hard to use, etc?

So what’s a block? A collection of related design elements and their various modes and interaction states. This is the same as the B in BEM.

Every block is in its own stylesheet; classes and states are differentiated as nouns/adjectives respectively. There is a block root (root element), block state, class (child element) and class state.

(demos – these had very high detail that was too much to reproduce, see slides)

Slides: The Cascade is Dead | css-blocks.com


Simon Wright – Designing Better Coffee

The story of Brew Crew starts in Tonsai, a great climbing destination. A couple of friends talking over beers and food, thinking about the idea of coffee subscriptions. Simon’s friend Ruben had just started Sample coffee and wanted to share coffee with a bigger audience.

They now send out a box with coffee and a card about the coffee, either fortnightly or monthly. They learned three big things in the process of getting to this stage:

  1. Embrace what makes you… you
  2. Start small, learn quickly
  3. Leave things better than you found them

Ruben wanted to sell online so Simon helped set it up, with a quick Bigcommerce store. But online stores make a lot of assumptions about what you’re selling.

Coffee is a perishable good. Ruben roasts a small amount every week, once it’s sold it’s gone. The web store looked broken most of the time.

Also online stores just don’t do subscriptions very well: you do things like set a zero price, with modifiers in the options… you have to ask people to trust you. Or you do a recurring shopping cart, where you have to come back and buy again every month.

Meanwhile, Sample didn’t have any space at the cafe to set up a subscription service. Their hours were no good for courier pickups. They needed to expand.

They are not an online store, so they embraced what they are. Ruben’s a coffee expert, Simon’s a design and web expert. Design is all about customers… and so is a coffee shop.

So they had a second go at the system. Ruben rented a warehouse and cafe space; Simon started building a custom application.

They had three principles:

  1. Subscription only (no adhoc sales)
  2. Don’t over promise, just say what you do
  3. Sell the coffee experience

So the second round created a very simple, very focused website.

I’m legally obliged to include this at a tech conference… and the 'no nothing’ is too good to correct!

Simon ran into all the things he didn’t know. In his case – print. He’d never done print. He figured he had to learn InDesign…and we can just put that in Dropbox and the guys will print it. What could go wrong?

Turns out it was hard… Now they just do this via the web with print CSS. No need for InDesign, anyone with a browser can print a label.

They were trying to make a personalised experience, like the experience of turning up in the coffee shop. Your name is on the postcard, the sticker used to seal the box gets personalised messages. Since this is all done in the browser as well, the guys packing the boxes can add things whenever they want.

Summit 17 Day 2

Then Simon decided to write a full custom application in Ruby On Rails. This did slow things down…

But they started simple. One question: how much coffee do you want? Then they added another question about whether you drink your coffee black or with milk? This is the same way people talk in the cafe. Then keep going… add options as they make sense and people want them.

It’s a lot like doing design sprints. Do a trial, even if it’s a bit manual at first or just a really simple solution. People kept asking when their coffee was coming, so they let people subscribe to a calendar. Very simple, solved the problem.

As they add more options, the impact on the team is big – the combination of options multiplies fast; and people packing boxes have to do all of it.

Bringing us to boxes. It’s critical to a delivery business. Their first box purchase wasn’t so great, they were annoying and had to be taped shut… and after a few hours of peeling tape noise, you go crazy.

Weird limitations: why is the upper subscription 420g? It’s the maximum amount of beans that wouldn’t tip the entire package over 500g, which is a lot more expensive to send. Sometimes they’d have to trim the boxes manually just to remove weight.

So they started making their own boxes. It’s easier to work with, looks great, has lots of brewing tips and other information in the box. There’s also a map showing where the coffee comes from. The new box didn’t need to be sealed with tape.

The third concept, leave things better than you found them… (idea stolen from Kris Howard)... Simon approaches this three ways:

  1. for the team
  2. for partners
  3. for the planet

Most of the team deals with the coffee, it’s just Simon sitting in an office. Turns out baristas are really nerdy! They measure everything in amazingly detailed ways. They come up with thousands of ways to make aeropress. They test water and survey which titration kit people used to do it.

Simon got the team into using Slack, which was initially just for notifications to go to Simon. But it became the way the cafes communicated with each other, as well. There’s an IFTTT feed that reposts instagram posts from the cafe into the Slack channel.

Partners… for Sample this includes farmers, who grow the coffee mostly on microlots – often on the sides of mountains. Our entire image of 'farms’ doesn’t apply. To pick coffee cherries that are consistently ripe, the farmers have to pick in multiple sweeps through their trees. It’s a lot of work but it produces the best coffee, so it’s fair to give a good price.

The Sample crew were already paying specialty coffee prices, but what more could they do?


  • Tom’s one-for-one – buy a pair of shoes, a pair of new shoes is given to a child in need.
  • Thankyou – they sell a range of products and give to product-relevant charities.

Sample think about giving by working together, which is where the Coffee For Good concept came from, where a percentage of the price is given to charity. (Coffee For Good was originally going to be called Better Coffee, hence the talk title!)

Better for the planet… they’ve always had a 'no satchels unless we have no choice’ rule. Post satchels are cheap, strong and weatherproof; but they are single use and usually not recyclable. Even when technically recyclable, very few places can do the recycling. Which is why Sample ended up using boxes. But at first they had to use sticky tape, so they got rid of that. But the actual coffee bag still isn’t recyclable or compostable; so now they’re experimenting with a paper envelope and compostable plastic liner. Sample work with local suppliers to cut down on transport and travel.

So that’s the idea:

  1. Embrace what makes you… you
  2. Start small, learn quickly
  3. Leave things better than you found them



Sarah Pulis – Designing for extremes

Summit 17 Day 2

Who is an 'ordinary’ Australian? The term is often abused by politicians, but the ABC crunched the numbers and found the ten “average characteristics”:

You speak only English at home
You were born in Australia
Your parents were born in Australia
You’re Christian
Your family has English ancestry
You’re in a registered marriage
You live with your spouse and two children
Your home is a free-standing, three-bedroom house, which you own with a mortgage
You have two cars
Your family income is $2,000–$2,999 a week (or $104,000–$129,999 a year) – Source

But in reality, almost nobody actually meets all of these criteria.

Nobody is 'normal’. There is no such thing as average or ordinary.

The American airforce discovered no pilot actually met the dimensions the cockpits had been built for, which was a supposed 'average’. By designing for average, they’d designed for nobody. The solution was adjustable seats, technology which we see in all modern cars.

Two things we should take from this:

  1. As individuals we are all different
  2. As designers, our products should support diversity and adaptability

Things organisations should embrace:

  1. Awareness
  2. Culture
  3. Innovation

In Australia the government’s requirement to meet accessibility standards raised awareness across the private sector as well as government. However the push for a11y didn’t really stick, the culture didn’t change. People had followed a checkbox compliance approach and not really got to the core values and systems to make it a permanent change. Some changes to approach – innovation – is required. We are missing opportunities by treating accessibility as an 'access checklist’.

We need to change our thinking to designing for extremes to the benefit of all.

The Microsoft inclusive design kit points out accessibility is not a small market. 26k people have a permanent disability like one arm; but then 13m people have a temporary disability like a broken arm; and another 8m have a situational disability because they are holding a new baby in one arm and doing everything with their other arm. So it’s 21,000,000 not 26,000.

We can also think of diversity and inclusion as being an iceberg – if we don’t look below the surface we simply won’t see most of the impact.

Things we can do:

  1. Diversity in research – recruit more broadly
  2. Use inclusive design principles – build for as many people as possible
  3. Diversity in testing – move away from checklist compliance to accessibility as part of usability

Last thought: extreme becomes normal.

Instead of seeing people as extremes, we should see them as normal. We are all different and we should embrace that difference in ourselves and others.


Dan Rubin – A life on the Web

Dan Rubin

Dan wasn’t sure what he could really talk about at WDS, given the broad range of things he’s been doing. But it became clear that the story itself was worth telling.

Dan’s been online for a long time. It starts in 1990-92. Dan was homeschooled and didn’t have access to computers until he was 12; and a neighbour gave them a Mac Classic. He also ended up with access to the internet at 14, thanks to a neighbour with an ISDN line (which was an incredibly-unusual high-speed connection at the time). It became a natural part of existence – the natural curiosity of the age plus the opportunity to look for things.

Then in 1994 he got access at home with a blazing fast 14.4k modem. (massive nostalgia hit as Dan plays the 56k modem connection sound) Suddenly he leapfrogged his mainstream-schooled peers. He had greater access to technology and information than they did. 'The world seemed both larger and smaller.’

In 1995 he got a job working at a museum that was getting online. He was asked to build an interactive exhibition and said yes, despite not really knowing how to do it. He quickly learned about interaction design using Macromedia Director. It was probably the second online exhibition in America.

1998-2011 he kept working as a contractor; and worked with a lot of big clients. He was also doing lots of other things but he kept learning more about the web. He ended up being the creative director of moo.com for a year, which gave him his first opportunity to work inside a company.

Screenshot of the blog post by Jason Santa Maria

In the middle of that period, 2008, something important happened. Jason Santa Maria was doing art-directed blog posts, which was as unusual then as now. He put a post up about the Polaroid SX-70. Dan bought one on ebay, with a couple of packs of film. When he started shooting, he produced photos he actually liked. All previous photos had been absolutely terrible. He started liking his photography. It also rekindled an interest in physical product design.

By 2010 his photography hobby had taken off, to the point that people were coming to him for advice. He was running photowalks at SXSW.

Someone tweeted an icon of an app that looked like a polaroid; and said they were playing with something cool. So two months before it opened up, he found himself invited to use the beta of Instagram. That quickly turned into being one of the most-followed photographers on Instagram.

So he was able to transition incredibly rapidly to professional photography; and his experience with design helped build an impressive client list.

This got him to thinking… what portable skills do we have that we’ve never explored?

When we are young we all have varied interests. We are exposed to more things, we explore more things, we think about what we want to be when we grow up. Very few people are doing what they dreamed of doing when they were a child.

Dan had a lot of interests when he was young and perhaps explored more than his mainstream-schooled peers. It was normal to be curious, to ask to go to the library.

At some point as we grow up, the concept of focus is introduced. To be a 'successful adult’ you need to pick one thing and just do that one thing. Maybe forever. That’s what you’ve got to do. Particularly starts when you start heading to university.

So we pare down our interests and pick A Thing™. If we are very lucky we get to work on a thing we love.

We forget about the possibilities.

Dan wanted to get back to the possibilities. He decided to have an experimental year, to explore and not chase paying work. He’d decided it was holding him back to focus attention looking for paid work. It took trust that people would come and ask. But he hadn’t had an experience for years where he’d been asked to do something he didn’t know how to do.

Many people refer to having side projects. Dan decided to focus on those projects. The balance in question was income vs interest. He’d focus where he was interested, not where the money was.

'Happy accidents’ have become the norm. Things coming from connections built on the web.

  • Koya Bound – had wanted to design a book for years; and finally did it working with Craig Mod. They’d met at Web Directions a few years earlier. Craig invited him to go hiking in Japan; and everyone going on the hike was a keen photographer. The idea became do the hike, then see how fast the book could be produced. They ended up doing it via Kickstarter.
  • Emily Denton – Dan had found clips of her music and followed her on Twitter. She happened to tweet about working on getting used to being in front of the camera; right when Dan was looking for more portrait work. So they did a shoot. Through a series of unusual events, she ditched her producer and Dan ended up having a look at the recordings. He became her producer. They needed a film clip so he brought in people to do this and became the video producer too. So it became a huge journey working together… all from following on twitter.
  • Moment – Dan had been teaching workshops; and this led to helping them build a new business.
  • Camera & Phone Straps – working with a leather maker to create beatiful little camera straps. It’s a small scale project, but heaps of fun and leads to other things.
  • Hiut Denim – they run the Do lectures in a field in Wales, as well as making jeans. He got to know the owner of the company, they found out Dan has a design background… now they’re collaborating to make a pair of jeans.

Once people know you do a thing, they start asking for it. Other people are asking Dan to design books now. They’ll probably start asking him to produce music too. Amazing things happen because Dan started conversations and said 'yes’ to things.

This all came from an intentional decision to go back to being driven by interest, tapping into a mindset of curiosity more like we had as kids.

One last thought that came out of Dan’s chats to John Allsopp… The importance of being human in a world increasingly dominated by tech. An overlooked common element is often you. You are the thing that connects otherwise-unrelated things, other interests. You are the connection.

Ref: David Lee Ted Talk – Why jobs of the future won’t feel like work

David Lee’s talk talks about getting people to work on things they’re inspired to do.

When you can bring your Saturday self on Wednesdays, you’ll look forward to Mondays More. – David Lee

We are now in a world that connects us to our interests; and to other people that share them.

If you can connect the dots between your interests, it can help you explore and lead to opportunities you wouldn’t find otherwise. The most exciting discoveries happen in the overlaps, the unexpected intersections between things.

Explore the intersections.


Photo walk

After conference close a group gathered for a photowalk from the venue to a chilled out pub destination in Erskineville. Photowalks are as simple as they sound: you walk, you talk, you take photos. Each person's style means they will take a different photo even when standing right next to someone else. Some take portraits, some focus on shadows, industrial artefacts, street art or cats. That's the joy of photo walks!

#wds17 #photowalk with @danrubin 2/4

A post shared by John McClumpha (@johnmcclumpha) on

@danrubin in action. #wds17 photo walk. #nofilter #sydney #sydneyafternoonphoto #goldenhour

A post shared by Ben Buchanan (@200ok) on