Directing creatively

I love what I do. That said I always feel a little uneasy telling people that I’m a creative director. To the average person, this tends to conjure up images of Mad Men’s Don Draper delivering an amazing pitch (seemingly out of thin air) before retiring to his office for tumbler of Canadian Club.


The reality is somewhat less glamorous. . . and sans whiskey.

Steps for creating that awesome thing.

Throughout my career, I have worn a good number of hats – business owner, graphic designer, web designer, front end developer and UX designer. This experience is crucial. It allows you to step back and see a project in a more holistic way. Being able to empathise with your team really allows you to work effectively and closely with them to create something awesome.


  1. Absorb

A lot of my time is spent absorbing. Whether it be listening to clients requirements, scouring the internet for innovative new trends or UI patterns, or even listening to my co-mates random stories. Inspiration can come from anywhere. It doesn’t even have to come from the digital space. Take, for example, a material design system by Google that’s inspired by paper and other physical materials.

“Material design: A material metaphor is the unifying theory of a rationalized space and a system of motion. The material is grounded in tactile reality, inspired by the study of paper and ink, yet technologically advanced and open to imagination and magic.”


  1. Get excited

I get excited by new ideas and new ways of solving problems. You can have the fanciest product using bleeding edge technology, but unless it really solves the problem, it’s ultimately useless. I understand that I don’t have all the answers which is why it is so important to listen. Listen in those early client meetings when they are outlining their vision or problem. Listen to the customers who are going to be be using your product. And, most importantly, listen to your skilled team around you. If you try to go at it alone, you will fail.



  1. Value consistency

Keeping consistency within software is a challenge. Consistency of both visual and function elements is a key part to creating a unified and intuitive experience for the user. You can create  a heap of detailed wireframes and functional mockups to explain the interface or process, but ultimately there will always be new functionality that gets slipped in on the fly, or something about your approach may simply not work as you thought.  


  1. Learn to let go

Throughout the development process, you won’t always be available to make calls on every little detail.  It’s imperative you create a design system that allows for autonomy. Julia Hide recently wrote a post about living style guides and her journey into creating the most practical way of designing and maintaining a style guide. This has by far been the best weapon in the fight for consistency. It has given the development team a scaffolding. When a new undesigned feature needs building, they don’t have to think about how it will to look. It may not be perfect, but it will be consistent. There is always an opportunity to revisit it in the future.


  1. Lighten up!

You can’t take yourself too seriously. You’re going to be wrong, a lot. What’s important though, is being able to identify when you are wrong. Try not to be pig headed about your vision. But, you also need to back yourself when you genuinely feel that your vision is the best way.

It’s like being a parent. You come to the table bringing experience, of both success and failure. You’re there to guide your team to nurture the good ideas and redirect the bad. Trust your team. It’s so important to trust that those around you are going to have good ideas. There is nothing more crushing to creativity than feeling like your ideas are always going to be shot down.

Being able to take all those ideas and collate them into a cohesive vision that is true to the brand and solves the problem is the key to success.

I love what I do. I enjoy inspiring creativity in those around me and love the fact that I get to come to work everyday to create new and exciting things. These steps are by no means fool-proof, but creativity has never been a precise art.

If all else fails, there’s always Canadian Club before noon.



Climbing Nerd Mountain

I joined Media Suite earlier this year, fresh from five years as a journalist, mostly working the lifestyle department writing about avocados and the Kardashians.

This is a Kardashian.

I graduated in Philosophy, Political Science and Journalism. Needless to say, my knowledge of web development was pretty limited. In fact, it was almost non-existent.

I was hired as the Client Services Guru, a role which encompasses everything from liaising with our clients to organising Christmas party and delegating work tasks around the team – and anything else required (which is quite a long list!). Every day is different.

Mostly, not understanding stuff.

My first day here was a baptism by fire. Acronyms flew around the room so quickly I found myself frantically writing a list of those I didn’t understand (all of them). I was given a crash course in about 10 different softwares to complete tasks I barely comprehended and people kept saying “front end” and “back end”.

I turned to Google for help.

“What is the difference between a domain and an IP address?”

“How does email actually work?”

“What is JavaScript?” …. “Are JavaScript and Java two different things?”

“What is a back end?” (FYI, Google dictionary’s first answer is this: “the end of something which is furthest from the front or the working end”. Super helpful Google, thanks!)

The power of Google

Despite the shortfall on the front end/back end conundrum, Google kind of became my workplace sidekick. I’ve never been afraid of asking stupid questions. If I don’t get it, I’ll ask. But I had so many questions I was in danger of seriously slowing the productivity of the whole team.

I ended up splitting queries between colleagues and the internet, relying on painstaking YouTube tutorials to learn how WordPress worked and lunchtime explanations of APIs and sprints (not, as it happens, running really fast).

This is me, most days.
This is me, most days.

In one particularly embarrassing moment, I edited a colleague’s blog post about game development, assuming 48k meant $48,000. It did not.


I’ve stumbled my way through conversations about Star Wars, virtual reality, the science of noise cancelling headphones and the pro-con list of languages called Ruby and Python (seriously, who names these things?). I’ve even suffered through some powerfully nerdy jokes involving comic strips and code. I’ve practised my fake laugh, like, a lot.


It’s been almost five months since I started here, and my colleagues must be credited with endless patience. They have spent those months helping me get up to speed on things that come naturally to them – and thus must seem all the more frustrating.

The trade-off is that they now have an Average Joe User to test their stuff on, which is both helpful for them and humiliating for me (in a funny way). When something new is built, a developer sidles up to me, app open: “So, what do you think this little icon means?”



Five months in…

I’ve now mastered (kind of) the very tip of the Nerd Iceberg. I understand our projects and what they do for our clients. I now (mostly) understand what our clients are asking for, and can work the landline office transfer system (which is harder than it sounds!).

Major milestones include:

  • I’m half way through a Udemy online tutorial on HTML, and have coded my own page. It has kitten images. #fistpump
  • Out-nerding my husband in a bar when discussing our business with others in the industry. Believe it or not, this is a major personal achievement here, having lived with an insufferable nerd who can work the TV remote better than me and knows what all the cables do.
  • Launching our awesome new company blog and kick-starting our Facebook page.
  • Being able to complete the odd support ticket without having to ask for help.
  • Learning what a Hard Refresh is (did you know lots of things can be solved with this?)


Of course, these are pretty trivial things in the grand scheme of web development. However, I’m sure I’m a lot less annoying with the volume of questions than I was back in August. (Well, I hope I am.) To be fair, I could only go up from where I began.

The team have also adjusted (hopefully) to my loud phone voice, fondness for Google Calendar and penchant for deadlines. They’ve also learned how to explain a problem and solution to someone with an extremely limited understanding, which can only be good when it comes to breaching the divide between devs and the rest of the non-nerdy world. I hope our clients are enjoying the translated explanation as well!


I guess we are all learning from each other, which is what Media Suite is all about.

Figuring out pattern libraries. With cats. U can haz read.

Disclaimer: This post is about my experience implementing living style guides – not an explanation of what a pattern library actually is… To find out more about pattern libraries, see Brad Frost’s article, Anatomy of a Pattern in a Pattern Library.

Back when I was a baby front-end developer, cramming poorly considered styles into a single stylesheet was my jam. Aside from how terrible I was at writing CSS back then, the generic style.css file would quickly slide into a state of unmaintainable horror. Any poor soul tasked with making changes to my style.css file would probably open it and be all like:


Fair enough. I know it was bad and I’m sorry.


Introducing pattern libraries

I like to think I’ve become better at writing CSS over the years, but up until recently, I still lacked experience working on larger projects with larger teams. As I shifted into working on single page apps using Agile processes, it seemed like the perfect time to improve my workflow.

Implementing pattern libraries for our web-based software felt like a step in the right direction. Doing so meant I could provide the developers working on these projects with:

  • Proper documentation for existing styles within a project.
  • More componentised and consistent styles that can be reused across projects.

Introducing a pattern library for each project also set a precedent for structuring our Sass files in a more modular way and writing CSS in a more consistent manner. Maintainability for the win!


The next step to implementing a pattern library was figuring out where to start…

Knowing your audience

When left unmaintained, a pattern library becomes rather useless. The best way to get buy-in from your team is to tailor the pattern library to their specific needs.

I had a few key factors to consider when deciding what would make pattern libraries most useful to our team:

  • We currently have one full-time front-end developer (me!) who maintains the styling across all of our apps. However, my workload can fluctuate, so I’m not always available to help.
  • Because we’re using Agile processes, the design of components changes frequently as new constraints and requirements manifest. Sometimes components get developed before they get designed (not ideal, but it is what it is).
  • Teams usually work to fortnightly sprint deadlines with a  client demo at the end  of each sprint. Developers are usually flat out getting the functionality built and don’t have a lot of time to spend styling components.
  • Developers aren’t as fond of CSS as I am…


After considering the list above, these were my requirements for developing pattern libraries for Media Suite to use:

  • Documentation needs to be easy to maintain.
  • Styles need to be well named and flexible so reuse is a cinch.
  • Easy-to-use layout and helper classes would be needed to keep things tidy if design falls behind implementation.
  • Developers shouldn’t have to waste time writing custom CSS for each new component.

Other teams may have different requirements but I felt this was a good place for us to start.

Finding the right tools


Now that I’d established that the cornerstone of a successful pattern library is the ease of maintainability, I went in search for what I’d later learn is called a “living style guide”.

The difference between a static pattern library and a living style guide is that while a static pattern library is maintained separately from the project it documents, a living style guide is generated from the comments in the CSS/Sass files.


There are quite a few style guide generators out there but in the end I went with Hologram. With a bit of configuration, you’ll have it spitting out a pattern library documentation site in no time.

I went with Hologram for a few reasons:

  • It uses a YAML file for configuration and Markdown for documenting the styles in the comments – both of which we’re familiar with and are easy to work with.
  • We’re currently using Ember to build most of our apps and the Ember build tools complement Hologram nicely.
  • Because Hologram generates the style guide via the command line, we’re able to ignore the compiled style guide files and just commit the config files to the Github repo. I’ve also added a wee script to the package.json file so that our developers can just run npm run styleguide to compile the style guide and serve it up at localhost:8000 whenever they want to check something.

Document and maintain. Rinse and repeat.

As stated above, a large chunk of pattern libraries quickly fall out of date and are simply forgotten about. In order to maintain a successful pattern library, you need to show it the love, even when you’re in a hurry.


If you add or change a component, make sure you take the extra 2 minutes to check the documentation you’ve written is still accurate. You’ll try to convince yourself that you’ll come back to update it later but trust me – you won’t!

Reflect, assess and refactor

Once I’d figured out the technical side of getting a pattern library up and running, my main focus was on getting better at writing more modular and dynamic styles. As time goes on, I find myself committing far fewer new styles and relying on existing ones from the pattern library instead.

I’ve started maintaining a boilerplate pattern library as a starting point for new projects and as I figure out better ways of doing things, I make sure I update this boilerplate so that any improvements are being carried over.

One year on…


It’s been about a year since I ventured into the land of the living style guide. While I’ve learned a lot along the way, I still feel like there’s room for improvement in the lifecycle of the components we’re building.

The life of a front-end developer sometimes feels like a constant struggle between deadlines, budgets, different technologies and evolving requirements. Using pattern libraries has turned out to be a great tool to ease this struggle and focus on what I love doing the most – building awesome things.

And finding cat memes.

Mainly the memes…