Thank you, thank you, thank you.
Hello?
Hello.
What the f--?
This is terrible.
We're a company from Edinburgh.
We're small, we're about 4 and 1/2 years old
and we're going to talk about this tightrope
between mediocrity and bankruptcy.
And basically what that means is we'll
talk about some challenges that we
have in terms of finding clients, or dealing
with clients, or dealing with designs, coming up with ideas,
or building stuff and development, in general.
We'll also show you some monkeys.
First off, I'm going to introduce myself, I'm Espen,
this is me.
Wow, that's a big drawing.
I'm creative director, as you can see.
I'm not an illustrator yet, but it's pretty good.
I'm also going to introduce this fellow here.
Hi, I'm Bart, and I'm going to tell you
how miserable life of developer is at Primate.
And hi, I'm Gordon McLachlan, I'm the managing director
of Primate, and I'm going to talk
about the wonderful world of clients
and getting business and project management.
So before we really start, we want
to talk a little bit about why we started Primate
and what's the whole ambition behind this is.
Hands up if you've ever worked in an environment like this?
A few?
We all met at our previous employer and we felt like this.
I appreciate some of you might not
be able to raise your hand because your boss is sitting
right next to you.
We felt like every day was kind of walking into a factory.
We do the same templates, the same clients,
the same churning out, so, you know, assembly line style
of design and development.
And we wanted to do something different,
so we want to create our own agency
where we could approach things our own way, essentially.
So one night when we've actually
decided we going to run our own company,
we've sat down and just talked about everything we
hate about web agency business.
And we felt really, really negative,
so we've distilled it into three positive messages that
soon became our vision for the company.
And that's the embrace progress, create for content,
and be honest.
And one of the challenges we've had over the past 4 1/2 years
is, how do we do really creative work and still get paid?
That may seem obvious, but sometimes those two things
conflict.
And that's where this idea of the tightrope comes in.
We're still working on the tightrope.
We don't want to end up doing mediocre work
and just churning out those same templates just
under our own moniker.
Equally, doing really creative work requires clients
and it requires balls and it requires money.
And we need to find that money, otherwise we have no business.
So, speaking of business, I'm going
to leave you in the hands of Gordon
just now, he's going to talk about clients and shit.
So, clients and shit.
Yeah, very exciting topic.
The first thing, and probably the most important thing
of any client and a business is getting work.
Clients are really the heart of every service agency
and of every freelancer, as well.
And if you don't have clients, you don't have a business.
If you don't get paid, you don't make money,
you can't earn a salary.
So they are incredibly imperative in that point
of view.
And it doesn't matter how good you
are at design, or development, or SEO,
or any of the other things, if you don't nurture
these clients, you don't find good ones,
you're going to be happy, and you're not going to get paid,
and you're not going to have a business.
So this dynamic is really the first challenge
we face on our tightrope.
How do we find good clients and how do we get good work?
And of course you don't just want to find any client,
because getting work you hate, it's not
going to make you happy, it's going to make your work suffer,
as well.
So to achieve this, you've got to try
to balance two things, one of which
is building and maintaining relationships,
which are very important.
And the other side is usually a very tedious kind
of pitching and proposal and tender process.
We love all our clients at Primate-- most of them.
We've only ever fired one client and that was a hard decision,
but it was something that had to be done.
It was just relationship that wasn't working,
and they were trying to bully us and they didn't appreciate
our time or our work or our knowledge,
so we took the decision, we had to get rid of them.
And like I said, finding good clients is tough.
And we have this kind of dream image of what
the perfect client is like.
They usually have to have money, obviously.
They might want to be in a sector you enjoy working in,
if it's charity, food and drink, tech, or something like that.
You probably want them to have ambition,
you probably want them to be really friendly and easy to get
on with, and you certainly probably
want them to respect your work and respect your time.
And the first few things are quite
easy to quantify and qualify.
Like you can tell the turnover of a business,
you can tell their profit, you can tell their marketing spend.
But how do you know what someone is actually like?
And that's a challenge.
And usually you don't actually know
what someone's like until you get into bed with them.
And we've had a lot of occasions at Primate
where we've met people and they've
seemed really great and really exciting and really
interesting, then we start to work with them
and you find out a few weeks down the line
they're a complete nightmare.
So you got to try be picky, and that's a challenge
on the tightrope as well.
Because if you're too picky, you'll have no clients,
or grow no business, no money.
And if you're not picky enough, you'll
just have really bad clients who will make your life miserable
and won't be very happy.
And like I was saying, as part of this process of finding
the client, you usually have to pitch, as well.
And I love pitching, I love the process of pitching.
But the whole process, the whole idea of it, is really terrible.
Something I'm sure most of you have done.
And the idea of a company going out
and trying to source several agencies, maybe five or six
or seven at a time, and get them to all come and sit
around and prepare slides and presentations
and work and then present, it's really crazy.
We kind of joke a lot, it's a bit
like speed dating, that you have to go and stand
in front of someone and then sell your work to them.
And as part of this, you usually have
to do a lot of creative work up front, often unpaid.
And that's a difficult decision, as well.
How much time do you invest in the sales process?
How much time do you invest in a pitch or a presentation?
Because ultimately, you don't want to be under-prepared
because then you're not going to win the job,
but you don't want to be over-prepared, either.
And if you spend 10 days of work for every job
that you're pitching for and only win
one piece of the result, that's a pretty terrible conversion
rate and that can have real negative impact
on your business.
So that's difficult, it's very difficult to juggle.
An interesting example's a few weeks ago,
we actually pitched for a big hotel chain
with their headquarters in Brussels.
So myself and Espen and one of our colleagues
flew over there for two days for a one hour presentation.
And before that we spent something like 10 days
on creative work.
We put together visuals, we put together slides, PDFs,
leave behind everything.
We had a really good feeling about the job,
we had a good nod on it, so we thought, yeah,
we're really going to invest in it.
And the whole project was worth a lot of money,
it was worth 100,000 pounds, or about 130,000 euros,
so it was sizable.
And we didn't win it.
We found out afterwards that there
been six or seven other agencies pitching all around the world,
from America, Belgium, and the UK.
And as good as the feedback was on our work, ultimately
the client had chosen to go with their incumbent supplier,
the person they had a relationship with already.
So take from that what you will.
On the contrary, though, one of our best clients
is someone that we got when we pitched
and we did very little work up front.
We simply went along and had a conversation with them.
And I think we did a few slides and we'd had a few visuals,
we'd taken some websites and put on their logos,
it gives them an idea, but we hadn't invest a lot of time
in it.
And ultimately we just spoke naturally, honestly,
and had a really great conversation.
And not only was a project worth quite a lot of money,
but they've turned out to be one of our best clients
in the respect that we've had such
a great ongoing relationship with them.
And in fact, we've even teamed up on projects with them
in the future.
So how much time do you spend?
How much is enough?
And that's a difficult question, I
don't have the answer to that.
I know there's a lot of agencies out there,
and a lot of really respected agencies
they refuse to do pitches unpaid or refuse to do it at all.
But then equally, I've seen agencies in Scotland
where we're based that we're going out with business,
we're taking this approach, so it's really tricky.
We've only ever been paid to pitch once,
and that was by an American company.
So certainly in Scotland and in the UK,
it doesn't seem to be the norm.
And so whilst I feel like sometimes we've
maybe lost a bit of courage by really going guns blazing
at these opportunities with creatives and visuals,
equally, I know that our competitors are doing it.
It's very hard to stand there and not have anything to show.
And ultimately I'm reminded of this quote
by the ice hockey player, Wayne Gretzky.
He says you miss 100% of the shots you don't take.
I'm also not advocating that you should go out and pitch
for absolutely everything you take, you have to qualify it.
I do believe if you don't sometimes
look for the opportunities and explore where they go,
you might end up with nothing to show for it.
So the final thing I want to talk
about along the lines of clients is project management.
Or, as I like to call it, managing
ridiculous expectations and stupidly tight budgets
whilst appeasing clients, over-zealous developers,
pandering to vain designers, and avoiding disaster in order
to survive another day, earn a meager salary and still pay
and impressive mortgage so you don't end up
homeless and destitute.
Thank you.
[APPLAUSE]
And the challenge here is, how much time
to invest in project management?
Too little and it's just chaos, too much
and it's a huge burden.
You spend too much time just maintaining specifications
and with change management and all these things
and not enough time actually doing the things that matter.
We work in an Agile manner at Primate.
I'm sure most of you are familiar with that,
I don't have time to really go in depth
and talk a lot about even though it's something
I'm very passionate about.
I stole this slide from Robert Stulle from edenspiekermann_,
who I saw talk in Barcelona in July,
and I really liked it as an analogy of how the whole Agile
process works.
It's this idea that really your client
is trying to get from A to B, and that's the problem you're
trying to solve.
And so instead of just trying to build a car and start,
and then running out of money and time and budget the end,
and not having a car, or having a part of a car doesn't work.
What you actually do is build a product in phases.
So you start with a bicycle, and then you create a motorbike,
and then you create a car if there's time and budget left.
And that really sums up to me and I really
like that approach, because then the clients always
have something that ultimately hits their objective.
Equally, the whole Agile process and methodology naturally
promotes communication and collaboration, which, I think,
is hugely important for clients and relationships and project
management.
We don't have account managers at Primate,
so though we do project management, all our team of six
and seven people, they're hands-on with the clients
all times.
We meet with them very regularly,
we meet with them every spring, we talk to the a lot
and we really involve them in the process.
Really great thing about Agile is
it tries to avoid specifications.
If anyone here works with specs, I'm sorry,
I feel really bad for you, but they are dreadful things
that people don't read and are a real pain to maintain.
So doing less of specifications is a good thing.
Agile's just not perfect though, it's not a silver bullet
and it can be hard to use on smaller projects.
If your data website only has a budget of 20 days,
taking an Agile approach can be very tricky.
Likewise, it tends to promote this idea
of the MVP, the minimal viable product,
and sometimes you forget about the lovable product,
the things that really matter.
But compared to what's out there,
I still think it's the best.
Having said that, we've had some pretty bad experiences with it
because we find some clients, not all of them,
but some of them, as much as you try to explain Agile to them,
don't actually understand what it is.
This is an example of a client who,
the one we end up firing, actually, who, at the start,
we talked a lot about it, we explained it,
we explained the concept of ice box and parity and everything,
and they said they got it.
And further on in the project we kept
reiterating this and the idea that we
had this brainstorm at the start and you might not
get everything in the bottom of the icebox, and they got it.
And three months later they're shouting at me down the phone
because they didn't have everything they want.
It didn't make me very happy.
And it's the idea that you still have
to maintain the relationship and you still
have to have a good client to work with,
because they're going to struggle
to prioritize their features.
They're still going to want everything no matter
how much you explain to them that you might not
be able to deliver it, or they might not
be able to get in their budget, or something else comes along.
To aid our process we a couple of tools.
One of them is Base Camp, I'm sure you use it and know of it.
Another one's called Sprinter, which
is actually a tool we've built ourselves in-house.
And these just trying and help and expand
on the natural transparency in communication and collaboration
that Agile brings.
And ultimately, like I said earlier,
what we're trying to do is really spend
more time on the doing and less time on the management.
And I don't mean managing us as in talking to clients
and dealing with them, but less on the updating specs
and spreadsheets and all the laborious things.
That just gets in the way of it.
But ultimately, it's still boils down to relationships
and having a good relationship with the client,
and Agile works very well for that,
because it promotes, like I said,
the idea of communicating with people.
So to summarize everything I was talking about in one idea,
it would be, be honest.
It's an approach we take, and it works very well.
The more honest you can be with a client or with anyone,
the better the relationship's going to be, the more honest
you could be at the start, the more likely
you're going to have clients who respect you, the more likely
you're going to find the ones that truly you connect
with if you try and be salesy and lie
to them at the start, that's never a good-- never going
to end well.
It can be difficult, though, because sometimes being honest
is hard.
And particularly, if you're trying to make a sale
and you have tell them something they don't want to hear,
that's a difficult thing.
But still, be honest as much as you can.
So I've spoken for awhile about the boring side of things,
and now Espen's going to talk about the more exciting stuff,
clients and shit.
Design and shit.
So how many of you guys are designers?
Hands up.
Great, so if you-- design on the web is often about,
you know, CSS and debates about pixels
verses ems and frameworks and SaaS and all those things.
To me, design is more about communicating an idea
or communicating a piece of knowledge
or communicating a user journey.
It's not so much about implementation,
but is about the conception of ideas
that we, as designers, have.
So I'm going to talk very-- I'm not
going to talk all about implementation, really.
I'm going to talk about the kind of, the shift that's
around design.
And it starts with this tightrope here.
As a designer we start with a brief,
and then at the other end we want to deliver an idea.
And over that tightrope there's several challenges,
and, I think, I could speak for a whole hour about this,
but I think I'm going to choose two main things that we
struggle with or that we-- the things that come up
time and time again that sometimes stifle creativity.
One of them is content and the other one is best practice.
First of all, the C word-- content.
This is the process we had when I first
started working as a designer.
I was a magazine designer, I worked in a publishing agency.
So we'd have maybe half to staff were writers
and the other half were designers.
So we were pretty much an even split,
and content was really, really important.
Naturally, when you do a magazine,
someone has to write the articles, right?
So the editor would go away or someone would interview person
and write up a draft.
That would be passed on to the designer, who would then
come up with concepts or images are illustrations or layouts,
even, that suited that content.
At the end, I'd maybe go and ask the editor,
can you tweak this headline, or do you
have an idea for the little box that we can use here,
or can we make this longer or make the shorter?
And likewise, the editor might ask
me to change the layout a little bit.
It was real collaboration, it was content and design
together.
On the web a few years ago, maybe a decade ago,
we got the CMS.
And the CMS changed everything in terms
of content, which means it also changed the design process.
Nowadays a lot of us design templates
without really knowing what content's
going to go inside them.
We design these shells and we focus
on making them really beautiful, because we can't really
tie the headline in with this superb image
if we don't know what the headline is.
So we pass our templates on to developers and builders
and coders and then maybe, in our experience,
if you're lucky, two weeks before launch
or maybe two hours before launch,
we get an email with shit loads of content,
we'd have to cram it into our templates.
This way of designing changes the whole idea
behind what designers can bring to a project,
because when we don't have content,
we start focus on the other bits like the buttons, and the drop
shadows, and this gradient, and the layout,
than this grid system, and this way of implementing stuff.
There's been little talk lately about style guides
and modular design and atomic design.
Everybody know what atomic design is?
Or modular design?
It's the idea that you start with your little small bits,
modules, like a maybe buttons and sign up forms or whatever.
You build up modules, and when you have enough modules,
you could build a page, and when you have a page,
you can build a whole section of the website.
But to me, that's kind of organizing design assets.
It's a really good process, but there's no ideas phase in that,
there are no concepts.
There's no real creativity.
So I feel like, in terms of content,
we have this tightrope.
On the one hand, if you don't have any content at all,
you have meaningless templates.
They might look really sexy and then might
be really responsive and nice and fast,
but they don't mean anything until we
stick any content into them.
And you're not adding any meaning to the content,
because the templates is design beforehand.
On the other hand, if every website was like a brochure
or magazine, you need a copywriter
and you need an editorial designer
to sit and work on every single page,
and that's simply too expensive.
Our answer to this is a take content
and bring it into the design process.
And it's not emailing the client and say, hey,
can you send us a draft for this page?
We do that as well, but when I work with ideas,
I need to be an editor for a moment.
I need to be able to express my ideas
and think about content along the way.
So, for example, if we're all designing
a website for a lawyer firm, for example,
and we have a kick-off meeting and we
talk about their values and their ethos
and they're like, yeah, we're different from all
the other lawyers.
We're honest, we're bold, we want to do something different.
And you're like, that's great, I can help you with that.
And then the CEO goes, OK, that's brilliant.
Can we start tomorrow?
That's superb.
Here's an image I wanted to use on the homepage.
OK, great.
Really different.
Bold lawyers.
Now, if this is your text, you have nothing.
You have an image and you have some text,
but there's no meaning, there's just
a handshake, the horrible handshake of death.
But, this is where we unleash our inner copywriter,
this where you go OK, I see you really want that image,
it's a little bit overused, but if you insist,
we can work with it.
But we can invite something into this
to make it more meaningful.
We can change the headline-- we don't do secret handshakes.
Suddenly you have something that is more intriguing,
you actually making the user think.
Fuck you, Steve Krug.
We're writing idea into it and we're
making this picture, the most boring picture in the world,
more meaningful.
And it ties in with the values of the lawyer firm, as well,
right?
I'm miss this kind of thing online,
I don't feel like we do to enough.
Synergy, this is a word that comes up
a lot in corporate websites.
And sometimes, like with a handshake,
you might be forced to work with copy
that's seems bland and trite.
But you can do the same thing here,
you can use images to enhance the meaning of the word.
So like a simple analogy of the flower and the bee might work,
it's maybe a little bit obvious, but it enhances
the meaning of all the words.
You're telling a story about two things coming together
to create something that's bigger than themselves.
And of course, the big the disparity between your image
and the text, the greater the effect.
Here's one example from the real world.
My colleague, Steve, did this.
It's for an organization that he's created called recreate,
it's a space where mentors and mentees can come together.
On this page you could have had any picture
of a hipster on a bicycle smoking a pipe with an iPad
and that's a perfect image of a creative, right?
Instead, he chose, this is actually stock photography,
but he found these two pictures and he conveys this idea
of the fusion of two minds.
It's not rocket science.
Is really simple and it's cheap.
It's not difficult to build, but it's meaningful.
This is a company called Active Payroll,
we just launched their site a few weeks ago,
and this is super boring stuff.
It's about payment system for companies worldwide.
This is from their about page.
And again, we could have had this really nice picture of all
of them in the boardroom smiling and it
could have said, about us.
But we had a conversation with them early on in a project
and we talked about who they were
and, you know, what's behind the scenes, how do you guys work?
And they started talking about their DNA.
So we thought, OK, that's great, let's use that.
So we wrote the headlines for them.
And then suddenly, again, we could use stock photography
where we could tie it in, we had this visual hook
so we can create a synergy between the headline
and the image.
And this is the last example, also one of Steve's designs.
this is the history page for a company
that those cruises on the Loch Ness in Scotland.
And again, it doesn't just say, history.
It says, the deepest love affair,
which was written by a copywriter based
on Steve's idea.
And what Steve done here it's just so nice,
like just this-- setting the type
in a way that makes it sink into the loch, I think,
is brilliant.
And again, it's simple.
If this was a template, it would be
the same template as every other website out there.
Big hero image and some white text on the front.
But when you have this synergy between the copy and images,
it really means a lot more.
So that's what I wanted to say about content.
And now I'm going to tackle best practice and the rule book.
I'm a little bit sad that Lisa isn't here anymore.
I thought her talk was really, really good.
But maybe some of the stuff I'll say,
she would be really offended, because maybe not advocating we
follow the rules all the time.
I think in our industry one of the best things
is that we're really good at sharing stuff, right?
We stand on stage, we write our Medium blog posts
and we're on Twitter, and we share best practice and tips
and hints and guides.
Sometimes, though, things get really, like,
it starts to sound like commandments.
Thou shalt not definest thy line height in pixels.
Thou shalt not baseth thy breakpoints on device sizes.
Or recently, we've had some talk about this today,
as well, thou shalt not taketh the name of the Lord,
performance, in vain.
Do you know what I mean?
So I might sit there and I'm designing a website
and I'm thinking, OK, we've got three piece of content here,
they're equally weighted, they're equally important.
So I need to I want to display them side by side.
This my starting point and I figure, this is good,
people can see all of this at the same time.
And OK, thou shall beginneth with mobile, fine.
I'll start with mobile.
My navigation is a little bit too long,
we all know what to do, we just condense the navigation
into one icon and we can put that in--
[EVACUATION SOUND EFFECT]
--no, OK.
Right.
No hamburgers, right?
We'll stack the navigation.
Hopefully it's just a short navigation.
What do we do with the content?
Well I think it's equally important.
I don't want a long, scrolling page,
so I want to stick it side by side and people could swipe,
you know?
[EVACUATION SOUND EFFECT]
Oh, OK The carousel.
Sad face.
[APPLAUSE]
This is the tightrope of best practice.
If you take all this stuff and put it together,
you have this massive Bible.
And if you follow that Bible to the letter,
you're a fundamentalist and your site's become really boring.
They all look the same, they all work the same,
and it's maybe some people's ideal vision on the web,
but it's not mine.
Like, I want something that's terrible
and wonderful and crazy and experimental
as well as things that are functioning.
If you don't follow any best practice,
you'll have Jakob Nielsen hunting you down and saying,
your site is unusable.
So it's a real balancing act.
Ladies and gentleman, my name's Espen Brunborg,
and I have a confession to make.
You see, I'm a Parallax uses.
It gets worse, I also use carousels and I use hamburgers.
Why are we so polarized around these things?
What is it about it that makes you go,
oh you can't do, that you can definitely not do that,
if you do that, you're evil.
I don't really know, but plenty of us think we do, right?
There's metrics, we can measure everything on the web,
and that's brilliant.
You know, you have A/B testing, you can put your site up
and you can get real feedback regarding
how your users use your site.
And when we see something like 60% of users
don't complete checkout process, or only 1% of users click
through to the next slide of the carousel,
it makes us feel good.
It makes it feel like we know this stuff
and we have the answers.
But metrics from one site doesn't necessarily
translate to another site.
And I think the answer to most design questions
and challenges is this-- it depends.
It totally depends on your context.
So a lot of people think rotating banners evil
and they should be removed immediately.
But I think it depends, it depends on the context.
How many people have a smartphone?
Right.
It's a big carousel, right?
The iPhone, Androids, iPads-- they're all carousels.
You just swipe from one slide to the next.
So it depends.
We did a carousel a while back for a company
called Harviestoun, they're a microbrewery in Scotland.
And as part of our vision for their websites
and their strategy was to really highlight the brewers, right?
Because this is a small place and we
wanted people to really connect with them.
So we had this photo shoot, and we shot all the brewers
and try to bring out the personality
and it was really, really good.
And we put this in a carousel.
We got nice copy written about them
and we had funny things like their wrestling names
and little jokes about them.
Really tried to bring it out.
And this was heavy, like it's, there's a massive background
image, it's Parallaxed, obviously we're
writing JavaScript, it was a real pain to responsify.
But people spend two minutes on this page.
It's the second longest time spent on the entire site.
Two minutes, and that's only one minute of load time.
That's a joke.
What I'm trying to say is that I think in this context,
people obviously know how to click to the next slide.
But the most important thing is because of the photography
and because of the stuff that we wrote,
and because of the audience actually wanting
to find out stuff, when you want to see the next slide,
you will do something to try and find it.
So I'll finish by saying fuck the rules, responsibly.
Best practice is really good.
I really, really loved Lisa's talk
on standards and the whole music analogy, it's fantastic,
standards are great, this whole community's great.
It's good to share things, you know,
and give each other advice on what works best, better
than other things.
But if you have an idea that works
for you or for your content or your audience or your device,
but then Twitter says you can't do it, fuck Twitter.
Just try it.
This is the whole tenant for our design process at Primate.
We try and bring content into it,
and we also think that if your content warrants it,
you can break the rules as long as you know why you're breaking
the rules, and in this case, it might be a good idea
to try a carousel or a hamburger, et cetera.
Then we should go for it.
So I'm now going to leave you in the capable hands of Bart, who
will talk about the murky depths of development, which
is why we're all here, so sorry about the delay.
Yeah.
Development and shit.
So as you probably expect by now,
we work with designers quite a lot as developers in Primate.
And I will politely say that this relationship
is really interesting.
But the one that's been well researched and observed
in the building is the one between architects
and engineers.
And if you were coming from development background,
you probably heard a lot about it in system designs and system
architectures.
But I think when we go to front end, the analogy, the parallel,
is even stronger.
Because on one hand, you've got an architect, whose main goal
is to operate in this sphere of vision and aesthetics
and emotions.
And on the other hand, you've got someone like me.
Front-end developer, who just has to build it.
You know, deliver to the real world,
just like engineers have to deliver architectured designs.
And we have to deliver them on time and on budget,
as well, which puts additional pressure on us.
But fortunately, we are not only delivering
what designers created.
Sometimes we bring stuff to the table
as well to enhance the creativity.
So like engineers did for architecture
in suspension bridges or reinforced concrete and stuff
like that.
We love these moments because we love our little toys,
we love to share them, and sometimes
designer are not really fussed about it,
and we're like, yeah, OK, but I didn't
see any application for that, but we
need to keep trying because eventually, they
will come back and ask for it.
Fortunately, we can tell designers off sometime
and make them cry.
Imagine, Escher came to engineer and said,
building me that staircase.
It's fine, I've just sold it to the client
and drawn it five minutes ago, and you can build it, right?
It's impossible, sometimes it's impossible to build something,
at least for us, as developers, at least on time and on budget.
So we like these challenges, but we have to stand on the ground
and do these reality checks during the design phase
as often as we can.
Because otherwise, everyone will be blaming us
that we've not been able to deliver that on time.
And I think the analogies between web development
and construction industry and here
because they operate in real world.
We know physics and we are got models bills and stuff
like that in engineering.
In web that's always changing, we
don't have anything to rely on.
Just like a few weeks ago we had to fix some back wave animation
on one of the sides because it didn't work on iOS 9,
something unexpected.
So for us, it's really this balancing act
between what's crazy and what designers really want to do
and what's achievable and unfortunately,
sometimes uninspiring.
Because you don't-- technology's greatest when it's transparent.
People will see the design, they will appreciate design,
but unfortunately very often they
will not appreciate the build.
You recognize some building and you ask, who designed it,
but you've never thought, like, who build it, really?
Who made it stand for 100, or 200, 300 years.
So we've got all these cool things, different technologies.
We use technologies that's people in Silicon Valley
will kill each other for.
But in Scotland, it's a completely different story.
You come to them and you say, look,
I'm going to build you a Ruby on Rails site,
and they will tell you to get out
because they want Drupal or Umbraco
or something like that.
But fortunately, some other clients simply don't care
or they trust us with our choices and at that point,
we know that we're going to have a really good gig.
But what's really interesting is that clients really don't care
about-- at least to clients we have,
they don't really care about the front end tech we use.
And it's really interesting, like, we've never
won a client because we said, we going to give you,
a living style guide, or we never
lost client because we said, we'll try react,
or we going to build it in Ember, or anything like that.
Nothing happened.
And it's really weird, because front end tech,
sometimes I feel like a little girl who get lost.
Nope.
Let's call her Alice, right?
So on one of her adventures to Wonderland, Alice
met the Red Queen and they were standing
of this giant field that resemble
this big chessboard and Alice is asking queen,
how do I become queen myself?
And she's like, OK, fine, you just
need to like run to that squared over there over the horizon
and you'll become a queen, right?
I can show you, it's no problem.
So she grabs her by her hand and they start running, right?
Then they run faster and faster, and soon
everything around them starts to blur
and Alice can't feel her legs touching the ground anymore
and they stop to find themselves in the same place.
And I bet some of you we feel like that
when Angular2 comes around.
But the queen says it takes all the running
to just stay in the same place.
And if you think about technology,
how it evolves, web technology or even front-end technology,
it evolves even quicker.
10 years ago, we didn't have a term Ajax,
or it first appeared around that time.
There wasn't Spec, for sure.
jQuery wasn't around, really and you
feel like jQuery has been around forever.
And even later on, we had some really cool things happening
in the front-end, but just in recent years
there's been a massive, massive explosion
of new tools and technologies.
So going back to the Red Queen, beside being
just a great story, you kind of a geeky psychedelia that both
of Alice's books are full of.
It gave the name to the hypothesis
in the theory of evolution called
the Red Queen hypotheses.
And it states that for a chance of survival
in ever-changing environment, you
need to move faster than everyone else.
And it claims to explain couple phenomena, and one which
is the advantage of sexual reproduction
against asexual reproduction.
This is kind of the stuff that we do at Primate, quite a lot.
I mean, not literally, but-- if you think,
sexual reproduction is all about like crossing genes
to make your offspring survive and give them better chance.
And this is what we do.
If you think of our gene pool, our knowledge
base we share in the office, and our offspring
being the work we produce, we have to think about everything
while working as developers.
So we will talk with designers quite a lot,
try to understand the basics of design,
things like grid systems, or vertical-written typography,
things like that.
So we can at least understand what kind of message
they try to communicate to the end user
and find the best tools to use.
We also need to understand business side of every project.
Very often we juggle three or four projects at the same time,
so we need to understand really what
needs to be delivered by end of the week or for tomorrow.
And most importantly, we have to speak to our clients,
because we, ultimately, deliver work for them
and if we want to be proud of what we create,
we have to think about it.
So all that means, really, that as developers,
week need to step up and don't let ourselves
push in the development dungeon where we put our headphones on
and listen to the music at work.
We need to speak to everyone else around us,
inside the office and also outside of the office.
That's the whole team that works on the project.
So we need to understand what they actually need.
Going back to the Red Queen hypothesis,
the other thing that it claims to explain very well
is the extinction of co-evolving species in this environment
we all live in.
And if you imagine that this little monkey is us
and the raptor is one of our big competitors,
we're on the treadmill where we need to run faster
than them so we survive.
And for us, running is really experimenting.
So in this wonderland of webfront, front-end web
technologies, we've got all these magic mushrooms,
cupcakes, brownies, portions, whatever.
Pipe smoking, caterpillars, you name it.
And we need to try all of them, or some of them, at least,
to know what's happening.
Take, for example, responsive web design.
I'm not quite sure when exactly we've adopted it,
but very early when we started company.
And thanks to that, just when our competitors
were starting to realize that they
need to start thinking mobile first,
we already had like two years off proper portfolio work
to show off to our potential clients
of fully responsive websites.
So it's all about finding these trends,
but not just because they trendy,
but because you realize that there's something more in them
and they going to help the business or they going to help
communicate the design better.
So we're bouncing on that line between trying everything
and never producing any work, and mustering just one thing
while everything else changes.
And that's how being so small we would probably die.
So we try a lot of things.
And just to give you some examples,
like in past 18 months, we've been through like three
different build tools and we just solely trying to step away
from the jQuery completely.
We are still using SAS, but we ditched Compass few years ago,
unfortunately.
Although I still like the vertical written part of that.
We do things like a Sprintr, we've
build it in Rails in probably like six weeks just
to rewrite it straight after into the JavaScript almost
completely.
And if you look at these two screenshots from Sprintr.
They're separate, completed two separate apps
built in totally different JS frameworks,
just so we could get a feel for what
we can achieve with these frameworks, what
are the limits, what is better for this use case?
And I already know that I would like to ditch one of them
and rewrite it in the other.
And makes you realize that tech is disposable after sometime.
It's a big pile of junk after a few years.
So have courage to dump stuff that maybe doesn't work,
or maybe if things are getting better somewhere else, have
courage to dumb things that are small,
like tiny tools and libraries or bigger frameworks,
even whole languages.
You can do it and you probably should.
Kong, our CMS from dreams, we've started
building that probably like six years ago, or six years ago,
a long time before we've started Primate,
just for few clients on the side.
And it was great project.
We had everything, like visual editing,
and it was six years ago.
We had to inline visual editing of content,
these interactive blocks you could create pages of.
We even had to build our own WYSIWYG editor
to do what we wanted to do.
And we had to stop because we realized
that we are competing with things like Squarespace,
or some kind of bigger projects we've lost a bunch of.
So we've understood that it was big, big undertaking
and we couldn't just continue.
We still run few clients on this,
but it's real difficult right now.
We've failed, right?
We failed with Kong.
But failure is something that, I think, every developer should
get used to, because you will feel that you're
failing quite a lot.
And I bet every one of you who is developing websites
or do any kind of development feel the same sometimes.
Just as bonus, this is a guy called
[INAUDIBLE] he's from Jing Woo martial arts school,
he's some sort of hermit living by the Great Wall of China.
And part of his daily regime is punching himself in the face
continuously for like an hour or so every day
just so he's ready when real punches land.
And you should do the same, you should practice failing.
If you do it more often, you'll get
used to how you go going to respond
in these kind of situations, because everyone fails.
I've seen broken HTML image from Gumtree.
And a few weeks ago, if you looked at Google Maps API page,
it was completely broken.
Unreadable, unusable, everyone fails, we need to accept it.
So we need to balance between what's
achievable and uninspiring and what's crazy
and greatly communicates the vision of our designers.
Wee need to keep experimenting and failing every day
just so we can embrace progress.
So we've spoken about design, we've spoke about development,
we've spoken about clients, and I'm
sure there's one thing you all really want to know,
and that is, can you go for lunch?
Well, we're not going to keep you much longer.
So we've come to the end of our talk
and the end of the tightrope, and the question
is, how do we feel?
How are we doing?
And we've started to realize that this tightrope that we're
on is a business and the journey we're on, it doesn't end,
and the stakes just keep getting higher.
Although we're doing good work, we're
not doing the best work in the world.
I know we're not bankrupt, we're not millionaires, either.
And the stakes just keep getting higher, projects get bigger,
salaries get more expensive, teams grow.
So it can be really tricky to manage sometimes,
and sometimes we do sit and ask ourselves,
what's the point of it all?
What is the point?
Sorry, is this on?
What's the point of traversing a tightrope when
there's no end to it?
When we started, we had these three core tenants,
and we built them into the company, right?
We wanted to use modern technology
because we were sick of just sticking with the same thing
and never being able to do anything
that was exciting and new.
We wanted to have a different approach
to design and bring in some of editorial design
from my magazine background into web design.
And we wanted to be honest with ourselves and with clients.
As cheesy as it sounds, the journey
is more important than the destination.
Whatever the endpoint seems to be, at one point for us
it was maybe let's get to the first year
and see if we're still alive.
Well, we are.
OK, but then you have a new endpoint, and you get there
and you have a new endpoint.
And so it never ends.
So for us, the important bit is to avoid this--
it's to have a place of work you can actually enjoy,
you don't have to sacrifice your whole life every Monday
and every Tuesday and every Wednesday.
It's to have a place that feels less like a factory
and more like a family.
This is our six staff members and their wives and partners
and their babies and their dogs.
And it's really important for us that I can, for example, go
to the vet with my two dogs if I need to,
or Bart can work from home with his daughter,
or Gordon can kind of take half paternity leave,
half working for a few weeks.
It makes sense because work doesn't just affect us,
it affects our families, and our families affect us, as well.
So this is, for us, right now, this is what it's all about.
This creating an environment where
we can just be happy and do exciting stuff
at the same time.
So we're literally at the end of the talk,
we have one more thing that we want to show you,
and that will be the takeaway from this talk, so here we go.
[MUSIC PLAYING]
Thank you very much.
Thank you.
[APPLAUSE]
Thank you.
Wow, thank you very much.
Please,
Should we sit down?
The comfy chairs, gentlemen.
That's a good challenge.
Quite a few questions.
We won't get time for all of them.
---can sit in the middle.
Just chime in, they're not addressed to anybody,
in particular.
Uh-huh.
And everybody's aware that you're talking about you,
so you're not able to give generic advice to the world.
Sure, you can sit, Bruce.
Cool--
You can sit.
I'm ancient, so I'll sit.
Little bit older.
Code of conduct.
You sacked one client.
In retrospect, when you're thinking back up on the,
presumably, the relatively grisly procedure
by which you sacked them, was there, looking back,
are there any early warning signals
that you look out for now when you have new clients?
I mean it's tricky to know.
To be honest, I wish we'd fired them sooner.
And I think you just start to get a feeling.
It was very positive we first met them,
but then, like I said, I just slowly start to get there.
And I think the early warnings were the first moment when they
are starting to have difficult conversations
and it's starting to get tough, and they're
starting to make noises like, they're not really
understanding what we're doing with our time,
or what they're paying for.
And I think it's tough.
And like I said, you're never actually going
to know what someone's like until you
start to work with them.
But I guess you do have to be aware
that if you're having a relationship with someone
and it is-- you are starting to argue,
it's starting to get tense, then I
think that's early signs that this is not going to last.
And if you're having difficult conversations and arguments
after a month, I don't think you're
going to be able to work with them in six months,
because it's rare that that gets better.
Is that why or that one of the reasons why you adopt an Agile
methods, because presumably therefore you're going back
to the client relatively regularly
and they're aware that you're doing stuff,
you're soliciting input, they can
see they're getting value for the month.
Yeah, that's the idea.
And also that they're getting deliverables
and it's easier to part ways than if you're
trying to fulfill a big specification for six months.
It's easier to just hand over and walk away if you have to.
But yeah, it works very well.
The whole Agile thing works well if we're dealing with clients.
If I might say as well, it's also
a big challenge in terms of the hardest things
to tell a client in terms of Agile
is you won't to get everything you want,
you won't get everything that you want now.
And we kind of say this, and it's particularly difficult
before you won the job, and you go, hey,
we could do a great website, but it won't
be what you think it will be.
It's really difficult. And even though we say it upfront,
it's kind of needs reiterating and that's
a tricky balance between being the negative realist
and a positive agent to work with.
Also, if I may, when you're working
on big software development project, Agile is quite simple.
But if you're working in project that's like only 20 days long,
it's getting difficult then.
Because how do you actually iterate over 20 days.
So that's one of the challenge we see because we've
got plenty of these clients.
I was going to ask that as well, because I imagine
that most people in this room are
familiar, at least, with what Agile is, even if they
don't get to practice it.
But it's a long time since I've done any commercial web design.
But you have any resistance from clients?
What is this?
We're giving you some money.
Come back in six months and give me a website, don't bother me.
Funnily enough, we've found most clients actually like it,
or at least at the point when you're talking to,
pitching to them, they really like that idea.
They like that they're going to be hands-on,
and they like that they're going to be part the processors
and they're going to see what it's like.
So we find actually it helps as a sales tool.
Got you.
[MICROPHONE POPPING]
Somebody's playing the drums, it seems.
Question four Espen and Bart.
Bart, you mentioned that-- I loved your metaphor with coming
up with an Escher picture and him to the developer,
build this.
Is it important, then, Espen, that, at least as a designer,
if you don't code yourself, I don't know if you do,
that you at least are aware of what's
physically possible given the limitations of the web so you
don't dream up something brilliant,
and then Bart goes, oh, fuck off.
Yeah.
I think it not only important so that I
don't dream of something that's impossible,
but if the more I know about SVGs or animations
or JavaScript, if I know that it's possible
and I can just hack it together myself in CodePen or something,
then I start to get ideas, right?
Once you know what you can do with CSS animation,
suddenly you start saying, oh my god, I could do that.
Instead of it being a limitation,
just opens the door completely.
And you do get a sense of what requires JavaScript
and what doesn't, which is, that can
be a big difference sometimes, in terms of budgets,
for example.
If you go back to this elephants picture,
it's really about that, it's about sharing what we know.
And one of the things I really wanted
to do when we started Primate's never
say no to say no to designers, but unfortunately, it's
not the case.
Sometimes we have to go in and say, like, look guys,
is really great, we'd really love to build it,
but we just don't have time for it.
I think one of the rare, one of the few pleasures of being
a developer is disappointing designers, to be honest.
One of the things that makes life worth living.
Last question, because we're running out of time,
is, why Edinburgh?
Have come you're in Edinburgh?
It's a nice place, I'm not dissing it.
I lived Edinburgh because my now wife moved
to Edinburgh 10 years ago.
No, six?
Nine?
Nice years ago?
It's a long time ago, and then I found a job,
and two jobs later I was working with these guys, and then
two years after that we started Primate.
4 and 1/2 years later, I still think
it's some sort of cosmic coincidence that happened.
Because three people from three different countries
meeting in the same company at some point
and just having a chat and thinking, OK,
we going to do it, we going to do it better.
Cheers to happy accidents.
Ladies and gentleman, Mr. Bart, Mr. Espen,
and Mr. Gordon from Primate.
[APPLAUSE]
Thank you.