Or, how we gave birth to Hookturn
A couple of years ago, a few months after I started working with Ross, we were talking business over a gentle beverage. We agreed about a lot, particularly the state of the conversation in our part of the world.
At the time we specified our part of the world as Melbourne, Australia, but also as Design.
We had noted:
- a deficit of nuance in argument and people not being able to defend their work or position
- too much reliance on affirmation, attention or examples from colleagues in the Northern Hemisphere
- a lack of pride or exploration of the quality of work being produced here
- a general reluctance by people to do the extra work it takes to make something really good instead of just getting the job done.
These were implicit issues in our society and it would take a lot of work to make any difference. We started by keeping the goal of improving the way local people spoke about their work in mind when making all business decisions.
This led to us starting The Nudge: an evening in which we interview someone else’s client to find out why they made the decisions they did about a certain design.
Soon we started releasing the events as a podcast so more people could enjoy the conversations we were having.
Then we realised that we needed more conversations.
That’s how Hookturn was born.
We created a label under which we could release podcasts and publications that would help lift the tone of conversation. We had some simple rules:
- Everything released must be planned.
- Recordings must have all main voices in the same room.
- Everything released must be edited.
In addition, we wanted to curate a feeling for the product under the label. All the shows force us to look at the world in a way we haven’t before.
We’re really proud of the work with Hookturn. We encourage you to take a look and download some of the shows. Have a listen and let us know what you think.
It’s part of our desire to be better designers and make our part of the world a better place.
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.