We are sad to see you go…
Sadly, we are no longer supporting our iOS Basecamp app ‘Bivouac’.
We created Bivouac before the launch of Basecamp’s mobile app, or even their mobile website. We needed a clean and concise list of our upcoming tasks to refer to when not at our desks, or even at our desks without the need to stop what we were doing on screen.
We’d like to thank everybody who used Bivouac for their support, check out Basecamp Mobile for a fully featured alternative.
I’ve been talking (ranting?) to whoever would listen about the state of design education in this country for about a decade now. It’s one of the recurring themes of our podcast The Nudge.
Today, Jeffrey Zeldman had this to say about Mike and design education.
As Mike sees it (and I agree) too many design programs turn out students who can defend their work in an academic critique session among their peers, but have no idea how to talk to clients and no comprehension of their problems. We are creating a generation of skilled and talented but only semi-employable designers—designers who, unless they have the luck to learn what their expensive education didn’t teach them, will have miserably frustrating careers and turn out sub-par work that doesn’t solve their clients’ problems.
This is not a problem unique to Australian design programs. It’s worldwide, and we need to address it now.
An integral part of our job, as designers, is to communicate effectively. When we speak about our processes in front of a client, though, we often fail in this area.
We might not consider it jargon because these are names we use every day, but the client probably has no idea of the hidden meanings behind these.
I write ‘hidden meanings’ because although it’s obvious from their name that wireframes might just be outlines of what someone might see on a screen and comps (short for ‘composite layout’) are fully fleshed out designs in the final colours and fonts, those names don’t explain how these tools are used.
I realised this recently when speaking to a client: their questions and requests showed that, while they had signed off on the wireframe and information architecture, they weren’t really sure what they were signing off on.
We provide a phased approach to design so that the client can have input and sign-off at various stages during the process. This is supposed to be helpful and provide a sense of progress during what is the set of often unseen actions that it takes to make a website.
Perhaps we had failed in communicating the stages and their uses to the client because they started asking for functionality changes after we had moved past wireframes, they asked for menu items to be moved around on comps.
Many of these changes were barriers to progression on the project, as far as the client was concerned, but realistically had no bearing on the final product (which image was used on the comp in a placeholder section, for example), or required a return to a previous phase (changing the home page from a news matrix to three highlights in a carousel).
So I created this description for them. It runs through the phases of creating a website and what it means in terms of working with Floate. It identifies what is appropriate to alter at whichever stage of the process and what isn’t worth worrying about until later.
These are by no means the strict rules of creating a website. Everyone has their own process but we’ve found these phases (which all come after the research phase) are the best for walking a client at a large organisation through a complicated decision tree.
This is often easy to produce after a solid research phase and it can help form the decisions in the rest of the process. We start with a dump of all the things we think need to be on the website as a result of interviews and competitor analysis. Then we categorise them based on behaviours we’ve seen in the research. Sometimes we’ve already started thinking about functionality.
IA can take a number of forms: a two dimensional tree is common although not realistic with a site that used a CMS with categories and tags. It can be a quick sketch of a page that shows how much of a screen needs to be dedicated to different pieces of information. It can be a diagram that shows how the different taxonomies of a site are defined.
The two things to remember here are that none of this is set in stone, it can all be changed right up to and including putting the content in the CMS, and that there is no right way to do it. Everybody understands the structure of information in different ways. There might need to be several treatments before all stakeholders understand where the project is headed.
Universal comprehension is the goal when producing IA.
These are used to show user interface concepts at a very rough level. Content placement on these pages is vaguely indicative of final versions only. The key with wireframes is that they contain everything that is expected on a page in roughly the right spot, but without any specifics around the names of sections, wording in captions or colours (if any are used).
Wireframes are general and low fidelity by definition. They are the skeleton that defines how the website works.
Composite Layouts (Comps)
These are high fidelity examples of what a page might look like. They can be used to get a good sense of font-sizes, how images appear with text, colours used etc. As part of creating the comps we try to create all the elements that we plan to use in the website: what will buttons actually look like in all their different states (active, hover, passive), for example.
The comps create the rules we use for how the website looks. Again, the content may not be correct. The names of menu items might be wrong (we can change them when we build the site) and images might be stock photography rather than final product.
We try to make it as accurate as possible but the nature of using a content management system is that it’s easier to make these changes once we have the colour and shape of everything confirmed.
Chances are, the number of pages that we have wireframed will equal the number of pages we have comped so you can see progress. Together, these will inform the functional and visual build of the website.
This is the phase to get to the nitty-gritty. Once we’ve built the website, changing the way something works or the shape of a button is time-consuming and inefficient. We should have changed those in the earlier phases.
But wait a minute. That paragraph should appear above the image with the happy man standing in a field and the graph needs a caption of “growth over time”. That’s a change we can make really easily in the content management system.
The carousel on the home page runs too slowly, let’s speed it up, and we’ve just tested that form internally and we need a couple more steps for people
Seen a problem on the live site? Ready to go to your boss’s office and commit some horrific ancient ritual? Put the sword away. We can change that pretty easily. Some people may have seen the error but it doesn’t mean that it has to stay that way for all eternity. It might take a couple of hours to get the change through, though, because we have to change it on the staging site first, have it approved and then export the changed files, but it’s still possible.
Sometimes we are disappointed that we can’t do everything on the web that we can do in print. Other times we’re glad we can do so much more.
Empathy is a powerful word, and a strong emotion. It’s the ability to understand what someone else might be thinking. It’s being able to understand how someone else might feel, or how they might respond to a given situation. It is rarely one’s first response; it requires a certain spark of selflessness.
And it’s fundamental to the way that we view design. To be able to do great work, we need to understand and empathise with our audiences, the users of the products and websites we design, and importantly, our clients.
We at Floate think that learning to better empathise with people who are not designers is a path to growth as designers. That’s why 18 months ago, we started what we think is an unusual design event – one where it’s not designers telling other designers about how annoying their clients are.
The Nudge is an on-stage conversation with someone who works on the client side; it’s a chance for clients to tell us what challenges they face, and for designers to find out what goes on behind closed doors. This way, we can get an understanding of how and why the decisions that affect our work are made.
The on-stage guests are never Floate clients. This isn’t a showcase for us. We do this because we want designers, including ourselves, to understand the context that we work in, and to start to empathise with what clients experience on their side of the project. In a sense, The Nudge is the antidote to the poisonous attitude that gave rise to Clients from Hell.
We’ve also expanded our reach a little and created a podcast where we talk to non-designers about their experiences working with designers, and listen to their views on subjects designers could know more about. We’ve spoken with Marketing Professors and sex workers, and a range of people in between. Even founders of startups. Through it all, we find we learn the most when we ask non-designers what they think designers ought to know about their world.
Tomorrow night (September 25), our guest is Sean Hall. Sean is the General Manager of Brand Marketing at Telstra –– he’s going to talk to us about what it’s like to work on a rebrand as large as Telstra’s, and the challenges that can arise when working with external design teams. We’re very grateful he can join us and hope you can come along. I’m buying the drinks.