Yesterday I posted on two themes I found emerging at Webstock this year: working with design/ers and crafting experiences. Today I’m turning to finding your joy, strategic creativity and One Big Idea ….
Living a good life
There was a definite sense of reassessment at this year’s Webstock. As Jeff Atwood wrote in a recent blog post, announcing he was stepping away from Stack Exchange, start-up life is hard on families. Walter Isaacson’s biography of Steve Jobs is causingreflection in a generation of people who have been pouring their guts into these ventures for the past decade.
Atwood was cited by Matt Haughey in his talk Lessons from a 40 Year Old. “Success at the cost of being away from your family is not success”, Haughey said, arguing that that world is full of ideas that could be executed in 20-30 hours a week, rather than while living off pizza and Coke and getting 2 hours sleep a night huddled under your desk.
The only thing I wrote in my notebook during this talk was THE SLOW STARTUP MOVEMENT. The shared notes for the session record the examples of long-term successful, self-funded companies, the go-to example being Marco Arment’s Instapaper (and see Arment’s response to Atwood’s announcement).
Amy Hoy also renewed up the Webstock tradition of talking inspiration, not technology. In a talk titled Change the Game, she urged us to ignore the invisible rules and the false dichotomies and to find our happiness instead: a true return to the militant strain of joyousness Webstock so often fosters. (And as a sidenote, try watching Matt Haughey’s talk once it’s online then following up with a dose of Hoy’s Fuck Glory – Start-Ups are One Long Con.)
Strategic creativity
Two of my favourite talks this year were by people who have a superpower I utterly envy: drawing. I was fascinated by how illustrator, letterer and designer Jessica Hische and designer, developer and cartoonist Matthew Inman have developed their careers.
Hische noted at the start of her talk that illustration and design are very different industries, and that she feels illustration has better deadlines, better customers and a better understanding between client and illustrator. She also noted that having an artist rep makes getting work and negotiating with clients easier, and that when you’re an illustrator, people assume you’ll be doing freelancing on the side, and are perhaps less demanding as a result.
While being endlessly amusing, Hische also had some strong messages about the intent and benefits of side projects (her own reputation having been significantly enhanced by the well-known Daily Drop Cap project). She noted that she often hears people say that they only get work they don’t want to do, and sees this as a reflection that their portfolio doesn’t reflect the kind of work they do want to do. She started Daily Drop Cap for similar reasons:
It was set up when she went freelance, to garner attention.
It was an opportunity (or demand) to be creative every day.
It’s resulted in an “insane lookbook” for clients, who can survey 300+ examples of her work and use them to identify what feel they want.
She became known as ‘the drop cap girl’ – which has been no bad thing.
It’s a side project that’s project her similar paid work (because people always want more of what you’ve done before).
Hische also coined one of the most tweeted sentiments of the conference, talking about the short shelf-life of ideas:
Don't wait past the expiration date of your excitement
The shared notes for Matthew Inman (of The Oatmeal fame) are some of the shortest for the whole conference, probably because people were too busy laughing to type. But as with Hische, I was impressed by how Inman has strategically moved away from client work that bored or frustrated him, and made his creativity work for him.
I was struck by how closely Inman watches the stats on his site, and rearranges content or creates new pieces to capitalise on this. I also thought about how ephemeral political satire is (most political cartoons have only days or weeks of relevance) but how a guide to correctly using the word ‘literally‘ will be relevant over and over again. And his short rules are gold:
Write about the things you hate
Write about the things you love
Be inspired by facts you learn
Don’t throw your face up on everything
Be a good follow
Don’t ask for likes – make things that are likable
Keep it short
Don’t spend too much time on it
Don’t have your friends look at it.
One Big Idea
Okay – it’s not such a big idea. But: the beauty of Webstock is that it makes you want to keep exploring.
I would love each presentation to end with a slide with three books or articles that the speaker recommends, in the spirit of ‘If you liked this talk, you might also like …’. Or perhaps a Webstock Reading List on the Webstock website (a little like the Kiwi Foo reading list).
Webstock is mind candy (with a side-helping of eye candy) and this, combined with the videos of the talks, would make for year-round inspiration.
So many people who had great blogs now have mediocre tweets.
Given the immense volume of tweets and the beauty of shared notetaking, I now try to stay offline as much as possible at Webstock, so I can focus on the speaker and my pencilled notes. But over the last few days I’ve tried to boil down some of the themes I heard emerging to share here, in two posts. Today: design and craft. Tomorrow: find your happy place, strategic creativity, and One Big Idea.
Working with design/ers
One of the greatest revelations to me since coming to work at Boost has been working with designers. As someone who works primarily through words, I don’t think I’ll ever get sick of watching designers do their thing.
It’s also been humbling to find out how accidentally moronic I sometimes was as a client. Here’s a reenactment of a series of comments I once gave to a poor designer:
I really like what you’ve done – but could we maybe see it in blue instead of brown?
Oh, okay. Hmmmm. How about green?
Oh. Sure. Right. Look, I’m really sorry to keep doing this – but perhaps we could see it in pink?
It’s still not quite right – could you show me the brown version again?
Hey – the brown version’s great! Let’s go with that.
Yeah. I was that person. Now, of course, I realise that (a) designers will always be better at design than I am and (b) almost every variation of colour, placement and size has already been trialled before the best version is shown to the client – and if it wasn’t trialled, it’s probably because it was a bad idea.
So I was delighted by all the speakers who touched on how we can work better with design and the good folks who craft it.
‘Thank you for knowing what you wanted’ – the compliment for a dream client.
There’s a difference between opinions (just saying stuff because you’ve been invited to a meeting and hey – you get to share your opinion!) and people who are identify problems and want to find answers.
If you’re the spokesperson for a committee, speak with one voice: either distill the many voices to one piece of feedback, or at least take the names out.
As a designer, you have been chosen for your demonstrated taste. Sometimes, your client is paying you to correct them.
The phrase ‘treat me nicely, with trust and respect’ works for both sides.
Offer a solution (to show you’ve thought this problem through) (not because you expect this solution to be used)
Give this at the time when it can still be used.
Johnson also invoked the rule of ‘Yes, And’ rather than ‘No, but’, and noted that great teams have great morale, which is needed in the face of constant criticism. I love that at Pixar, criticism takes the form of ‘plussing’ – it’s part of the company’s culture, and it’s essential to the way they create things.
Finally, Jared Spool made a million interesting points, outlining five different breeds of design (Unintentional design, Self design, Genius design, Activity focused design, Experience focused design). The points that really stood out to me came out towards the end:
Every style has a purpose
Great designers know which style they’re using
Great designers use the same style throughout a project
Great teams ensure everyone uses the same style (and everyone understands that they’re doing this)
The more advanced the style, the more expensive this will be
The more advanced the style, the better the design.
Crafting experiences
Webstock 2012 opened with a clarion call for making experiences from returning speaker Kathy Sierra. She gave the idea of “building engagement with users through social media” a robust bollocking, arguing that no matter how awesome your brand or product is, it’s the awesomeness your users feel about themselves that counts. I was interested in her ideas about aligning business goals with user goals, but found myself wanting more actual examples of where she sees this awesomeness happening.
I wasn’t in content strategistErin Kissane’s presentation, but it sounds like adopting an attitude of craftsmanship (and allowing time for it) were big themes of her presentation. It seems Erin was asking how to bring the values of craft (mastery, human scale, excellence, satisfaction) to large scale system. I’m looking forward to watching her talk when it’s up on the Webstock site.
One of my favourite ever Webstock talks was Cal Henderson at Webstock 2008. I’ve always enjoyed the presenters who take you on a deep dive into the work they’ve done, while teaching you more general lessons along the way. This spot for me was filled this year by responsivedesign guru Ethan Marcotte, talking about the Boston Globe redesign (if you’re too impatient for the video to go up, check out his blog post on this).
Ethan ran us through the opportunities and challenges of reshaping the bulging content of a newspaper into the slim lines of various desktop and mobile devices, and the ways that designers and developers might be able to change their usual working patterns to meet these (it sounded a lot like what I see in our teams that are using Scrum).
Craft took centre stage in Jennifer Brook’s presentation about publishing and the iPad, where I was more captivated of her stories of teaching herself to bind her own books than I was by her story of working on the New York Times iPad app. I’ve squirreled away her recommendation of Designing Calm Technology for later reading.
Tomorrow
Those were my first two themes. Tomorrow I’ll cover off finding your happy place, strategic creativity and One Big Idea.
Behavior Driven Development has become a key tool in our toolkit as developers strive to become leaner and more agile. Here at Boost we have been using Cucumber with Ruby on Rails to integrate Behavior Driven Development into our everyday software engineering practices.
At Boost we’ve been using Test Driven Development (TDD) for some time now. Test driven development is a process whereby the developer writes an automated test prior to the beginning of coding of a new function or improvement to an existing function – the test fails at the outset as no code has been written. The developer then develops the code to pass the test, as well as refactoring the code to an accepted standard.
We’re also using Behavior Driven Development (often referred to as BDD). Behavior Driven Development extends Test driven development by writing text cases in a way anyone can understand. Behavior Driven Development fits in well with Scrum in that the Behavior Driven Development tests can be written by the product owner. A product owner writes acceptance criteria for a user story within a sprint, but by asking the product owner to contribute to Behavior Driven Development testing by writing feature descriptions we are fostering collaboration rather than merely co-operation. The product owner is able to take fuller responsibility for a successful outcome.
Over the last year we’ve been using a tool that combines both Test Driven Development and Behavior Driven Development. Cucumber is a tool that enables the product owner and developer to work together to produce features. Here’s how it works:
1. The product owner writes a plain text description of a task and how it should work using a particular syntax (Gherkin) and providing scenario examples. Here’s an example of a feature description written for our Intuition HQ site:
Feature: Sign up to a plan
Sign up should be quick and friendly.
Scenario: Successful sign up
Users should see a confirmation when their payment details have been accepted.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation page
Scenario: Invalid card number entered
Where an incorrect card number is entered
Given I have chosen to sign up
But I enter an invalid payment card number
Then I should be told that the card number is invalid
And the form should be redisplayed offering me the opportunity to re enter my card number
2. The developer writes corresponding step definitions. The step definitions should include the phrases used within the feature description. The step definitions are tests written in code that Cucumber then runs against the site. The first time the tests are run they will fail as no code has been written.
3. The developer writes code for the new functionality described in the feature description and re runs the tests. Cucumber highlights success within the feature description in green, pending in yellow and failure in red as shown in the image below:
5. The developer amends the code and reruns the tests and so on until Cucumber shows the entire feature in green indicating that the tests have been successful.
The advantage of working with Cucumber is that both Behavior Driven Development, (in the form of the feature descriptions and scenarios) and test-driven development, (in the form of step definitions), are used to verify the success of development.
I spoke to one of our developers about his experience of using Behavior Driven Development and his response was that one of the most important advantages of using Behavior Driven Development is that it allows the product owner to write acceptance criteria in the form of features. The developer can then work towards developing step definitions to test the features the product owner has defined. The step definitions correlate with the acceptance criteria/features with the intention of leaving no discrepancies between what the product owner wants from their product and what the programmer develops.
Behavior Driven Development is proving to be a valuable tool in helping us to eliminate the gap between developer and client understanding of requirements therefore producing successful and useful features.
