Over the past 8 years I’ve seen numerous friends, colleagues and clients—along with many regular UX London attendees—move from design practitioners to design leaders. Some have taken up leadership roles at agencies or small design teams in traditional companies. Others have risen through the ranks of the tech giants to land senior positions at companies like Google, Facebook, and Twitter.
My role at Clearleft is something along the lines of being a technical director. I’m not entirely sure what that means, but it seems to be a way of being involved in front-end development, without necessarily writing much actual code. That’s probably for the best. My colleagues Mark, Graham, and Charlotte are far more efficient at doing that. In return, I do my best to support them and make sure that they’ve got whatever they need (in terms of resources, time, and space) to get on with their work.
We’re trying something new. We used to update you with weeknotes, which served as news from our working week, but we began to feel that they weren’t a very enlightening representation of the work we do any more. NDAs and various bits of industry red tape prevented us from really being able to show you exactly what we’re up to. So here we are. We’re inviting you to be a fly on the wall at the studio (or some other more glamourous wall-climbing creature). We want to give you a fresh look into the way we work, the things we’re learning and other general antics.
Everybody talks about the challenges of running a fast growth business. However slow growing business have their own unique challenges.
The component/pattern library has proven to be an effective, robust format for delivering documented code and design patterns to our clients. So I thought I’d share a few notes on some lessons I’ve learned from designing, building and shipping various iterations of this format over the years.
One of the objectives of a redesign is to serve up more relevant and useful content to the users. Content has to come first. No?
Some advice for maintaining a consistent visual language throughout agile design sprints.
James and I went to Ipswich last week for work. But this wasn’t part of an ongoing project—this was a short intense one-week feasibility study.
When designing for performance means killing some darlings, making hard decisions and realising that it’s not about the design, it’s about the user.
Culture change. It’s a phrase that’s thrown around with reckless abandon these days. Seems like no matter where you turn everyone is looking for a culture reboot.
Typography - it’s at the heart of the web experience but with so many different options available it’s sometimes hard to know where to start when designing. Font stacking, embedding or web fonts? And what’s more important, brand or user experience? And what does this all mean for the designer who just wants to try and make type look great across as many devices as possible without losing their mind?
This week we hosted the Agile SwapShop meet up at Clearleft, and had around 20 people come along to the session. With such a large group of people, and the emphasis being on discussion rather than presentations, it was important to find a method to allow everyone to get involved and provide a useful structure for the conversation. We decided to try out the Lean Coffee method.
A couple of weeks ago we held the second in a series of Roundtable events, where we invited UX leads, product owners and creative technologists from organisations like The Guardian, Auto Trader, RBS and Pearson who are at varying points of the journey of going responsive; to share experiences, troubleshoot, debate and share ideas.
Or why you should be asking “What’s the point?” Design for objectives not for goals.
Andy’s been playing Devil’s Advocate again, defending the much-maligned hamburger button. Weirdly though, I think I’ve seen more blog posts, tweets, and presentations defending this supposed underdog than I’ve seen knocking it.
It’s tempting to think of testing with screen-readers as being like testing with browsers. With browser testing, you’re checking to see how a particular piece of software deals with the code you’re throwing at it. A screen reader is a piece of software too, so it makes sense to approach it the same way, right?
Let's discuss your next project
From simple questions to complex queries, we’re happy to chat about a partnership tailored specifically to your needs. Call the studio at +44 (0)845 838 6163 or email us directly.
If you have a bit more time, why not download our Client Worksheet. Fill it in and send it back. We’ll take a look and give you a call.