Content strategy meets design system

Feb 10 was a joint meet-up between Sydney Content Strategy and the Design Systems meetups. The speakers were:

  • Tony Starr, Content Design Manager for the Atlassian Cloud Platform and Product Content Standards;
  • Steven Berends, formally at the DTA and currently founder of Bear Lion Bird and on assignment at the Australian Trade and Investment Commission.

Both speakers outlined projects and the underlying principles where content has evolved alongside and within design systems. Anthony Starr titled his talk “Strive for 73% content in your design system”. This was not about content playing second fiddle and both talks showed that mature product and service design teams are merging design systems and content strategy.

So what’s in a system?

  • Pattern libraries and style guides but keep these short, usable, and readable
  • Style and grammar: voice and tone, mechanics, glossaries
  • Resources for writing user-facing documentation, emails, in product help, and other content
  • Examples of best practice

The problem that content strategy and content design systems are solving for:

  • The friction caused by inconsistency across ecosystem of websites and services
  • Creating consistency throughout the user journey
  • Capturing institutional knowledge

As always

  • Start with user needs, meet the user story


  • Identify indicators as well as measures – e.g. 0 searches on pages can infer unmet needs


  • Consider a content style council to manage decisions. The metaphor of a tree was used to show this system of decisions
  • Root decisions
    • Terminology
    • Voice and tone
    • Brand guidelines
    • Messaging (think microcopy of interactions)
    • Organisational styles
  • Trunk decisions
    • Glossary
    • Product terminology
    • In-product experiences
    • ‘Spicy’ style and grammar choices
  • Branch decisions
    • Content patterns
  • Leaf decisions:
    • Product guidelines
    • Standards and style choices

Form communities of practice, be visible to embed use:

  • Team up with Brand to increase ‘capacity through the system’
  • Allow uniqueness, and
    • incorporate new patterns into the system
    • also ask that people document why they have created a new pattern
  • Keep agile practice, interaction design, and developers close
  • Socialise wherever and whenever possible. Examples included:
    • Through project delivery
    • laying the groundwork with stakeholders
    • being visible in Slack/social channels
    • speaking at in house events
    • attending team and project brainstorm sessions
    • considering a service design to support the design and content system

Thanks as always to Elle Geraghty for organising an amazing free community event. For more info on future meetups by these organisers go to: and

If you want to learn more another write-up of the meetup was captured by Mattia Fregola at and a video of one of the talks is available at


This slideshow requires JavaScript.


“It’s much better to be a learn-it-all than a know-it-all” Steve Vamos

“I think design thinking and agile which are big trends in business today are a reflection of the fact that if you are building anything without customer feedback today you are deluded”

“Mistakes are learning. You cannot innovate, create and progress without mistakes”

HT to my friend Pauline Lucas for sharing this with me.

The Work Experience

Agile teams thread.

Agile or not, lots to reflect on and love in this thread on agile teams (threadreaderapp) by Susanne Husebo. It start likes this:

  • They start their daily standups on time.
  • They tend to laugh a lot and have fun.
  • Everybody in the team gets to express themselves.
  • They correct and edit each other when they go off track.
  • They try out new things with appetite. But they are quite willing to admit those things didn’t succeed.
  • They often don’t care very much if it looks like they’re working hard.

and gets better and better. See the original tweet here.

Design Events

What’s love got to do with MVPs?

At this Sydney Agile Business Analysts & Product Owners meetup Erwin van der Koogh set about educating and dispelling some myths about the emerging and illusive term — the Minimum Viable Product, or MVP.

So what isn’t an MVP?

  • It’s not what can be built before the deadline
  • It’s not what is possible for a given budget
  • It’s not the first version that is going to be delivered
  • It’s not the least you can get away with.

It is a product, whether built or prototyped or simulated that is designed to get a market signal to test. Erwin related the MVP concept back to Kano model theory making the point that an MVP should not be the “minimum” product that you can get away with — as that would only elicit an “indifferent” response.  This might sound pithy in a blog post, but if you learn about these concepts MVP does then rise as a term that is about building products customers will love, rather than a production term wholly associated with being lean and agile. Erwin adapted a couple of Eric Reiss quotes to make the point that an MVP should be that slice of end-to-end functionality that you can get away with, that also behaves and performs as users expect. Or to bring the love into it

A minimum viable product is that version of a product which allows a team to collect a maximum amount of validated learning about true love [sic] with the least effort

Some examples further illustrated the point.

  • Dropbox was not the first file sharing service but it was the first that allowed synching to a desktop drive. To test the product a video was made that pretended that the product did in fact already exist to test whether anyone would use it and buy it. The Dropbox video MVP attracted 50,000 sign-ups in 48 hours.
  • Zappos, the first online show retailer needed to prove that customers would buy shoes online. The team went to a shoe store, bought a shoe, took a photograph which they posted online. Someone did buy it and while they lost money on their first sale they did prove that customers would buy shoes off the internet.
  • Intuit, wanting to help fight poverty in India had a hypothesis that fisherman with access to real time price information would be able to better manage and plan their business. This team created paper prototypes that people signed up to. Behind the scenes someone manually entered and texted market prices to the tens of people who signed up, and elsewhere in the simulation a couple of people pretended to be an IVR and quickly iterated scripts before the service was built.

In the discussion I asked whether or not minimum viable experience would be a better term, and the phrase minimum viable experiment was explored. Theory around the experience economy and the Cynefin framework was explained and again Eric Reiss was adapted with a bit of folly …

A start-up is a human institution designed to find true love [sic]  under conditions of extreme uncertainty.

And while this theory is a lot to get one’s head around it makes sense. MVP as both product and research approach is designed for operating environments of extreme uncertainty, and for creating products for an experience economy. I.e. product research that can be experienced by customers in real market conditions.

Attendees asked what the difference was between a MVP and a prototype with the answer that while a lot of MVPs are prototypes, not all prototypes are MVPs. This makes sense if an MVP is a product designed to test for a market signal, rather than other research objectives often associated with concept and usability testing.

The talk finished by encouraging Business Analysts to switch their mindset from a “solution finder” to a “problem understander”. Music to the ears of this designer.

Check out all of Erwin van der Koogh’s slides from this talk on Slideshare

MVP, You keep using that word. I don’t think it means what you think it does from Erwin van der Koogh
Design Events

Meetup wrap up: Product Roadmaps, what are they good for? at Product Talks

I’ve not yet been responsible for a roadmap but I have certainly fed information into them, so I was very keen to check out yesterday’s meetup and hear from a panel who disagreed and agreed on the merit and use or uselessness of product roadmaps. The panellists were

  • Michael Pearson, Director Product & e-commerce at Expedia
  • Michael Bromley, Head of Digital Strategy and Chief Innovation Officer at SMS Management & Technology; and
  • Chrissie Zenonos, Head of Product at Mi9 (Channel 9)

While the panelists weren’t in perfect alignment they generally agreed on the following.

What is a product roadmap?

  • A communication tool
  • A list of priorities

What should a product roadmap communicate?

  • Needs, problems
  • Goals and objectives
  • The business value to be delivered
  • The vision
  • The capability

How should a product roadmap behave?

  • It should be flexible
  • It should accommodate a test and learn approach

What value do product roadmaps provide?

  • Provide visibility to different teams to enable them to align to a singular vision
  • Show how everything fits into a greater scheme, to provide context
  • Provide clarity to tackle ambiguity

What a product roadmap is not, or should not be or do

  • Should not be a features list
  • Should not describe granular detail
  • Should not explain how something is to be delivered

The aversion to product roadmaps was best expressed by Michael Bromley:

“Because I can’t predict the future I don’t try.”

And with technology and the market changing so rapidly its easy to see why people need to work in differently. What the panelists had in common was a way of working which was flexible, agile, and iterative, applying a test and learn approach. From what I could gather Michael Bromley, of SMS and Chrissie Zenonos of Mi9 could do away with the traditional concept of a product roadmap deliverable because they worked with co-located teams. They used walls of post-its and the business model canvas as alternative tools. Michael Pearson of Expedia, unlike the others was still an advocate for product roadmaps. He works with distributed teams of developers and needs to communicate the wider context and timelines to engineers and call centre channel teams who need to know when a feature will drop. His version of a product roadmap is a JIRA workflow where the hypothesis to test eventually becomes the code then the feature.

My big takeaway was realising that so much documentation—product roadmaps, feature lists, test schedules, project plans, even the business case—are really communicating the same thing. The challenge is rationalising tools that so many feel so comfortable with to avoid duplication, focus on communicating the vision, and work iteratively and flexibly towards achieving it.

Product Talks is a meetup organised and hosted by Brainmates for Product Managers. Their next topic “Is UX a Part of Product Management” will be on 9 June.


WebDU 2012

It’s been a few years since my last webDU so this year’s conference was a reunion of sorts with familiar faces, friends and dear old colleagues. I should point out that as a daemonite alumni I was a guest, so yes I am biased and I do think this conference is awesome. The staging was great, the food better and the speakers stellar. Did I mention there was ice-cream?

There is no point in me sharing the 16 pages of notes I took over he 2 days—that would be a pretty tedious conference review. So, what I thought I would do is share the reasons you might want to follow up on the session slide deck and speaker profile. So here goes …

Terry Ryan from Adobe evangelising device testing then showing us Shadow

Terry Ryan, Adobe, Keynote Day 1 and Semantic HTML
Reason to click

Shane Morris on Microsoft’s Metro design language
Reason to click

John Bristowe – Make awesome web
Reason to click

Alex Danila (Google) – on the new shiny of HTML 5
Reason to click

  • Updates on new attributes and native applications of HTML 5: camera, microphone and more.
  • <canvas>

Mia Horrigan – The unsubscribed: designing for conversion
Reason to click

Dale Rankine – Mr Spock! Consumerise the enterprise
Reason to click

Marcus Shappi– the internet of things
Reason to click

Matthew Hodgson – The trouble with time travel
Reason to click

  • Case studies on two different agile project frameworks and the lessons learned in using them to create collaboration between UXers and developers.
  • Follow up for user workshop/design research  ideas.
  • Slidedeck

Of course, the above is just my view of the conference. I’m not a developer so if you want to follow up on the techier talks check out the the webDU site. I also have neglected to divulge the hilarity of Dmitry Baranovskiy’s you’re just not doing it right JavaScript comments on the speaker round table and the inspirational and thoughtful Colin James day 2 keynote. That deserves a blog post all to itself.

Until next year.