Blog Category: design
Designing a good portfolio
It’s 1998 and I’ve just arrived in Bangkok and it’s 90F at night. I’ve arrived at a small hostel just around the corner from the Khao San Road and, just like everyone else travelling or on a gap year, I’m a walking stereotype. From my flip flops, overly loose trousers, consumption of banana fritters and cheap Thai beer. Oh, and well-thumbed copy of The Beach.
Like I said; a walking stereotype. Except for lugging around the 2kg A3 sized portfolio case rammed into my already weighty backpack.
It’s 1998. The web is still in its infancy, but it’s there and pretty good. Fireworks was on version 1. I used Internet Explorer 5 and Eudora The first iMac had been recently released. Not really the dark ages, but here I am, lugging around an additional 2kg of dead trees for two months around South East Asia. Why? Well, I wanted a good job when I got to Sydney. And, as a designer, a good portfolio – or ‘Book’ as it’s called in advertising – would get me one.
Let me back-peddle a bit to my first job as an intern at an ad agency in Manchester. There worked an Art Director called Tom. Tom was quiet mannered, quick to smile and laugh, and much quicker to point out a small opportunity for improving a design. Together with the other Art Directors, he taught me about hierarchy and how to make type fit on a page (this was a distinct problem when designing plumbing catalogues). But he also taught me the value of a good Book. How to design one; how to tell a story through your work; how to present your work and do enough in the portfolio to get you a foot in the door which is what junior designers needed so much back then.
“Leave your book and pick it up tomorrow”
My experience of looking for a job early in my career was probably quite usual amongst my peers: I never replied to a job advert. Instead, I was encouraged to get together a list of the places I’d like to work and then to sell my portfolio around them. So, there I was; fresh out of school, full of ‘I got a First Class honours degree’ confidence selling myself from agency to agency. It was a baptism of fire. I remember the first day was particularly horrific. Out of the six or so agencies I’d arranged to visit, only one was happy to let the art director see me rather than just leave my Book and pick it up tomorrow. And then, my work was systematically ripped to shreds by an Art Director with too little time on his hands.
Now, this isn’t meant to sound like ‘oh, woe was me and my hard time finding a job’. But, I am trying to recall how my portfolio was the start of a conversation. And, generally, a conversation I wasn’t there for. I didn’t really plan for that so had to adapt the work to invite that second meeting.
Oh, those soft skills
So much of what we do is working with people. Sometimes, though, I think I need to have experience in counselling or negotiation tactics in order to usher through design changes which impact organisations at their core. It’s difficult work. And, if you’re not the type of person who like talking to other people, then the impact of your work will only go so far. The question is, how do you demonstrate this in your portfolio? How can you demonstrate the value of design games, or collaborative moodboard exercises? Or that it took six months of negotiating with dozens of facets of an organisation in order for a content strategy to be adopted? My advice would be to write a story. Show photographs of workshops. Demonstrate how you approach these things. List the methods you’ve used and those that have worked. List those that haven’t and the reasons why.
This may seem odd for a portfolio, but if you think about it, design agencies have been doing this for decades. This is because they have similar problems. A lot of agencies sell the process of design, not the end result. In order to charge money for things like strategy, research, collaboration and what-not, all of which is difficult to show in a piece of design, they have to demonstrate it in other ways; case studies, stories, photographs. Packaging the work to show the full range of what was worked on.
A few pointers Tom gave me (and a few of my own)
Let me take you back to Manchester in 1995. I think it was early in a week in July. It was probably raining, as is usual in my home city. Anyway, Tom and I are discussing university and where I’d like to work and doing what. I start talking to him about my final year and the projects that await and he begins to advise me on not leaving my portfolio work too late. That I should be working on it throughout my final year and how I shouldn’t under-estimate the amount of work it will take. A year! Surely it couldn’t take a year, I said. It’s just a dozen prints after all. ‘No’, he said. ‘It’s probably the most important piece of work you’ll do in your final year, and one you won’t get marked on until you try and find a paying job’.
Over a nice hot cup of tea, he and I chatted for an hour or so about what makes a great portfolio and all of the things he considers when a dozen or so would land on his desk every single week. At the time, this was for a print portfolio, but looking at these now, you could easily see how they’d apply to all types of portfolio, including those for a small studio or agency.
Here are the highlights…
Who was the client? When did you work on this. What was the Date? What was your role? What was the value to the client? But keep this brief. This meta data way-finding is important when skimming through a portfolio.
Show a progression
Show work that didn’t cut it. Demonstrate your ability to change and iterate and show variance to get to a solution. This also demonstrates your graphic design capability, copywriting, and visual thinking.
If you worked under a senior, say so. Talk about why projects might not have been completed. Honestly, if you bend the truth, it’ll catch up with you at some point.
If your work is just a bunch of posters, of a certain type of client or work, then it’s easy to pigeon hole you. If you just design icons, that’s the type of work you’ll get. Demonstrate breadth, even if it means working on your own side projects or setting yourself your own briefs.
Fewer and better
Be very, very picky about what you show. If you only done three projects you are really proud of, then just show them. Talking passionately about how it went, what your contribution was, and what happened after it was finished will shine much brighter than ten single pieces of work. It’s easy to spot things made with care and love, even those commercial projects that fell short of the mark (and it’s ok to say that if you know the reasons why).
Walk the walk
If you can code, then demonstrate it. If you can’t, be clear about why you don’t think that’s applicable for your role and growth. Either way, conviction in your own abilities or not will tick boxes.
Work is more about pictures
The big difference between junior designers on the web and print is quite stark, but the more experienced you become, the roles become similar. It becomes less about pretty pictures, and more about facilitating a process from beginning to end. Think about how you can convey something before hand that isn’t a picture. This is where writing about your work trumps showing pictures. Because sometimes there just aren’t any pictures to show.
And, the last point I think nicely rounds off this post.
It’s the start of a conversation
This was applicable when I started my first job, when I ran a small agency, and now I work in-house at Monotype. Any portfolio is the start of a conversation. It needs to invite discussion, further questioning, and that all important call-back.
Going back to that stereotype traveller type, wandering around Asia with an extra 2kg in his backpack… Well, I arrived in Sydney. I had a very short list of studios I wanted to work for and proceeded in doing what I’d done before: making myself a nuisance until I had the opportunity to either leave my Book, or talk it through with someone. I managed to get the job I wanted with a great little company in Sydney called Spike. It was my first web design job. All thanks to Tom and his advice. And a sturdy rucksack.
A Design SDK
A software SDK is a set of tools that allows the creation of applications for certain software, or video games, or a hardware platform. A hit could be as simple as a bunch of APIs or software that talks to embedded or proprietary systems. An SDK is a collection of tools to make something with. It’s a leg-up for development. And they’re needed for design, too.
Guide me, don’t tell me
When working with identity guidelines, pattern libraries, or styleguides, the biggest pushback I hear from designers is ‘I don’t want to be this specific. Point me in the right direction, but don’t be prescriptive’. The chances of a pattern library or styleguide answering every design problem that comes along is slim, but providing an overall understanding of a system is probably the best position you can put a designer in in order for them to do good work. That, and providing them with the right tools.
Giving someone a design SDK may be better than asking people to look for, navigate and understand an entire website dedicated to your design language.
For example, let’s say you work for a large bank in their in-house design team. Your design language is years old and grown organically to become a place of internal collaboration for stakeholders and silos – not really the place for external suppliers. One day, you need to get a very small web project designed and your team is maxed out so you outsource it to a freelancer. Now you’re faced with a problem.
Your design language documentation and collaboration site is housed internally, behind the company firewall, and you can’t give her access. You try to collect some material together for her, but it takes all morning before you even have an idea of what might be needed. And then you can’t find the logo in the right format. All you really need to do is send her what is needed and nothing more.
All of this takes too much time. And a styleguide doesn’t solve the problem. A design SDK is what you need.
A style guide is about providing the right help for every use case all in one place. An SDK is about providing the right help for a specific environment. In software development, APIs may have middleware wrappers like a PHP and Ruby. But regardless of the wrappers, the endpoint is always the same: the software at the end of the API. In the same way, a Design SDK should provide an end-point — a design language — typically via different methods such as HTML and CSS, or Sketch files, or Photoshop files, or text documents, or InDesign swatches.
The key to this is to be where the designer is. Learn where your designers and design partners do their work and provide tools that help get your design language adopted in those tools.
The problem with style guides
Style guides can be great for documenting a design system and providing a way for design to be consistent across multiple projects, products and people. But they can also be a shackle for creativity. A firehose of difficult to navigate content that compromises clarity for brevity. The key thing with style guides is they rely on you going hunting for what you need. They are everything for everybody. They are pull rather than push.
A design SDK I’m talking about is push rather than pull. It’s given to you, and it contains just what you need and nothing more.
What would be in a design SDK?
The key here is to provide just enough for someone to get going with their work. For some projects, this may be all of the following, but for others, it could just be a couple.
- Moodboards and inspiration
- HTML boilerplate
- CSS or Sass snippets
- Template assets
- Suitable example images
- Icons in various formats
- Licensed typefaces or links to the correct typefaces
- Branding identity guidelines
It would be ideal for me if an SDK could be created on the fly for different people based on project needs. So, for example, for freelancer ‘A’, I don’t want to send them HTML or CSS as I know they’re not building anything, so I just send them mood boards and inspiration, image assets and branding guidelines. For freelancer ‘b’, a front-end developer, I send boilerplate, CSS, template assets and icons. I mix and match and provide the design SDK, rather than send along a URL and expect them to know what they need and how to use them.
‘Isn’t this just for big, in-house teams and projects?’
No, I don’t think it is. There were plenty of times when I ran my design agency that we could use a design SDK as a deliverable for a client. Because, after you have finished working with them, chances are they will need other people to take forward your design in one way or another. And maybe the client isn’t the best person to determine what is needed to do that. A design SDK would be a great deliverable to ensure design integrity is maintained after you move onto other projects.
Visual Design might be a thing
If you recall, a few years ago, I wrote about my belief that the term ‘visual Design’ was propagating through the UX community and the potentially damaging effect that was having on the problem-solving roots of graphic design practice. This was swiftly followed up by a longer piece for The Manual.
I’ve had a lot of comments from people since then – either agreeing or disagreeing (y’know, the web) but over the past six months or so I’m coming around to the idea that Visual Design might actually be a thing. It’s just incredibly rare and is dependent on a number of rarely addressed factors.
Following the problem
Michael Bierut explains in his piece ‘You’re so Intelligent’ that graphic design has long suffered from what he calls ‘Problem Definition Escalation’:
Like many designers, for years I used a tried-and-true tactic to hoist my way up the respect ladder, a technique I will here call Problem Definition Escalation. If you’ve listened carefully to the lyrics to “Gee, Officer Krupke” in West Side Story you already know how this works. The client asks you to design a business card. You respond that the problem is really the client’s logo. The client asks you to design a logo. You say the problem is the entire identity system. The client asks you to design the identity. You say that the problem is the client’s business plan. And so forth. One or two steps later, you can claim whole industries and vast historical forces as your purview. The problem isn’t making something look pretty, you fool, it’s world hunger!
This behaviour is everywhere I’ve looked and worked for my whole career. From designers to content strategists, product managers to researchers. Almost always though, unlike Mr Bierut, I don’t think this is a need to elevate ones self through any sort of professional low esteem. I like to look at this a different way.
This is a result of people trying to find the problem. It just so happens the problem is rarely the logo.
From board room to your users and everywhere in between
If you think of Visual Design as being on top of a stack of other activities and functions, it might look something like this:
- Visual Design
- Customer needs / Value proposition
- Board of Directors / Leadership
- Organisation environment / culture
‘Stuff’ of course is a big, fat catch-all for all other tactical product design and development.
Customer needs have to be balanced with the product value proposition and opportunity. This is built up on a capable and supportive leadership team. But the bottom layer is probably the most important of them all. The environment.
The environment has to be right for all of the other things to happen. Unfortunately, ‘environment’ or company culture is hard to define and replicate. But how we use processes – such as agile, or defining market opportunities, through to how you refer to customers and evaluate designs - is probably the most important of them.
The Problem Story
It wasn’t until I saw Leisa Reichelt talk through how the UK Government Digital Service team work – from the Creative Director through to the developers and researchers – that I saw a corporate culture and structure where Visual Design could be a thing. Why? Because the problems had been defined, researched, worked through, solved, iterated upon in the layers below. Doing this means that probing the problem results in answers quite quickly. And the more the problem is probed, instead of it all unravelling, it builds into a cohesive narrative. The problem has a story that can be easily tracked back.
Visual Design might be a thing
If the problem has a story that can be traced back, the environment is supportive, and answers are available, then I can certainly see instances where designers learn not to go hunting for the problem. And, thinking about it, I wonder if this behaviour is more probable in in-house work, rather than agencies? Why? Because agency designers are used to clients coming to them with bigger problems than they initially present. This is how agencies generally get more work from larger clients – we follow the problem and, together, make projects to address them.
But, anyway, back to visual design.
If the problems are solved. If the designer is used to not going hunting for the real brief. Then, and only then, I think visual design could be a thing. When a designer has the right information, is working on the right graphical problem where she can focus on, what Michael Bierut describes as:
our miraculous fluency with beauty, our ability to manipulate form in a way that can touch people’s hearts… the gifts that matter, and the paths through which we create things that truly endure.
Yeah. Maybe that’s when visual design might well be a thing.
My Handbook – Environment
I’ve been doing a talk this year called ‘My Handbook’. it’s a rather silly little title for a bunch of principles I work to. They are my ‘star to sail my ship by’, and I’m going to start documenting them here over the coming months, starting with Environment – a post about how, for me, design is more about the conditions in which you work.
I’d describe myself as an armchair mountaineer. I enjoy reading about man’s exploits to get to the roof of the world, or to scale precipitous walls under harsh conditions for no other reason than the same reason George Mallory said he was climbing Everest: ‘Because it’s there’.
In any expedition to a mountain, great care and consideration is taken over the kit, the climber’s skill, the team around them, the communications, the list is seemingly endless. But, the biggest single factor in a successful trip are the conditions of the mountain. Will the mountain let them up. And back down again. Assessing the condition of a mountain takes experience, time and careful consideration; it may be snowing, too warm, too much snow on the ground, too cold, too windy. The list of variables is endless, but the climber considers all of them, and if necessary moves to adjust the route, or simply doesn’t attempt the climb.
Now, let’s shift to design – not necessarily web design, but commercial design of almost any kind. Let’s say you take a brief for a project, you begin the work and suddenly in the project, other stakeholders come on board and start to have comment on your work and direction on strategy that was unknown to you. We’ve all had projects like those, right? Suddenly, your work becomes less about what you may think of as ‘design’, and more about meetings, project management, account management, sales, production work. You know, all of those things that have a bad reputation in design. Meetings are, apparently, toxic. Well, I’ve started to look at this in a different light over the past few years.
As I’ve grown as a designer, like many, I’ve found myself doing less ‘design’. Or, rather, less of what I thought was design. Five years ago, I thought design was creating beautiful layouts, or building clean HTML and CSS, or pouring over typefaces for just that right combination. Now, this is design. But, so are meetings.
Experienced designers spend time making the environment right whilst they are doing the work. Because, frankly, you can push pixels around forever, but if the conditions aren’t right for the work to be created and received by the client in the right way, the work will never be as good as it could be. But, what do I mean by ‘conditions’? Here are a few practical things:
The physical space: I see a large part of my job as making the environment in the studio as conducive as possible for good work to happen. That means it’s relaxed, and up-beat. Happy people make good things.
A Shit Umbrella: It’s my job to be a filter between client and my team on certain things. Someone recently described this as being a ‘Shit Umbrella’.
Politics: Wherever you get people, you get politics – because people are weird. I spend a lot of time on client projects trying to traverse a landscape of people to understand motivations, problems, history or direction. Once you understand the landscape, you can assess, and work to change, the conditions.
People first, process second: We fit the processes to the people rather than the other way around. Our team runs things that works for us, but that’s the result of a lot of trying & discarding. Like tending a garden, this is a continual process of improvement.
Just enough process: I’m a firm believer in working to the path of least resistance. Being in-tune with how people work, and changing your processes to suit, helps create a good environment. But we ensure we impose just enough structure. To much, and it gets in the way. This doesn’t work if you don’t do the previous point, in my experience.
Talk. Do. Talk.: It really is true that the more we talk, the better work we do. We talk in person, on Slack, on Skype, on email. Just like meetings, there is an industry-wide backlash against more communication because the general consensus is we’re getting bombarded. But recently, we’ve been working to change that perception in the team so that talking, and meetings, and writing is the work. It’s tending the garden. Making the conditions right for good work to happen.
Making things is messy: This is actually another point from my ‘handbook’. Since the 1950’s clients and designers have been sold a lie by advertising. Design generally isn’t something that happens from point A to Z with three rounds of revisions. It’s squiggly, with hundreds or thousands of points of change. A degree of my time is spent getting people – clients, internal clients, the team – comfortable with the mess we may feel we’re in. It’s all part of it.
I see all of this as design work. It’s also my view that much of the disfunction from large agencies to other organisations is that this work isn’t being done by designers because they don’t see it as the work. It’s being done by other people like account managers who may not best placed to get the conditions right. Designers need to take responsibility for changing the environment to make their work as good as it can be. Sometimes, that means sitting in a board room, or having a difficult discussion with a CEO.
Mountaineering is so often not about climbing. You may do some if the conditions are right. Design is so often not about designing beautiful, useful products. But, you may do some if the conditions are right.
Creating moodboards is something I was taught from a very early age. In primary school, they were a simple mixed-media way of expressing a form of an idea.
The thing I find interesting about mood boards is not the end-result, but the process of creation. Watching my children make posters from torn up bits of newspaper and magazines is really no different to watching my clients do it. Similar to watching other activities – such as affinity sorting, or depth interviewing – it’s the listening that I find interesting. Every moodboard tells a story, and as a designer, listening to your clients tell that story when they make them can be very insightful.
Making moodboards for you, not for me.
I have to be honest, I don’t make moodboards for myself. Not physical ones anyway. When I familiarise myself with a brand, or make some suggestions for design context, I always try to place those things in a context the client understands. This is where design visuals are important. They are almost unsurpassed in their immediacy of understanding for a client because they show the design in context. Of course, replace that with a high fidelity prototype, and you get the same thing. But, I want to step back a little here, as to when I find creating moodboards valuable.
Let me ask you a question: how many times have you heard this from a client?
‘I’m not so sure I think the design is heading in the right direction’. ‘It needs more pop’. ‘It’s just not us’.
These are all because a client cannot communicate about design at the same level we do. So, it’s abstract. Either that, or:
‘I don’t like that green’. ‘That button is great! But, it needs more pop’. ‘The logo needs to be bigger’.
Then things get subjective and extremely detailed. Why? Because these are approachable things people can comment on. More often than not, these comments are a failing that should rest firmly on our shoulders. We need to give our clients the words and understanding to express their thoughts. Either that, or we tease out these issues earlier in the process, in a way that is abstracted from the design work that will come later. This is where I feel collaborative moodboards work extremely well.
So, why would want to try and run one of these sessions?
When a client’s brand is repositioning, sometimes we’re brought in very early on the back of a strategy. No tactical work as been done. So, it’s up to us to navigate the waters of implementing the branding strategy. Making design work on the back of a few bullet points in a slide deck can be challenging.
Usually in a discover process, I will get a few red flags from speaking with a client. Generally these come through when talking about competitors, or things they like.
When I get conflicting stories from different stakeholders. The homepage team has a completely different view on the branding than the marketing team.
When branding needs evolving. A lot of organisations have mature branding collateral for print and advertising. Not so much for web (still!), so these are useful exercises to start to tease out differences or how they can align to the web in future.
I’m sure there are more, but those are few I can think of off the top of my head for now.
How to run a collaborative moodboard session
- Get the stakeholders in a room. 3-4 is ideal. 9 is way too many.
- Bring with you lots of magazines, newspapers, flyers – just physical paper stuff – that you can all cut up.
- Glue. Lots of glue. One tub each.
- Large (A1) pieces of paper.
The thing about this that I find interesting from a people-watching/behaviour perspective, is that the act of cutting things up and sticking them down is something that most of these people wouldn’t have done since school. The process involves collaborating, getting stuck-in and discussing the work. I find it a great leveller for the client team (hierarchy quickly disappears), and a very good ice breaker.
You set the brief for the morning/afternoon (all day is generally too long for the making part of this process). The idea is to find content that communicates part of the visual story of the product – and that could be anything:colour, type, texture, image – and stick it down.
For the agency team, it’s our job to ask questions throughout the day. To tease out the insights as people are in the moment of choice – before they’ve had chance to post-rationalise. And you know what? Answers like: ‘I just really like this green’ are great, because our next question is ‘Why?’ and it forces rationale. Without us being there, and asking that, almost always post-rationalising and ‘business stuff’ gets in the way of finding the truth behind those choices.
Quite often, just like cave paintings, moodboards are an artefact of a conversation. We often discard them from this point because they have served their purpose. We have the insights. The marketing team are best buddies with the homepage team. We all heading in the same direction.
So, next time you start a project and you need some steer on branding, or reconciling differences of opinion on a client team, try collaborative moodboarding as a way of coming together to try and solve the problem.
Responsive Web Design – Defining The Damn Thing
Unlike many design disciplines, web design goes through cyclical discussions about how to define itself and what it does – anyone who’s ever spent any time in the UX community will know about this.
In 2010, I attended An Event Apart in Seattle. During that show, I saw three or four presentations – from Eric Meyer, Dan Cederholm, Jeremy, and of course, Ethan. All of them, independently, talked about how using media queries and CSS we could change the content using a fluid layout. It was a perfect storm, and indicative of the thinking that led Ethan to write – and A Book Apart to publish – Responsive Web Design a year later. The rest, they say, is history.
Responsive Web Design had a simple formula: fluid grids, media queries and flexible images. Put them all together, and your web product will be responsive. As Jeffrey said:
If Ethan hadn’t included three simple executional requirements as part of his definition, the concept might have quickly fallen by the wayside, as previous insights into the fluid nature of the web have done. The simplicity, elegance, and completeness of the package—here’s why, and here’s how—sold the idea to thousands of designers and developers, whose work and advocacy in turn sold it to hundreds of thousands more. This wouldn’t have happened if Ethan had promoted a more amorphous notion. Our world wouldn’t have changed overnight if developers had had too much to think about. Cutting to the heart of things and keeping it simple was as powerful a creative act on Ethan’s part as the “discovery” of #RWD itself.
The idea of responsive design has taken a few years to go from cubicle to board room. But now it is a project requirement coming directly from there. For the past eighteen months, at Mark Boulton Design, we’ve seen it as a requirement on RFPs. And with that, it brings a whole other set of problems. Because what does it mean? Hence, we have to Define The Damn Thing all over again. And recently, to be honest with you, I’ve stopped doing it. Because, depending on who you speak to, responsive web design has come to mean everything and nothing.
There are some who see it as media queries, fluid grids and scalable images. There are those who see it as adaptive content, or smarter queries to the server to make better use of bandwidth available. There are those who just see it as web design.
Me? I think it’s just like Web 2.0. And AJAX. It’s just like Web Standards (although to a lesser extent) and exactly like HTML5 (in the minds of those of you who aren’t developers) and its rather splendid branding. Responsive design has grown into a term that represents change above all else. To me, responsive design is more about a change in the browser and device landscape. A change in how people consume content. A change in how we make things for the web. And responsive design is just the term to encapsulate that change in a nice, easy solution that can get sold to a board of directors worrying about their profit and loss.
‘Responsive design is forward-thinking and means it will work on a phone, and that’s where things are headed’.
We’ve heard this line time and time again over the past couple of years. You see, responsive design is a useful term and one that will stick around for a while whilst we’re going through this change. How else do we describe it, otherwise? Web design? I don’t think so. No board member is going to get behind that; it’s not new enough.
How we work
I’ve had a few people ask me recently about how we work at Mark Boulton Design. And, the truth be told, it slightly differs from project to project, from client to client. But the main point is that we work in an iterative way with prototypes at the heart of our work every step of the way.
Work from facts AND your intuition
We always start by trying to understand the problem: the users of the website or product, the organisation on their customer strategy, the goals and needs of the project, who’s in charge and who isn’t. There’s a lot to take in on those early meetings with a client. One of the first things we do is to try and put in place some kind of research plan: what do we need to know, and how are we going to get it.
This could be as simple as running some face to face interviews with existing or potential customers coupled with a new survey. Of course, good research should provide some data to a problem, not just ‘what do you think of our website?’. Emma has written some good, quick methods for doing this yourself.
We couple that with trying to extract the scope from the client. I say that because, half the time, we’re given a briefing document – or something similar – and most of the time that document hasn’t been written for us. It’s been written for internal management to sign off on the budget of the project. So, rather than ask for a new document, we run a couple of workshops to tease out those problems:
User story workshop
This workshop is designed to tease out the scope of the project – everything we can think of. We ask the client to write user stories describing the product. Nothing is off the table at this point and our aim is to exhaust the possibilities.
Persona / user modelling workshop
Personas have been called bullshit in UX circles for years now. Some say they pay lip-service to a process, or they’re ignored by organisations. Whatever. I think, sometimes, something like personas are useful for putting a face to that big, amorphous blob of a customer group. Maybe that’s just a set of indicative behaviours or maybe a lightweight pen-portrait of an archetypical user. The tool is not the important thing here, but how you can use something to help people think of other people. To help an organisation to think of their customers, or designers to think of the audience they’re designing for, or the CEO to think in terms of someone’s disability rather than the P&L.
What I find generally useful about running a workshop like this is that it exposes weaknesses in an organisation. If a client pays lip-service to a customer-centric approach, it will soon become very evident in a meeting like this that that’s what’s going on.
This is a vital workshop for me. As a design lead on a project, I need to understand the tone of a company. From the way it talks about itself, through to the corporate guidelines. But, my experience is, that’s only half the story if you’re lucky. So much of a brand is a shared, consensual understanding in an organisation. Quite a lot of that can go un-said. This workshop is, again, about teasing out those opinions, views and arguments.
The first three workshops have the added bonus of finding out who runs the show in an organisation. I make it my business to find out – and get on side – the following people:
- The founders / CEO. This should be a given.
- The people with a loud mouth. It’s useful to find the people who have a loud voice and get them around to our way of thinking. Then they can shout about our work internally.
- The people with influence. Sometimes, these are the quiet, unassuming people, but they carry great sway. If we want things done, these people need to be our friends.
That’s quite a lot of people to keep happy, but if we get these three groups on side, we find projects run a lot smoother.
Prototype your UX strategy
Leisa gave a great talk at last year’s Generate conference in London about prototyping your UX strategy. The crux of this was it is way more efficient to demonstrate your thinking and design, than it is to talk about it. If you can quickly make something, test it, iterate a bit, and then present it, then you can massive gains to cutting down on procrastination and cutting through organisation politics like a hot knife through butter. Showing that something works is infinitely more preferable to me than arguing about whether something would work or not.
Wherever possible, we’ve been making prototypes in HTML. It gives us something tangible and portable to work with. We can put it in front of users, show a CEO on their mobile device to demonstrate something.
The right tool at the right time
I’ve spoken before about designing in the browser, or designing in Photoshop, or on pencil, or whatever. Frankly, we try to use the most appropriate tool at the right time. Sometimes that’s a browser, but a client may respond dreadfully to that because they’re are used to seeing work presented to them in a completely different way. Then, we change tack and do something else. My feeling is the best design tool you can use is the one that requires the least amount of work to use: be it a pencil, Photoshop or HTML.
agile not Agile
I feel that design is a naturally iterative process. We make things and then fix things as we go. Commercial design, though, has to be paid for. And so, in the 1950’s, the Ad industry imposed limits to this iteration – ’you have three changes, then you must sign off on this creative’. Of course, I can understand this thinking; you can’t just get a blank cheque for as many iterations as you like for a project until something does (or does not) work. But, what we gain in commercial control, I’ve found we’ve definitely lost in design quality. It takes time to make useful, beautiful things.
So, from about 2009, Mark Boulton Design have been working in the following way:
We work in sprints that are two weeks long. We never have a deadline on a Friday. Sprints run from Monday to Monday, with a release end of play Monday.
‘Releases’ are output. Sometimes code. Sometimes research. Sometimes design visuals.
We front-load research into a discovery sprint. This is to get a head-start and give the designers (and clients) some of the facts to work around. Organising, running and feeding back on research takes time.
Together with the client, we capture the scope of the project with user stories. These are not typical Agile user stories – for example, we don’t find estimating complexity and points, useful in our process – but they are small, user-centred sentences that describe a core piece of the product. It could be a need, or a bit of functionality, or a piece of research data. The key point here is, for us, they are points of discussion that are small and focussed. This helps keeps us arrow-straight when we prioritise them sprint on sprint.
We conduct research each sprint if it’s required. This is determined by the priorities for that sprint. For example, if the priority for the sprint is focussed on aesthetics, or typography, or browser testing, then usability testing is not going to be of much use for those.
And now for some of the commercial considerations:
Contracts are most often fixed-price, but broken down into sprints. Each sprint has an identical price.
We bill as we go. The client pays a degree up-front, and that is then factored into cost of each sprint.
We explain to prospective clients how we work: each sprint, we work on agreed priorities, with no detailed functional spec to work against.
Points. In the past, we’ve worked on Agile agreements where we would be delivering against agreed estimated points. This was to see if we could make web development agile work in a project environment. It didn’t. We found we were delivering to the points, rather than to the project. Plus, if we didn’t hit the points for that sprint, we were penalised financially.
Coaching our clients through this process is as challenging as coaching through clients of a responsive design project. When the project is in the early-mid messy stages – when client preconceptions are being challenged, the prototype is not being received well by users – it takes a strong partnership to push through it. Design is messy. Iteration, by it’s very nature, is about failing to some degree or another. Everyone has to get used to that feeling of things not working out the way they first thought.
The sticky end. When we get to the final stages of a project, we should be in a good place. The highest priority items should be addressed, we will have buy in and sign off from the right people and we should be focussed on low priority features. But sometimes, that’s not the case. Sometimes, we’ve got high priority things left over which are critical. And that’s the time when we have to go back to the client and discuss how these need to be addressed. Sometimes that’s an extra sprint or two. Sometimes it’s an entirely new contract.
What we don’t do from ‘Agile’
We don’t do:
Estimating tasks. We don’t assign time to design tasks. In our studio, work just doesn’t happen that way. Generally, things are a bit more holistic.
Tracking velocity. For the same reason above, if we’re not measuring delivering against user stories in a numeric way, we can’t track our velocity.
Retrospectives. We don’t run traditional retrospectives on sprints. Maybe this is more a symptom of a close, high-communication level of our team. We’re talking all the time anyway. We have found that retrospectives have been a useful forum for clients to feed back on how they’re feeling about progress in the past, but this has felt like a somewhat forced environment to do it. So, recently, we have points of checking in with a client to see how they’re feeling about things.
So, that’s about it. A whistle-stop tour of how we like to work. As much as possible, we’ve tried to tailor our process to what works for us, built on some useful structures that agile gives us. I guess the most important thing for us is that we’re not wedded to our processes at all. We regularly shift focus, or the way we work, to meet the needs of particular clients or projects. Just as long as we align those processes to how design naturally happens, then I’m happy.
Al Jazeera & Content shelf-life
From speaking at the phenomenal MK Geek Night All Dayer, to launching a project three years in the making for Al Jazeera, the releasing a new design language for one of the oldest university in London, to Mark Boulton Design being nominated in four categories in the Net Awards. It’s been a busy couple of weeks.
Last week, I was up in London visiting a client when I heard that another project of ours was to be launched shortly. It was part of a project we’ve been working on for just over three years: the global design language for Al Jazeera Network digital, with the first two products being launched in Turkey and a beta of the Arabic news channel.
There is so much to talk about on a project of this scale. Here are just a few highlights:
- Spending time with journalists and the newsroom to understand how news is reported.
- Working with Al Jazeera during the Arab Spring; from the uprising in Egypt to Libya.
- Course-correcting throughout the project. Responsive Design wasn’t really a thing three years ago.
- Designing in four languages – Arabic, English, Turkish and Slavic – when the MBD team primarily speaks one.
- Adopting an Object Oriented approach from content through to code. Modular, transferrable and scalable. It required a level of detailed thought right down to how content types were defined in the CMS.
- Working with three development partners across three independent content management systems.
I could go on and on. And I probably will at some point. Needless to say, none of the above could achieved without a patient, smart and agile client-side team. Good job the Al Jazeera team are just that.
There are many buzz words you could label this project with: content-first, responsive, atomic, OOCSS. Again, I could go on. But the one thing that was first, central and always through prototyping and early strategy was good research. It was a research-first project. That probably won’t come as a surprise to some of you given we have our own in-house researcher, Emma. What may come as a surprise, however, is the degree in which that early research led approach laid the foundation for a fundamental shift in how Al Jazeera thought about their content.
Many news journalists think of their content as a few distinct types:
- Rolling news: Typically taken straight from the wire and edited over time to fit the growing needs of the story.
- Editorial: Longer form piece. Still highly topical and timely.
- Op-ed: Opinion piece from a named author.
- Feature: A story. With a beginning, a middle and an end. Long-form content, and not necessarily timely.
These can all be mapped to timeliness; both in terms of how long they take to create and their editorial time-life. The more timely a piece, the shorter it takes to create and the shorter the shelf-life.
- Rolling news: timely, short shelf-life.
- Editorial: timely, long-form, short to mid shelf-life.
- Op-ed: Long-form, mid shelf-life.
- feature: Long-form, long shelf-life.
Publication schedules are often focussed around this creation with journalists having several pieces of the different types in various degrees of completion to various deadlines focussed on different stories. This is a comfortable mental model, one that newspapers have been arranged around for decades. But it isn’t necessarily how users of websites look for content. Users will not typically look for a type of content, but will look for a context of a story first: the topic.
The new information architecture of the Al Jazeera platform has been built around a topic-first approach. But also, the modular content and design allows for the rapid changing of display of the news as a topic or news story moves through the various content types. It’s a design system, connected to a CMS that accommodates what news naturally does. It changes.
The Design System
The whole platform is built on top of Gridset using modular design principles. The content is modular and multifaceted, designed for re-use, as is the design. For years now at Mark Boulton Design, we’ve not designed websites, but an underpinning design system with naming conventions, rules, patterns. This is particularly useful when many CMS software thinks of content objects in this way. Our systematic thinking can applied all the way through CMS integration. Software engineers love designers giving them rules.
It’s funny, we seem to have just discovered this in web design, but many other design disciplines have been approaching their work in this way for decades. Some for centuries. Take typography, for example. The design process of creating a typographic design is systematic thinking at its purest. Designing heading hierarchies and the constituent parts of written language can be approached in an abstracted way. This is exactly the right approach when designing for other languages.
Arabic has obvious challenges for an English-speaker. Not only is it written right to left, but the glyphs are non-roman. To approach this as a English-speaker, we needed to create tools and process to help. Words no longer look like words, but shapes of words. Page designs no longer look like familiar blocks of text, type hierarchy and colour. We saw form more than we saw function.
Just the start
Three years is a long time to work on a project. I’m so delighted to finally see the design system in the wild. For such a long time, we only saw it in prototype form, but you can only take prototypes so far. We needed to pressure-test content types, see where it breaks, adjust a hundred and one small details to make it work. All of this just underpins the fact that now the system is being rolled out, there needs to be changes made every day to evolve the system. This is the web after-all. It’s a feature, not a bug.
In my fourth article for 24ways over the years, I wrote about typesetting the right rag.
One of the first little typesetting trips I was taught – in my internship at an advertising agency – all those years ago, was how to make text fit within a given space, but still read well. This involved a dance of hyphenation, letter-spacing, leading and type-size. But a crucial ingredient of this recipe was the soft-return.
Scanning a piece of text I was looking for certain criteria – or violations – that needed a soft-return (or, in Quark XPress, shift-return). Using those violations, I would typeset the right-rag of the piece of text, and then use hyphenation, and what-not, to tease the rag into as smooth a line as possible. All whilst ensuring the content was pleasurable to read. In a perverse kind of way, I always enjoyed this part of the typesetting process.
My article on 24ways is about how we can apply this thinking to the web, where the inherent lack of control on the medium means we have to apply things in a slightly different (read: clumsy) way.
Emma read the article this morning and pretty much summed up the way I feel when I read text sometimes.
Just like a musician listens to music, I view text in a different way to most people. I just forget that I do it most of the time.
I can hardly believe that 24ways has been running since 2005. In the web years, that’s like 72 years ago. It’s a credit to Drew, Brian, Anna, and Owen. It’s not easy running this year in, year out, on a daily publishing schedule for a month. Hours and hours of work go into this, and we should all be thankful for their time and effort. Oh, and let’s not forget Paul, who has given 24ways a lovely redesign this year (you can read more about that on his blog)
Design Abstraction Escalation
What are we losing by abstracting our design processes? Could it be as fundamental as losing a sense of humanity in our work?
A few years ago, Michael Bierut, wrote about a natural progression in a designer’s career.
“The client asks you to design a business card. You respond that the problem is really the client’s logo. The client asks you to design a logo. You say the problem is the entire identity system. The client asks you to design the identity. You say that the problem is the client’s business plan. And so forth.”
He calls this Problem Definition Escalation. Where a designer takes one problem and escalates it to a ‘higher’ plane of benefit and worth – one where it will have greater impact, and ultimately, make the designer feel like they’re doing their real job.
Designing in a browser, in your head, on paper, on a wall, on post-it notes. It doesn’t really matter. What matters is the work. Is it appropriate? Does it do the job well? Will you get paid for it? Does the client understand the benefits?
Really. Who cares how you get there? We’re all coming around to the idea that designing responsive web sites in Photoshop is inefficient and inaccurate (if things like web font rendering matter to you).
Let’s look at the arguments:
For those familiar with the tools, designing in Photoshop is just as efficient as designing in code.
I design using the tools of least resistance. Preferably a pencil, sometimes Photoshop, and a lot of HTML. Photoshop is my tool of choice for creating website designs.
Presenting static visuals to clients is different than using them as a tool yourself as a means to an end.
All of that is good news. Good for clients. Good for the work. Good for us.
A natural result of this is abstraction.
Design patterns are everywhere. The often-repeated chunks of content that we find ourselves designing and building time and time again. User’s get used to seeing them in certain ways, and over time, perhaps their performance is hindered by deviating from the norm. We see this all the time on e-commerce websites, or in new user registrations. Over time, we all collect these little bits of content, design and code. They build up, and eventually they need organising.
Why not group them all together, categorise them, and iterate on them over time? Throw in your boilerplate templates, too. Maybe group them together as a ‘starter kit’ with included navigation, indicative content – for different types of sites like ecommerce, blogs or magazine sites?
And… wait a second, you’ve got all you need to churn out site after site, product after product for clients now. Excellent. All we need to do is change the CSS, right? Maximise our profits.
No. It’s not right.
Conformity and efficiency have a price. And that price is design. That price is a feeling of humanity. Of something that’s been created from scratch. What I described is not a design process. It’s manufacturing. It’s a cupcake machine churning out identical cakes with different icing. But they all taste the same.
Documenting things that repeat is an important thing to do. I have my own pattern library that I’ve been adding to for years now – it’s an electronic scrapbook where I take snapshots of little content bits and bobs that I find interesting, and that keep on cropping up. It’ll never see the light of day. I’ll never use it on a project, because what I’m doing is building up a head full of this stuff so that when a problem presents itself, I will have a fuzzy recollection of something – maybe – that is similar. Instead of going straight to my big ‘ol database of coded examples, I’ll try to recreate this little pattern from memory – and that’s when something interesting happens.
Recreating something just slightly differently – from memory – means you end up with something new.
That’s why I wanted to be a designer, after all. To create new, beautiful things.Next