-
Content design with cojones
Or so I tweeted whilst watching the recent Apple keynote. A month later and I don’t think I could have been more wrong.Immediately after the iPad’s reveal, the interweb rippled with an argument between two tribes, those that want a computer that allows them to tinker under the hood, and those that don’t care about getting their hands dirty – they just want to email, surf, watch and listen. For me, this isn’t the interesting debate. It’s how the speed, screen size and controlled environment of the iPad now means that content design on screen can finally come of age and grow some balls. Big ones.
Or so I tweeted whilst watching the recent Apple keynote. A month later and I don’t think I could have been more wrong.
Or so I tweeted whilst watching the recent Apple keynote. A month later and I don’t think I could have been more wrong.
Immediately after the iPad’s reveal, the interweb rippled with an argument between two tribes, those that want a computer that allows them to tinker under the hood, and those that don’t care about getting their hands dirty – they just want to email, surf, watch and listen. For me, this isn’t the interesting debate. It’s how the speed, screen size and controlled environment of the iPad now means that content design on screen can finally come of age and grow some balls. Big ones.
Your content isn’t the same as my content
There are some sites that people check two or three times a day. BBC News is one of them for me. However, out of the 50 or so articles on their home page in the morning, I’ll probably only read around ten stories. As I check back during the day, there’s a law of diminishing returns, in fact every time I visit I usually end up reading half as many stories as I did the previous time.
-
Less and more. Not so much
Dieter Rams is big at the moment. His ten principles of good design seemed to explode around the interweb when the new Vitsoe site launched. He’s been profiled by the V&A as part of last year’s Cold War Modern exhibition. And Apple can’t launch a single product without Jonathan Ive’s name being linked to Rams’ time at Braun.
Reflecting the moment, London’s Design Museum is now showing an exhibition profiling the design ethos of the man himself.

It’s a great exhibition and, as a fan of Rams’ work, it’s wonderful to be able to see so much of his work in one place. Certainly being able to see his designs as physical objects (rather than simply photos in a reference book or blog post) gives a different perspective and appreciation of what he managed to achieve in his time at Braun.
Scattered throughout exhibition are quotes from Rams. The first time that I read some of these I was slightly awe-struck at how much of his design ethos could be applied to service and interaction design:
A product must not claim features – more innovative, more efficient, of higher value – it does not have.
Whilst it’s great to get people excited about features coming tomorrow, those features aren’t a panacea for having a service that doesn’t work today. Transparency and honesty in design can go a long way in helping to create something useful for users from day one.
Because it is certainly unpleasant and tedious to be confronted day-in, day-out with products which are confusing, which literally get on our nerves, and with which we cannot relate.
Usability has always been a key part of interaction design, however, the ability to relate to the user is perhaps even more useful. It’s not just about designing something to be as simple as possible to use. It’s about being to empathise with the end user and knowing what their measure of simplicity is.
More can be found in Rams’ 10 principles of good design:
Good design is innovative.
Good design makes a product useful.
Good design is aesthetic.
Good design makes a product understandable.
Good design is unobtrusive.
Good design is honest.
Good design is long-lasting.
Good design is thorough down to the last detail.
Good design is environmentally friendly.
Good design is as little design as possible.However, the more that I walked around the long, regimented lines of radios, stereos, shavers and kitchen appliances the more I felt that something was missing.
Passion.
Not passion for creating the most useful, honest and understandable products. But passion as a response to actually using a Braun appliance.
Yes, of course it’s great to have something that just works, that fits in your hand just so. That does everything you expect it to do. But that’s where these designs seem to end: they do everything you expect them to do and nothing more. Whilst that’s undoubtedly a big part of being honest, I can’t help but feel that there was something missing.
Going that little bit further. Surprise and delight the user. Don’t just be beautiful through utility, create passion by crafting an experience that quickens the breath just that little bit. The little intake that when you hear it you know that you’ve got someone hooked.

I know that several of my friends would dispute that Braun products don’t elicit a passionate response. One friend in particular purrs like a contented kitten at the thought of owning a T1000 World Receiver. Though I suspect that this response is heavily based upon what Rams’s work now represents rather than the experience of using such a design classic.However, now more than ever, creating an experience that quickens the breath – whether it be a product or a service – may be the only way to creating brand loyalty and a relationship that lasts. After all, other than toothbrushes, who buys Braun now?
-
The future of wireframes?
I have a love hate relationship with wireframes. In the last 10 years they’ve been a part of every web project I’ve worked on. There have been times when I can’t imagine how we would have solved a particular problem without them. Yet there are also times when I’ve been completely exasperated at the amount of time and energy they’ve consumed, seemingly to very little reward.
This frustration has forced me to change the way that I approach wireframes. And as my approach has changed, I’ve been able to extract more and more value from black key lines and grey boxes…
From functional to visual

10 years ago the first wireframes I used were about as functional as you can get – a long list of page elements: static text, dynamic text, input text, radio button and so on. They were universally awful. About the only concession to help people understand how the page worked was to group common functionality into individual tables.
The wireframes were functional rather than visual as they were used to describe how the page should be built. Certainly, when you consider the screen from a developer’s perspective a list of different functional elements is probably quite logical.
However, from a user experience point of view this was a killer. Functional wireframes are incredibly difficult to read – the method of presentation gets in the way of being able to translate the information into a real screen, especially at the review stage.

Looking at this image it seems obvious that wireframes should be visual, however, IA was in it’s infancy ten years ago. Everything was new.
Wireframes also took a long time to produce. Changes to one wireframe often meant updating countless others. Change to the global nav? Certainly. Just one moment whilst I update 120 wireframes with that one.
Understandably, this hampered attempts to create wireframes that more closely represented real life screens. To help get around this, when they did become visual, they also become modular.

The modular approach to wireframes also reflects the reality of building sites. Functionality and snippets of code are built once and then reused over and over again. So why not create wireframes in the same way?
Visual wireframes also started to break down a belief that information architecture can be considered in isolation to information design. The information is the interface. How can the two possibly be separated? Join them together and you start creating wireframes that can be read and understood by everyone on the team, including the client.
Of course, this can raise the problem of clients expecting the final screens to be identical to the visual wireframes. “In the wireframes the submit button is on the right of the drop down, but in the designs it’s below. Why?” This requires careful client management, but it can be largely avoided if the wireframes concentrate on getting the ideas and thinking across, rather than just laying out a page.

Once wireframes are created using information design as a technique rather than just a visual conceit, they can be used to explain how a site will be experienced by the end user. In the example above the different colours represent different areas of content, targeted at different types of users. The client and the team can then get inside the screen and understand how it works and what the priorities are. It’s a very different world from 1999 – a list of functional elements that only be read by the one person – the author of the original wireframe.
As wireframes have evolved, the methods behind creating them have changed too.
Fail fast

Several years ago I can remember working on projects where the wireframes felt as if there were merely a documentation or cataloguing tool. The object was to create as many wireframes as possible, of every screen in the entire site, in big, monolithic and hugely detailed chunks. Rather than exploring different approaches to the information and structure of the site, the emphasis became entirely focused on using all of the time available to build a collection of wireframes, regardless of whether they were the right wireframes.
At Made by Many we practice a very iterative and rapid approach to wireframes. We create the smallest number of wireframes to explore a concept before stopping and reviewing. Does the idea hold up? If so, add on another layer of information and see whether it still stands. If it doesn’t, change direction and explore another route.
As we start off by only doing enough to prove the idea (and no more), the cost of change is so small that you can very easily change direction without having lost time or money. Ideas are allowed to grow or fail fast.
Explore interactions, don’t just specify software

For many years the primary role of wireframes was to specify software. We now use wireframes to investigate and explore how people will interact with a site. Using a ‘just enough’ approach, we often create a series of simple interactive prototypes to try out a variety of approaches to solving a problem. These prototypes can be made in HTML or they can be as simple as a series of Keynote slide for someone to click through.
This is a very different approach to wireframing. Rather than simply documenting where a link goes, the goal is to model and start experiencing what moving around a site feels like as quickly as possible. The prototype can then be tested and the results used to iteratively improve the end solution.
Of course, sites still need to be specified, but wireframes aren’t always the right tool for doing this.
Nobody likes reading wireframes

No matter how much love and attention is poured into a wireframe, they’re cast aside as soon the screens have been designed. Nobody likes reading wireframes, especially when there’s a picture available.
I’ve yet to meet a developer who would choose to build a screen from a wireframe over a Photoshop document, regardless of how many helpful and important details the wireframes may contain. Realizing this is human nature, we now annotating our PSDs rather than wireframes. Why hold the information in a document that’s no one wants to read?
The best before date keeps getting shorter

For a long time wireframes were seen as one a project’s major deliverables. The client was paying for them as part of an agency’s ‘set piece’ best practice. Because of this they were constantly updated throughout the life span of a project, regardless of whether they actually needed to be. I’ve seen perverse instances where a set of wireframes have been updated after the site has been designed, merely to ensure that the wireframes match the finished site. Why update a document that’s never going to be used again?
As more projects are developed using agile methodologies, where the working software is the spec rather than a set of documents, the useful working life of a wireframe is getting shorter and shorter.
The right approach

In a previous life at a big ‘old style’ new media agency, there often seemed to be a one tool fits all approach to projects. This applied to information architecture too – there was a set way of creating and delivering wireframes, regardless of the individual needs of the client.
In contrast, we’re now lucky to have a wide range of tools and techniques that allow us to approach a problem from the best angle. A sketch, a grey wireframe or a full on keynote prototype. These tools allow us to develop a solution in iterations, slowly adding on more detail as the solution becomes closer to a design that can be built.
Whilst there’s a natural progression from sketch to a detailed wireframe, it’s important to never feel constrained by the life cycle of a project. A sketch can be done at any time (and by anyone), regardless of where you are in the process.
Wireframes aren’t the keystone

In the same way that the guild of stonemasons kept the secret of building arches to themselves, wireframes shouldn’t be the preserve of a select group of information architects. As wireframes have become more visual (and more useful) the number of people able to contribute to their development has increased. This isn’t just a list of designers and developers, it’s also clients and business analysts who are becoming more and more involved with the process.
We often involve all of these people in collaborative sessions around a whiteboard to gradually ‘build’ the interface of a site. It’s a different way of working that involves people in a very different way to help create a better service. It’s also a way of working that’s slowly demystifying information architecture, changing the way that we interact with it and, ultimately, who creates it.
The designer as information architect

As wireframes have developed the role and skill set of information architects have developed too. The most effective wireframes are now created by people who can see how a site fits together as a series of connected interactions. Who see the information as the interface, and understand that these two can’t be separated but yet can be affected by time and place.
The more that I appreciate these skills, the more that I believe that wireframes can (and should) be created by designers.
The best sites are those where there’s a seamless divide between the look, the content and the experience. Being able to model an interaction and understand how someone moves through a site are crucial skills in this trilogy. It’s time designers stepped up to the plate and claimed wireframes as their own.
-
Behind the scenes of LOVEFiLM’s new product pages
We’ve been working with LOVEFiLM for some time now. They’re a very exciting client whose business model is built around the internet. They’re also a very successful client, having just passed 1 million subscribers to their DVD rental service.
One of the projects we’ve been working on recently is the redesign of their film pages. These are absolutely at the heart of the service – they contain all of the information about each title that LOVEFiLM has, including user reviews, recommendations, interviews, news stories and cinema listings. Seeing as LOVEFiLM have over 65,000 titles on offer it’s important that they work hard.
Rather than simply showing you the great work that one of our Senior Designers, Julia, has created, I thought it might be useful to show the process behind the project…
1. Requirements wall

Our first step on this project was to get under the hood of the current site. Using the existing film pages as our starting point, we collected together all of the content, interactions and functionality in one place.
This ‘wall of requirements’ allows us to see everything in one view and therefore helps us gain a better understanding of the problem. The process of breaking down the site, freely annotating and then rearranging and grouping components together is invaluable.
Having a physical representation of the problem we’re trying to solve also makes it easier to talk around. It’s not long before a requirements wall becomes overlaid with layers of notes, questions and answers – either from ourselves or from the client.
______________________________________________
2. Block diagrams

Once discovered, the finer details then allows us to take a step back. Rather than being constrained by details, we now want to open things up and explore a wide range of approaches.
Assigning a colour to each block of content (purple = video player, light blue = user reviews, cerise = pack shot etc) we then used Keynote to create a series of block diagrams.
The simplicity of these diagrams allows us to experiment freely with a wide variety of layouts, without being constrained by time. Keynote is a perfect tool for this approach – we can be creative, quickly.
We then reviewed these layouts (and an analysis of the competition) with the client. The consistent colours across all the layouts makes it easy to compare the relative merits of one approach against another.
______________________________________________
3. Photoshop design sketches

Once an initial route had been chosen we start sketching the page in Photoshop. Whilst it may feel unfamiliar to hear the term sketch used in conjunction with a program known for producing highly polished, finished designs, sketching is exactly what we’re doing.
At this stage we’re not excessively worried about the look and feel, or the details being pixel perfect. It’s all about getting the design to a sufficient level to prove that the chosen approach works and feels right.
Sketches are created by laying out the new page using found elements and elements of the existing site to save time. Only elements of the page that are specific to the new approach are created from scratch. This ‘just enough design’ method allows us to get to a working proof of concept as quickly as possible. We can then get feedback from the client and continue to develop the page in an iterative way.
______________________________________________
4. Detail exploration

As part of the design, we also wanted to introduce a new type of interaction metaphor that hadn’t been attempted on the existing site. (In this case, using an accordion to hide and reveal the different options for renting, purchasing and/or watching a film).
As this functionality handles some of the most crucial interactions on the site, we wanted to elaborate our thinking here to prove that the solution would work. We created a series of comps we could use for testing that showed off the interaction and all the different data sets the accordion would have to handle.
It’s important to note at this stage that the designs we’ve created are still not branded. The designs are polished enough to prove their viability, however, not so polished that we can’t make changes quickly based on the client’s feedback.
______________________________________________
5. Sketch and fail fast

As is often the case with the design process, as the screens become more real so does the understanding of the project’s requirements. Sometimes the very process of design can also uncover requirements that haven’t been fully expressed before.
Although change can be intimidating, we embrace it. One of the joys of sketching is the ability to visualise ideas quickly and, if necessary, fail fast. By concentrating on idea generation and then adding sequential layers of look and feel, we’re able to adapt and change quickly.
In this case, as well as our own sketches, the client created some of their own to try out a new idea. This was then added into the designs we’d created so far.
______________________________________________
6. Production designs

Once the route had become firmer we started to turn the pages into production designs. As you can see from the above image, the design now begins to take on the shape of LOVEFiLM. Although the look and feel has been at the back of our heads throughout the entire design process, here it really comes to the fore. For example, the black was introduced as a background colour to help the video player feel more cinematic.
Regular meetings with the client team helped keep the project running smoothly – both to review progress and to collect any specific, detailed requirements and feedback. These continual review points also meant that we were able to hand over the screens in batches throughout the production design phase, rather than in bulk at the end.
______________________________________________
7. The streaming player

The page also includes a streaming media player for trailers, interviews and films. It was very important that this was integrated fully into the design – both from a functional and visual perspective. Using wireframes and requirements from the client, we designed the player at the same time as the film page.
The designs for the player included all of the rollover states and interactions, such as dialogue boxes and ‘more like this’ recommendations screen that appears at the end of each trailer. These were specified fully and then handed over to another development agency to be built.
______________________________________________
8. Specification

AJAX overlays, message boxes and different rollover states were specified for the film pages as well. Whilst this can be a laborious process, it’s often in these small details that the design comes alive – those finishing touches that can seduce a user into falling in love with a service or product.
______________________________________________
9. Build, test, iterate…

The new film pages have been live since the middle of March. (The screenshot above is a pre-release design that uses German for the tabs – the new pages also have to work in Danish, Finish, German, Norwegian and Swedish as well as English.)
As with all agile projects, new iterations are planned for the future, as well as rolling in any feedback and comments from LOVEFiLM’s active community of subscribers. Hopefully, we can continue to share the process with you as it happens.
-
Have I seen this before?
Before TV schedules disappear completely, there’s a breed of TV channels that have built their schedules around predictability.
Audiences know that at 7pm on More4 they’ll be an episode of Grand Designs. And an hour later they’ll be an episode of Top Gear on Dave. These schedules feel unchanging: the only certain things in life are death, taxes and Jeremy Clarkson shouting ‘Power’ at 8pm.
However, this type of schedule breeds fatigue: have I seen this episode before? God no, not the boring team build on a housing estate in Birmingham. Again.
Is there anything that my TV could do to help me out this situation? At this point I could of course just run to the shop and buy a PVR, yet a hard disc full of Jeremy would be more than I could bear. One solution would be to update the on-screen TV guide. Here’s a copy of an existing guide:
Whist the description does provide a nudge as to whether I’ve seen a show before, the on-screen guide could do so much more. Have I seen this before? Did I watch all of it? When?
Here’s a quick sketch of a on-screen guide that aims to solve these problems:
The dot shows whether you’ve seen the program before (an outline), watched a portion of it (half full, as demonstrated) or not seen it (fully coloured in). The guide also shows when you’ve watched it and how much you’ve seen.
In the future you could also add in the ability to rate a program. However, this sketch is an answer to a short term problem only. How long before the iPlayer and on-demand kill the schedule completely?
-
Jock Kenneir is turning, no SPINNING, in his grave
Jock Kenneir, co-designer of the UK’s road signage will be spinning in his grave. Perhaps the sign was painted by someone on work experience?
-
How do you say London in type?
A fellow typographer has created a great series of postcards that show the subliminal messages sent out when using different typefaces.

With tongue firmly in cheek, some of the postcards are absolutely spot on. Who can doubt that Comic Sans isn’t the hand of God or that the typeface Stencil isn’t Rambo 4?
However, I was intrigued by the choice of subliminal message for Gill Sans: I am the son of a stonecutter. This is surprising, not least because there are so many things you could hold up against Eric Gill that being a son of a stonecutter is a bit of a cop out, but mainly because to many Gill Sans cries out “I am English”.
The typeface has a long history of being used for organizations that have a national prominence or by companies that are uniquely identified as having British heritage. From the LNER to the Ministry of Information, from Jan Tschichold’s iconic designs for Penguin to the BBC.
It was this heritage that we experimented using when we started the design phase of Metrotwin, the social utility for Nylonistas. One of the first ideas we discussed was signposting the different cities through colour and type:

The choice of Gill Sans for London was clearly cut, as was the choice of Helvetica Medium for New York. Used (in a roundabout route) by Massimo Veignelli and Bob Noorda for their signage plan for the NYC subway system, it’s now a ubiquitous part of the city’s identity, found on virtually every street corner.
Our colour choice was also to be found on every corner: yellow for New York cabs and black for London taxis. (We also had a secondary palette which didn’t get developed which used red British telephone boxes and blue American post boxes.)
In the end, we decided that the 2 colours (especially when reinforced by images of taxis as on the Metrotwin home page) had such a strong meaning that having city specific fonts was over kill.
However, it’s undoubtedly true that both colours and fonts have the power to create associations and send out messages of their own accord. Which reminds me, with Obama surging ahead in the polls there’s a really obvious one that Lars left out:

-
Just say no to Latin
Lorem ipsum sucks. There, I’ve said it. I’ve come out against the designer’s fall back. Need a block of copy, none available from the client? Lorem ipsum will do. Need some sample user comments? Lorem ipsum. Need a headline to fill that space at top of the page? Want people to focus on the presentation and not the content? Whack in some latin. It’s the catch all filler copy, the designer’s best friend. Yet is lorem ipsum actually a friend to clients and, ultimately, a site’s users?Our work at Made by Many falls into two distinct phases, strategy and production design. We don’t use lorem ipsum for either.
In the early phases of a project, we use design as a visual tool to help our clients understand the services we create. We often focus on a user’s key interactions, presented to the client as a series of highly polished screen designs. Whilst the visual nature of these designs helps translate our thinking into something that looks and feels real, it’s often the content that makes the service believable.
In fact, the service is only made real by showing the relationship between form, content and interaction. Taking away any one of those elements (by falling back on latin copy for example) immediately makes the idea less tangible.
As a project moves into production, there’s often the temptation to use latin as a design element – the idea has been signed off, what does it matter if the design becomes progressively less real? However, the most successful sites are those where the user has been considered at every step of the project. How do you do this? By creating designs that mirror the experience real users will have of the site as closely as possible.
Real users don’t see a site with latin headlines or where every comment is the same 50 word fake entry that has been repeated using cut and paste. By taking the time to use real copy, the designer is asked to consider each element from the user’s perspective. Does this form need any instructional copy? Is it as simple and as short as possible? Does the formating for comments work for both entries of 1 word and 100 words? What happens if a headline splits over 2 lines? Without considering these real elements, there’s a strong danger that design just becomes decoration.



