Things what I writ

I sometimes write nonsense about things to try and sound clever


240/365 by Tim Caynes

whereupon I use words like pivot to articulate the transition from steady as we went to fucking hell what’s going on at this place there’s 17 people in this room I’ve never met before and you know they’re amazing people but how do they know what we do and how did they get here and who knows what on earth is happening these days it used to be so simple we just dropped a couple of resumes around on email and a couple of nods and winks later employee number 34 was up and running and it was like nobody really had anything to do with getting that person in the building they were just there one day and started being perfectly brilliant at what they do and carry on but it’s apparent it doesn’t quite work like that when you’re looking for employee number 213-225 and that’s just this week and wait a minute I’m supposed to be making things not running things.

if the ethos is the craft then the antithesos is the scale and everything heads binwards as creative entropy does some kind cataclysmic crisis acceleration and rather the like relentless pumping of custard into a cheap balloon things don’t so much fall apart as they go on they explode in faces of barely conscious long service award-winners as if to remind them that it’s all their fault that they were so focused on making thing they didn’t even notice they were somehow supposed to be also MAKING THINGS HAPPEN like it doesn’t just run itself you know it’s just fine that you’re busy over there prolapsing over an outcome in the name of CRAFT but for forgot to build a RAFT and I don’t mean like some team-building activity but ironically I mean like some team-building activity but the kind where you build TEAMS and not a fucking RAFT with spaghetti and masking tape as a facilitator called Katie makes sympathetic noises while all you really want to do is break a bit early and go to that mcdonalds on islingtom high street before you get the train back to stratford to tell your partner you built a fucking RAFT when you could be doing CRAFT and they’ll tell you you can’t do it all on your own love you need to take operational control and invest the right people with the decision-making capabilities to enable the studio to grow sustainably and take the logistical overhead away from practitioners and coordinate a measurable roadmap for sustainability that enables you retain the essence of the practice without burning you out love trying to do the CRAFT and RAFT at the same time I mean it will take a bit of change management and some people won’t like it but it’s really the only way and by the way dinner’s ready did you get the paprika no I didn’t I’ve been trying to screen resumes all day ah well there you go that’s exactly what I’m saying love.

should designers learn to teamtailor?

There’s a Package For You

I just opted in to our design documentation standard, to do the right thing. I mean, we always do the right thing, but we’ve not really defined the ‘right thing’ very well up to this point. However, we’re just getting our design process rationalized across the team, including the technology we use to interface with other teams, vendors, agencies etc. We’ve always had the super web design component standards out there, which I’m sure you’ve all seen, but internally, well, it probably isn’t a surprise to anybody out there who is part of a reasonably sized design team to know that there’s always been a number of different ways in which we initiate, manage and deliver our design projects

Not any more. No sirree. The few good people here that have been tasked with coordinating our activities are just starting to cement some of the pieces in place. These are not new ideas. We’ve talked about the need to do this for about 10 years, and in that time, the size of the organization has grown many times its original small, lithe, sexy size. Now, more than ever, we need to be able to track and tune projects on a predictable path, to set expectations, engage the multiple teams you need to engage with these days, and even just understand what the project we’re currently working on actually is (surprising how often you stop in the middle and realize you have no idea what it is you’re supposed to be delivering. That’s not just me is it?. Oops.).

Which brings me to documentation. I’ve always been the kind of rapid prototyping kind of person. If you want to see what the web pages will look like, I’ll write them, and then you can tell me what you think. Context, you see. So what if it takes a bit of work to do the initial set up and a few frantic nights of html hacking to make it look like it will fit seamlessly into the Solutions section, when you know really that it won’t actually look like that because that section is actually implemented on a hack of a content management platform and none of those components will really sit together like that? At least you see it in context. Trouble is, you can’t, as I often found, take that development site to the publishing and engineering teams and just say “I want that one”. They want to know things like “what happens when I click this”, “how many of those can you have”, “has this been reviewed?”. How unreasonable. Its just a mockup, its not supposed to actually work, you know.

Which is where the new documentation standards come in. Some sickeningly efficient folks in our team have been doing this kind of thing the right way for years. You know, they’re the ones who have actually qualified somehow to be a designer. People like me, however, just have never had a clue. So, how serendipitous it is that Creative Suite 3 finally gets delivered to me (after protracted supplier delays), and I get my hands on InDesign, for that is the tool of choice. Our friends at Eight Shapes did a grand job, a while back, of working on a design documentation framework that supports our component set and incorporates “mapping & annotation standards, artifact modularization, and tricks of the trade learned over years of experience” (their words, but they’re the right words). What this means in practice, is that I can now develop fully annotated design specifications, with consistent wireframes, nomenclature, and interaction definitions, which are understood by clients, designers, publishers and engineers alike. This is nothing short of a revelation to me. I mean, it doesn’t actually do the designing for me, so I can still get that hopelessly wrong, but its a huge change for the better on the project and process management front, and its a self-documenting exercise. I also get to learn a new application, which is nice. Oh, and, of course, I get new friends on Facebook, so I now know what Nathan’s Star Wars character is, which is always useful.

Listening Post: White Stripes: Bone Broke