Tag: kranthi

Interaction Design: When You Shouldn’t Use Fitts’s Law To Measure User Experience


  

The key statement of Fitts’s Law is that the time required to move a pointing device to a target is a function of the distance to the target and its size. In layman’s terms: the closer and larger a target, the faster it is to click on that target. This is easy to understand, not too difficult to implement and it doesn’t seem to make much sense to contradict such a simple and obvious statement.

However, before you start applying Fitts’s Law on every single pixel you can find, consider a few problems that might arise for you as an interaction designer.

Fitts’s Rule Number 1: Create Larger Targets

The likely most prominent statement derived from Fitts’s Law is that the larger a target, the faster it is to acquire.

The Benefits

Creating larger targets will facilitate interaction as well as allow you to get the most pixels out of your interface.

For example, some websites do not extend the clickable area of a button or link to the entire target. As a result, more precision is required to move the cursor to the respective link, which leads to slower navigation times. Fitts’s Law would suggest utilizing every available pixel to enlarge the clickable area and thus making it a larger target to click.

The target to the left lets a few pixels of screen real estate go to waste. The target to the right makes itself larger and quicker to click by exploiting every pixel at its disposal.
The target to the left lets a few pixels of screen real estate go to waste. The target to the right makes itself larger and quicker to click by exploiting every pixel at its disposal. (Left example: Firefox, Right example: Apple)

Increasing the absolute or relative size of a button to make it easier to click is also a popular technique among designers for communicating priorities within the interface and prompting or calling users to perform a particular action.

Relative and absolute size communicate priority within an interface.
Relative and absolute size communicate priority within an interface. (Example: LibreOffice)

Although there are many more considerations to be factored in when designing a call-to-action button, Fitts’s Law provides one of its foremost theoretical foundations.

The Perils

The downside of large targets is, of course, that they can break the balance in your interface as well as quickly take up screen real estate. However, even if you have plenty of space to spare, you do not have to constantly enlarge your target areas to make them more usable since the predicted usability of the size of a button progresses in a non-linear fashion.

Good for your pixels: The usability of the size of a button is a non-linear relationship.
Good for your pixels: The usability of the size of a button is a non-linear relationship.

Thus, if you make a small button 10% larger, it will become much more clickable, but if you make an already very large button 10% larger, you will not gain much more in terms of its usability.

Fitts’s Rule Number 2: Minimize Cursor Movement

A second statement one can deduce from Fitts’s Law is that the closer a target, the faster it is to acquire.

The Benefits

If you place the links and buttons users are most likely to access on a regular basis next to each other, rather than distribute them across the interface, you will speed up interaction by reducing the amount of pixels the cursor will have to travel.

Consider, for example, the Ubuntu Unity interface. It allows you to browse various sources and use two different filters on the results: a text filter and a file type filter. However, notice in the picture below how far apart the two filters are. While the text filter is placed at the very top of the screen, the file type filter is placed at the very bottom.

Fitts would disagree: Search filters are often accessed successively and should therefore be placed close to each other.
Fitts would disagree: Search filters are often accessed successively and should therefore be placed close to each other. (Example: Ubuntu Unity, Screenshot: Webupd8.org)

For a fluent workflow, this arrangement is not optimal. When performing search queries, users often access the input field and file type filters in quick succession to adjust their search results. In order to do that here, the cursor would have to travel quite a distance. Instead, placing the file type icons next to the input field would have minimized cursor movement and sped up interaction (as well as freed up some vertical space).

The Perils

Arranging elements strictly according to this formula can cause conflict with other important design principles, such as the principle of grouping and separating different classes of functionality or content. Its purpose is to give your interface a clear and consistent structure as well as increase its discoverability.

Notice in the picture below how the various tools are sorted into small, meaningful groups: in this case table tools to the left and insert tools to the right.

Sorting interface elements into meaningful groups will give your interface a clear, consistent structure.
Sorting interface elements into meaningful groups will give your interface a clear, consistent structure. (Example: Numbers)

This allows users to create a familiar mental map of where to access a certain kind of information or tool. By contrast, if you analyzed the buttons purely by the frequency in which they are accessed, you would probably choose a different arrangement to minimize cursor movement. This, however, would break the functionally-consistent structure of your interface.

Another principle Fitts’s Law can interfere with is the principle of providing a clean and tidy interface. In order to clean up their interfaces, many websites group their content into drop-down menus. Although many designers raise objections against their usability (a discussion of which would go beyond the scope of this article), drop-downs are nonetheless acknowledged as a visually elegant and space-efficient way to unclutter the interface and organize its content.

Drop-downs can help you structure your content and unclutter the interface.
Drop-downs can help you structure your content and unclutter the interface. (Example: Blurb.com)

The reason Fitts’s Law does not recommend the use of drop-downs is that they involve a longer cursor movement since users cannot access the target in a straight line. Instead, users will have to first click or hover over the drop-down menu, and then move the cursor down the list (and possibly across sub-menus as well) until they eventually reach the desired entry. But considering the benefits of drop-down menus, a longer cursor movement can be an acceptable trade-off.

A third, very important principle that may force you to defy Fitts’s Law is the principle of building forgiving interfaces, which aim to prevent and minimize the costs of mistakes.

Fitts’s Law suggests placing elements directly next to each other to minimize cursor movement, which would also save some space. However, saving those few pixels can result in users accidentally clicking the wrong item, especially when item boundaries are not easily discernible or when focused items are not highlighted distinctly enough.

Accidents waiting to happen: the placement of interface elements can either cause or prevent mistakes.
Accidents waiting to happen: the placement of interface elements can either cause or prevent mistakes. (Example: Codebeamer.com)

Be aware, though, that the consequences of mistakes are less severe when the elements represent navigational functionality as opposed to sharing or editing functionality.

If I open the wrong link, I can simply click the “Back” button to revert my mistake. Thus, when it comes to the links in your header or sidebar, there is no real harm in saving space or increasing the target size by leaving no space between them.

When it comes to navigating during consumption, things can become more annoying. When playing video or audio files or displaying text files, accidentally clicking the “Stop,” “Eject,” “Next Item” or “Clear Playlist” buttons will require more effort on the users part to revert to the original state.

However, when it comes to editing and (especially) sharing functionality, mistakes can become downright destructive. If I click on a button such as “Send,” “Print,” “Delete,” “Download,” “Upload,” “Burn,” “Rip,” “Close,” “Shut Down,” “Connect,” “Disconnect,” “Accept” or “Decline,” my actions can be of much more severe consequences and may not be undone as easily.

Therefore, especially for elements with editing or sharing functionality, you should take precautions to minimize mistakes and the consequences of mistakes:

To give an example for the last point in the list: if I accidentally click on the “Get Mail” instead of the “Write Mail” button, the results are not dramatic, but do not place the “Reply” and “Delete” buttons next to each other.

A special type of input method aiming to prevent mistakes is the two-step input method. The basic idea is that while you can accidentally perform both actions separately, it is unlikely that you will accidentally perform them successively. Take, for example, swipe-to-delete.

First swipe, then delete. While each on its own can easily be triggered by accident, they become a fail-safe mechanism when combined.
First swipe, then delete. While each on its own can easily be triggered by accident, they become a fail-safe mechanism when combined. (Example: Timelogger App)

I can imagine myself accidentally swiping from left to right or accidentally pushing a button, but not accidentally performing both actions in succession.

Two-step input methods are usually deployed for smaller screens, where you may not have enough space to place dangerous commands a bit farther apart. They require a slightly longer hand or cursor movement, yet they are more space efficient in that the second step doesn’t need to be visible until after the first step has occurred.

So, whether swipe/tap, swipe/swipe or tap/tap combinations (except, of course, double-clicking or double-tapping the same spot), two-step input methods make things a bit more difficult than just pressing a large button, but the inconvenience adds a little bit of security that is sometimes necessary to safely get your work done.

Fitts’s Rule Number 3: Avoid Muscular Tension

The goal of Fitts’s index of performance (PDF) is to quantify the information capacity of the human motor system. In other words: it aims to rank input methods according to the amount of physical effort they require to execute a certain command.

The Benefits

The benefits of effortless input methods are most obvious when working with cumbersome devices. The most prominent example is vertical touchscreens, which are typically deployed in professional environments to create, visualize and manage large sets of data.

Fitts’s Law can facilitate and prolong interaction with vertical touchscreens.
Fitts’s Law can facilitate and prolong interaction with vertical touchscreens. (Example: Perceptive Pixel)

When working with vertical screens, keeping your arms in an upright position can quickly tire the deltoid muscles and cause input mistakes or force the user to abandon the interaction. Therefore, avoiding complex and strenuous input techniques can facilitate and prolong the interaction with those devices.

The Perils

Input methods that are more difficult to perform can sometimes actually prevent mistakes. For example, mobile devices are often carried around in pockets, which can trigger commands by accident. In those situations, high-precision input methods are deployed, which use a higher input difficulty to make sure that a command is not executed accidentally. However, these input methods are also a way of making users aware of the severity of the command. Take, for example, the way an iPhone is turned off:

Choosing UI elements by the severity of their consequences: Slide controls for dangerous commands, buttons for harmless ones.
Choosing UI elements by the severity of their consequences: Slide controls for dangerous commands, buttons for harmless ones. (Example: iPhone, Screenshot: Outsideinnovation.com)

Powering off or rebooting the device are quite weighty commands; once triggered, they cannot be undone. Therefore, they are made into sliders, which require a higher precision. By contrast, the cancel command is of no comparable consequence here; hence it is made a button.

Slide controls and other gestures that require a higher precision are the most secure but also the most tedious input methods. Therefore, in order to balance security and usability, they are usually reserved for dangerous commands that are executed infrequently, such as unlocking the screen, turning off the device, setting system-wide preferences, performing administrative tasks or silencing wake up alarms. When dangerous commands are supposed to be executed quickly or frequently, for example when editing, deleting or transferring items, a well-spaced icon arrangement or two-step input method are more appropriate. Although they do not offer the exact same degree of security, they are still fairly secure yet much easier to perform.

A second reason to implement more awkward input methods is to take advantage of the space-efficient nature of gestures. According to Fitts’s index of performance, gestures, which involve some degree of dragging, require a higher muscular tension, which is why Fitts’s Law favors pointing-and-clicking. However, the advantage of gestures is that they trigger functionality without requiring UI controls.

Take, for example, the way you manage your art collection at deviantART. In order to add an item to your Favorites, you do not have to press a button. Instead, as soon as you start dragging a picture, a pane is displayed which you can drop it onto.

Dragging-and-dropping provides functionality without needing visible elements to trigger it.
Dragging-and-dropping provides functionality without needing visible elements to trigger it. (Example: deviantART)

Since dragging-and-dropping doesn’t require buttons or other UI elements to trigger that functionality, it is very space efficient. The downside, of course, is that gestures do not offer any obvious visual clues as to their existence (except perhaps through tooltips). Nonetheless, if screen real estate is crucial, these input methods, although more difficult to perform, become almost a necessity.

Fitts’s Rule Number 4: Exploit The Prime Pixels

The concept of prime pixels states that some pixels are faster to acquire than others. Corners and edges of the screen are especially fast to access. However, the fastest-to-acquire pixel in any situation is simply the pixel at the current cursor position, which has lead to the introduction of the right-click context menu into human–computer interaction.

The Benefits

Context menus appear at the very pixel you right-click and provide you with context-sensitive options for the selected item. As a result, you do not have to move the cursor to a possibly distant fixed location in the interface. There are two kinds of context menus: linear menus and radial or pie menus.

Consulting Fitts’s Law will reveal that it favors radial menus over linear menus. The reasons: First, the wedge-shaped menu entries offer larger target areas. And second, because the menu has a circular shape, the pixels the cursor has to travel to reach either menu entry are always identical. This consistency allows users to create a more efficient muscle memory. By contrast, in linear menus only the menu entries closest to the initial cursor position are quickly accessible, which is why the most frequently performed actions should have those spots reserved for them.

Fitts’s Law favors radial over linear menus.
Fitts’s Law favors radial over linear menus. (Left example: OneNote 2013, Right example: Firefox)

The benefits of placing items at the corners and edges of the screen are that the screen frame guides and positions the cursor once it reaches that location.

Corners and edges are prime screen real estate.
Corners and edges are prime screen real estate. (Diagrams: Particletree)

The user could basically throw the cursor to a corner or edge to select the respective item without having to readjust the cursor position. The result: the targets will be much easier and faster to click.

The Perils

Empirical studies confirm the theoretical assumptions about radial and linear context menus, stating that seek time and error rates give the former a slight edge over the latter. Yet when the participants were asked purely about their subjective preferences, the pie menu was not favored anymore.

In fact, the pie menu, although favored by Fitts’s Law, does have a few disadvantages that can outweigh its benefits in certain situations.

One issue is that the circular menu shape quickly leads to small target areas when more menu entries are added. One way to deal with this problem is to remove redundant options, in line with Hick’s Law. For example, if menu entries are not only applicable to the selected item, or if they are already accessible somewhere else in the interface, they do not have to be incorporated into the context menu as well (“Cut,” “Copy” and “Paste” always apply solely to the selected area as opposed to “Undo,” “Redo,” “New File,” “Save File,” “Print File,” or “Zoom In/Out” and thus lend themselves as fixed toolbar items).

A second way to manage a large number of options are sub-menus. While this is possible within radial menus, doing so will quickly clutter the screen and make them appear less organized than traditional linear menus. This is related to a very specific advantage of linear over radial menus: linear menus make it easier to express hierarchies via sub-menus as well as to group entries.

Grouping entries is more easily done in linear menus.
Grouping entries is more easily done in linear menus. (Example: Word 2013, Screenshot: PCPro.co.uk)

Finally, circular menus take up more space. This can lead to two problems: they can obscure selected items, and they are more likely to pop up at places other than the current cursor position when triggered close to screen edges.

Therefore, in summary, you should consider a linear context menu over a radial menu if:

  • You have to integrate many options,
  • You have to work with sub-menus,
  • You want to group and rank menu entries,
  • Screen real estate is critical.

And finally, as to the corners and edges of the screen, two potential problems should be mentioned: when working with large screens, the amount of pixels the cursor will have to travel can somewhat offset the aforementioned benefits. Also, Web designers will not be able to benefit from this rule because their content (except when in full-screen mode) is run in a browser window. As a result, they cannot take advantage of the edges of the screen and will almost necessarily have to opt for a more compact, centered layout.

Final Thoughts

The difficulty faced by interaction designers and user experience designers is that they have to consider, balance and combine measurable and non-measurable dimensions of user experience to create the best possible product. Fitts’s Law tries to help user interface designers by giving them easily quantifiable, mathematically accurate values to base their design decisions on.

Of course, it is often possible to measure the quality of an interface using mathematical values: The fewer clicks required to access a certain set of data, the faster the navigation. The more vertical pixels a horizontally aligned interface preserves, the better it is suited for the respective device orientation. The closer the most frequently accessed buttons are placed, the more economic the cursor movement.

However, since interfaces are designed for humans, they also have to be consistent, considerate, inclusive, playful and discoverable: qualities that can hardly be measured as easily as clicks or pixels. The stunning accuracy and simplicity of mathematical formulas may sometimes lead designers to favor the measurable over not-so-easily-measurable dimensions. And while mathematical formulas can, indeed, help you enrich user experience, you should treat those formulas as tools, not as principles.

Instead, you should debate and choose anthropological principles first, and, if they permit it, use formulas such as Fitts’s Law as much as possible to actually improve user experience.

Further Reading

Resources you might be interested in:

(cp)


© Anastasios Karafillis for Smashing Magazine, 2012.


Designing Contracts for the XXI Century

Designing Contracts for the XXI Century

A design contract is like a business card—it comes from the same desk, and bears the same creative mark. But it’s also the business card you hate handing out: a folder of legal gibberish with terrible formatting that reminds the client of everything that could possibly go wrong before the work has even started.

Is this just a necessary evil? Why can’t contracts evolve like everything else?

Actually, they can—and should. Modernizing your contract will not only make it match your carefully crafted brand, but it can also help you reach an agreement faster, and even strengthen your position when negotiating. This is not an easy task. Legal content is a delicate matter, and you definitely can’t start tweaking your contract like it’s a blog post.

Before we start modernizing contracts, we first have to understand their purpose, and how and why they got the way they are. It’s a long journey back.

Five Roman principles of contracts still valid today

The Romans developed a sophisticated system of commercial law that has become the foundation for pretty much all of the Western world’s legal systems. A design contract was probably signed to make the incredible decorations of Ara Pacis. Such a contract would have been created to accomplish something not that different from today’s products of design: defining what must be done, the deadline, the client’s approval, and the price. The concept of copyright did not exist yet, but unauthorized and fraudulent copies of literary works were socially unacceptable. (As for non-literary works, good luck copying those marble statues.)

While our work has evolved, contracts have essentially stayed the same—for a number of good reasons. In fact, several principles are just as important in today’s contracts as they were in Roman times.

1. Verba volant, scripta manent

Spoken words fly away, written words stay.

In a world where few people could read or write, a written contract was much more difficult to obtain—and therefore much more valuable than a handshake. Romans were the first to establish a now-universal principle of civil procedure: The burden of proof is on the plaintiff (onus probandi incumbit ei qui dicit). Therefore, a written contract protects the wronged party. This is still true today, so don’t only use a written contract before work begins; make sure every modification is documented in writing.

That’s a much easier task today than in Roman times. You don’t have to run to a scribe, or even a notary. E-mail has been proved legally binding multiple times, so to amend a contract, you can just drop a line like, “As discussed in today’s meeting, we mutually agree to modify the statement of work as follows…”

Some contracts even have a clause that requires all amendments to be in writing. If that’s the case, you’ll want to make certain you follow it; otherwise, the client can make excuses for not paying you for extra work.

AIGA’s standard agreement for design services uses a nifty solution to make sure all modifications are in writing and that there’s a limit to the number of modifications that can be requested:

4.2 Substantive Changes. If Client requests or instructs Changes that amount to a revision of at least 15% of the time required to produce the Deliverables, and or the value or scope of the Services, Designer shall be entitled to submit a new and separate Proposal to Client for written approval. Work shall not begin on the revised services until a fully signed revised Proposal and, if required, any additional retainer fees are received by Designer.

As you can see, it’s the same old verba volant, scripta manent still in use.

2. Aliquid dare, aliquid retinere

Give something, keep something.

The value of a project depends not only on what you put in a contract, but also what you leave out. This is particularly true for design, which is not strictly a product, nor strictly a service. It’s a hybrid set of “deliverables,� and the contract (not the e-mail with the design attached) is the place where you give them to your client.

Be wary of what you give and keep. If possible, hold onto copyright: Delay the assignment, or the effective date of the license, until the money is in the bank. This is the best leverage you have.

Clients will try to do the same with payment, of course. Welcome to contract negotiation.

On this inevitable battlefield, details make a difference. For example, imagine you are an illustrator who creates a set of characters for a story. Your client picks the ones they like, and those are the deliverables they buy. Why shouldn’t you keep the rest, and “recycle� them for future projects? If you don’t specify this in the contract, the client will be assigned all the work in connection with the project, including unused sketches.

Same thing if you are delivering code. It’s common to incorporate snippets of code into multiple projects, but just because that code ends up in that project doesn’t mean that client owns it. These are usually called “design tools� in a contract—which means instead of giving something away, you’re simply giving your client permission to continue using the tools.

3. Leges sine moribus vanae

Laws are useless without customs.

Just as graphical and technical standards are essential to designing, standards and industry practices play a crucial role in negotiating contracts. Following best practices not only lowers transaction costs and streamlines the process, but also fosters more balanced deals.

What are the contractual standards of design? The AIGA agreement mentioned earlier is a great start, but standards can also live in single clauses. Eric Adler, a lawyer who works with creative professionals, knows which clauses of his contract are more likely to be negotiated, and takes care to explain those to his clients.

An excerpt from Eric Adler’s contract annnotations.

When it comes to liability, Adler suggests that it’s standard to cover your asse(t)s up to the overall net value of the project. You could try to ask for more, but no one wants to make a client nervous over a legal boilerplate, and standards make sure this doesn’t happen.

Standards don’t just come from lawyers or unions. Andy Clarke’s Contract Killer is extremely popular among freelance designers—in fact, a version of his contract is one of the most viewed and downloaded items at my company, Docracy, which provides an open collection of legal documents. This is likely due to Clarke’s strict no-legalese policy. He even dropped the classic impersonal language, transforming it into a natural dialogue with the client: “What both parties agree to do.�

The result is a set of informal yet clear rules that cover essential legal provisions, like assigning copyright only upon full payment and reserving portfolio rights.

But where is all the horrible small print?

There is none. This contract shows that it’s possible to enter a binding agreement using everyday English. Your lawyer may not like it, because he may fear not being taken seriously enough, or feel uneasy not following his standard. Fortunately, this is something that has actually changed since the Romans. They had to use formulae and magic words to make sure the contract would be upheld in court, while we typically enjoy shared language and literacy skills.

4. Clausulae insolitae indicunt suspicionem

Unusual clauses will raise flags.

We all like standards, but let’s face it: Everything is negotiable, and people will always try to sneak advantageous clauses into the contract. You need to make sure you don’t sign anything you’ll regret, and spotting bad provisions is not a lawyers-only job. Scanning contracts is a necessity sometimes, so always look closely at the following parts:

  • Parties, particularly when companies are involved: Make sure the people you’re dealing with have the power to bind their companies.
  • IP provisions: Who owns copyright and when, and what the licensing limitations are.
  • Your representation and warranties—the fewer, the better: underpromise and overdeliver!
  • Termination: What happens if someone wants to get out of the deal early?
  • Dispute resolution: The clause no lawyer ever wants to give up. Watch this one, because you don’t want to let a client drag you to a court a thousand miles away. If you can agree to arbitration or mediation, even better.

The more contracts you read, the better you’ll get at spotting weird provisions. Trust your judgement: If something doesn’t seem quite right, it probably isn’t.

At minimum, you should ask for an explanation. This is never a waste of time. If you have a lawyer do this, just find someone who doesn’t bill by the hour, or this negotiation will take forever.

5. Pacta sunt servanda

A deal is a deal.

Both in Roman times and today, if you don’t deliver, it’s on you. Keeping promises is fundamental for a professional reputation. That’s why you have to be clear and consistent in the promises you make.

How do inconsistencies arise? One common way is having a statement of work (SOW) that’s not compatible with a master service agreement (MSA). This happens more often than you might think, particularly if no one has ever read that thirty-page agreement. If it’s not clear which one prevails (yes, you have to write it down), you can find yourself in a legal mess.

For example, capping your hours in the MSA is a great way to mitigate the fixed-fee or milestone-based pricing you agreed to in the SOW, but only if the cap prevails! Vice-versa, if you know you’ll only be looking at the SOW and all the special payment provisions are in there, then it should probably override any older pricing rule buried in that thirty pages of small print.

Even better, an MSA doesn’t really need to include thirty nasty pages of small print.

Making a modern contract

I bet you didn’t read iTunes’ latest Terms and Conditions before clicking “I Agree.� We try to read contracts when we think it’s important, but it’s not easy, for several reasons:

  • Contracts are optimized for print, but today we read mostly on screen.
  • They are often poorly formatted and typographically awful.
  • Many elements are difficult to read, like definitions and ALL CAPS PARAGRAPHS.
  • They’re full of legal jargon, not plain language.

The good news is, these problems can be fixed.

Typography

Let’s start with font. Designers and clients alike now mostly read on screens. Electronic signing is a reality, so there are few arguments for optimizing a contract for print.

If you’ve studied typography, you know how to use contrast, proximity, and alignment to create emotional and persuasive effects, and you can apply these same principles to legal text.

Matthew Butterick, author of Typography for Lawyers, has even developed a font optimized for legal text: Equity, a serif font that also looks good on screen—a nice compromise. Whatever you choose, ensure you give your contract balance and contrast.

Typesetting

Contracts are a very peculiar subset of legal documents. How can you use typesetting skills to improve their layout?

  • Structure them in nested lists. HTML does such a great job handling nested lists and headings, so why use a crappy text editor? You often see reckless tabbing and manual line breaks made by frustrated people desperately trying to keep order. Using tools of the trade like Markdown, LaTeX, and Illustrator, you can do better in no time.
  • Divide the boilerplate from the custom terms. Highlight relevant content like party names, important numbers, and percentages so they stand out from the boilerplates and can be easily skimmed.
  • Make important clauses stand out, but never use all caps. The law only asks the drafter, in specific situations, to highlight certain provisions—and there are ways to do that without sacrificing readability. If your lawyer thinks differently, she’s wrong.
  • Allow longer paragraphs. Words need to “breathe,â€� but contracts also need to cluster like clauses for readers. For this reason, line length is a delicate choice that depends both on the length of the clauses in your contract and on the font you choose to use. If you opt for a sans serif, you might get away with longer lines, but be sure to keep generous margins and line spacing (ideally, 120 to 145 percent of the point size, according to Typography for Lawyers).

You’ll also need to decide whether to justify or left-align text. The general rule is that justified text only works with proper hyphenation. This means you’ll have to manually input non-hyphenated breaks for the words you want to keep on the same line. Unless you’re drafting the contract yourself from start to finish, this is a daunting task. And, if your contract manages to have short paragraphs, ragged-right looks more natural, particularly on screen.

When we redesigned Docracy’s PDF typography, we opted for a longer line with lots of white space on the sides. This lets even the longest contract breathe, yet creates a compact final look:

Plain language

Now for the million-dollar question: Why are contracts written in legal jargon? Sadly, it’s because lawyers are too lazy and change-averse to rewrite their forms. The good news is, this is changing. And you can contribute; most formulaic “legalese,� like herein, thereof, or hereby, can just be replaced with “this.� You might even be able to remove entire lines, but better check with a lawyer to make sure.

Here’s an example of traditional contract language rewritten in plain English. Not only is the new version half the length, but it’s much easier to understand:

Before

After

Timing. Designer will prioritize performance of the Services as may be necessary or as identified in the Proposal, and will undertake commercially reasonable efforts to perform the Services within the time(s) identified in the Proposal. Client agrees to review Deliverables within the time identified for such reviews and to promptly either, (i) approve the Deliverables in writing or (ii) provide written comments and/or corrections sufficient to identify the Client’s concerns, objections or corrections to Designer. The Designer shall be entitled to request written clarification of any concern, objection or correction. Client acknowledges and agrees that Designer’s ability to meet any and all schedules is entirely dependent upon Client’s prompt performance of its obligations to provide materials and written approvals and/or instructions pursuant to the Proposal and that any delays in Client’s performance or Changes in the Services or Deliverables requested by Client may delay delivery of the Deliverables. Any such delay caused by Client shall not constitute a breach of any term, condition or Designer’s obligations under this Agreement.

Timing. Designer will prioritize the Services as may be necessary, or as identified in the Proposal, and will take reasonable efforts to perform the Services in a timely manner. Client agrees to review Deliverables within the time identified in Schedule A and to either (i) approve the Deliverables in writing or (ii) provide exhaustive written feedback. Designer may request written clarification of any of Client's comments. Delays in the performance of the Services due to Client's late feedback or requested Changes will not constitute a breach of Designer's obligations.

Classical roots, contemporary documents

There are many reasons the core rules of contracts are still in place two millennia after the fall of Rome. But there are other elements that we can, and should, take to the twenty-first century.

If we want to address the readability problems unique to our era—and improve communication with our clients—then it’s time we fix the language, layout, and typesetting of our contracts. And who better than designers to do it?


RSS readers: Don't forget to join the discussion!


Translation is UX

Translation is UX

Je ne suis pas monsieur Lebowski. C’est vous monsieur Lebowski. Moi, je suis le Duc.

The Big Lebowski, French version

There is a world where Harry Potter’s arch enemy is “Du-weißt-schon-wer,â€� Facebook users click the “Me gustaâ€� button, and the Dude is named “le Duc.â€� This world is a translated world.

We—the people who make websites—now study almost every aspect of our trade, from content and usability to art direction and typography. Our attention to detail has never been greater as we strive to provide the best possible experience. Yet many users still experience products that lack personality or are difficult to understand.

They are users of a translated version.

When we pledge to embrace the adaptable nature of the web—to make our websites responsive and even future-ready—we’re typically talking about diversity of devices. But the web’s diversity also comes in the form of different languages and cultures.

Translation affects users’ experiences—and our organizations’ success. It’s time we consider translation part of our jobs, too.

Waiting for C-3PO

“Do you want your forum clean like this?�

I had just set up a user forum in French when I stumbled upon this rather bizarre banner. “What makes the forum so clean?� I wondered. “Do they tidy the code every day?� I had to change the language back to English to understand it: “Do you want your own forum like this?�

In French, “propre� means either “own� or “clean,� depending on how it’s used. The rule is simple; any translator would know it. More precisely, any human translator. Google Translate, the system behind the French version of the forum, obviously wasn’t so sure.

It’s not just Google Translate, either. In the 1950s, Alan Turing, the father of computer science, devised a test to evaluate machine intelligence through conversations. The biggest Turing test ever was held last June to celebrate what would have been Turing’s hundredth birthday. The winner was probably the most advanced chatbot ever created, yet Eugene Goostman—as this bot is named—failed to fool the judges 70 percent of the time. When will machines pass the test? In the year 2029—maybe.

This should come as no surprise. Languages are amongst the richest and most complex systems humankind has ever produced. When machines gain the ability to really speak (and therefore translate), it will be possible to use Google Translate in a professional context—and no doubt we’ll also have Google Design and Google Copywriting by then. But today, Google Translate is to translation what the auto mode is to photography: a quick-and-dirty solution. It comes in handy when you need to get an idea of what’s being said about your project on Weibo (China’s version of Twitter), but it isn’t a good option when you need to translate your website into Spanish.

While we’re waiting for C-3PO, we need professional translators. We must also acknowledge their creativity and recognize them as peers.

Great design deserves great translation

Translating is a respectable, valuable, creative and worthwhile use of a human brain.

—David Bellos, Is That a Fish in Your Ear?

Le Big Lebowski is a masterpiece. I would even argue that it surpasses the original. Everything is just perfect: the dubbing, the humor, the dialogue. The translators retained the essence of the film while adapting it for an audience that has no idea what a “dude� is. They managed to translate not just the words, but the Coen brothers’ genius as well.

E-mail service provider MailChimp is a masterpiece, too. Aarron Walter’s UX team has succeeded in creating a unique personality. Much of this personality manifests itself through copy: the greetings from Freddie, the company’s joke-cracking mascot; the always-relevant error and help messages; and—above all—the “funny but not goofy, informal but not sloppy� voice and tone used throughout the application.

Now, if MailChimp were to be translated into Spanish, Russian, or Chinese, what would become of this personality? What does it mean to be “informal but not sloppy� in Japanese? Should the mascot’s name still be “Freddie Von Chimpenheimer IV� in German, or could that be misinterpreted? Can you greet an Indian user with “Hi. You could be a part-time model�?

There are no easy answers to these questions. Translating is walking a tightrope. The challenge is to remain faithful to the original design while adapting it for a new audience, for a different culture.

If you think a machine can do this, take a look at this Google translation of MailChimp’s success message, “High fives! Your list has been imported�:

Cinco años de alta! Su lista ha sido importado.

Show that to a Spanish-speaking friend and you’re sure to get a bewildered look.

The road ahead

The web is home to plenty of innovation. But when it comes to translation, other industries are far ahead.

If we want to reap the benefits of translation, we must learn what it takes to do it well—and why it matters. Let me give you two examples.

Linguistic validation

The pharmaceutical business may not seem to share much with web design, but it has one best practice that could inspire us: linguistic validation.

Introducing a new drug into the market is a complex and controlled process that includes a long series of trials and reviews. Some of these tests involve the patients themselves, such as Patient-Reported Outcomes questionnaires, which assess whether a drug has actually improved a patient’s quality of life. These questionnaires are written in English by clinicians and then translated into hundreds of languages.

Ordinary translation is usually a two-step process: translation then proofreading (some even skip the proofreading). The linguistic validation of patient questionnaires has a few more steps, such as doing both forward and backward translations and pilot testing.

Why such a complicated and costly process? Two reasons: First, the original version is a precise research instrument. Nothing has been left to chance. Second, it is essential for patients to perfectly understand the questions, because what they report will serve as scientific data. The questionnaire must therefore be intuitive and patient-friendly.

Thoughtfully designed products, user-friendly interfaces—aren’t these what we aim for? If we care equally about all our users, it’s time we start thinking of translation as something slightly more complex than a word-to-word job.

Cultural expertise

Raving Rabbids is a humorous party game designed in Ubisoft’s Paris studio. The development team includes a localization specialist in charge of the game’s eight localized versions. She works hand in hand with designers to ensure their jokes, references, and altogether craziness are translatable. For the U.S., Rabbids’ biggest market, a duo of Americans from Nickelodeon even gave the team a little extra cultural insight.

It costs millions of dollars to produce a major video game, and even more to target international audiences. Because playing a game is such an immersive experience, the teams behind Rabbids and many other games have found that localization specialists are critical. They are not given a finished product to adapt—they take part early in the project, as their feedback on cultural matters may profoundly change the game’s design.

The game industry prefers the term “localizationâ€� to “translationâ€� because the latter is too often restricted to text. This says a lot about how seriously game studios take cultural expertise. Because they know a cultural misfit can stall a game’s chances of success—and they know for every dollar invested in localization, there’s a $25 return.

Because they know that translation—sorry, localization—is UX.

Translate early, translate often

Most startups employ what could be called the lemonade tycoon approach: Start in your neighborhood, amongst the people you know; this is your best bet. Get it right at home before expanding into far-off lands.

I’m not saying you shouldn’t start in your own country. Local knowledge is priceless. But why wait to internationalize? Unlike lemonade selling, the web is international by nature. From day one, your website will be accessible to any person on this planet.

What’s more, procrastination has a cost. According to Smartling, a translation software company, “it can take companies 12-18 months to internationalize their code and launch their first foreign language site, absorbing much of the company’s engineering resources.â€�

Companies face the same problem when they develop a mobile version of their site afterward. Good thing many now adopt a “mobile first� process.

Perhaps they should consider “foreign first,� too.

It’s a big world out there

When you come from a non-English-speaking country, as I do, a “foreign first� approach is very likely to mean “English first.� But what if you’re based in New York, Manchester, or Auckland? Which language should you go for?

The answer is actually not to think “language,� but rather “opportunity� and “culture�—as these three companies have:

  • Wufoo is a popular form builder from Tampa, Florida. At the beginning of 2012, it launched Wufoo Español, its first foreign version. You won’t find the Spanish version at wufoo.es, but at wufoo.com.mx—because it saw an opportunity in a neighboring market, and language was a means to reach that market. Besides, Wufoo doesn’t mix up language and local culture: It plans to roll out additional localized versions for Spain and Argentina.
  • CanaDream is a Canadian RV rental company whose website is available in three languages. English and French are obvious choices, but the third one is trickier: German. Again, the company saw an opportunity—Germans love RV travel. But German people generally speak good English, don’t they? Yes, many do—but they will still prefer a company that attends to them in their own language.
  • Bla Bla Car is a car-sharing service born in France. Here we can see that “English firstâ€� isn’t always the rule. Bla Bla Car’s first foreign version was in Spanish. The car-sharing market was less competitive in Spain than in other European countries, which gave Bla Bla Car the opportunity to test-run its internationalization before moving on to other markets—which it eventually did. Car sharing is getting more and more popular in Europe, and Bla Bla Car aims for leadership in the region—and in a multilingual area, this has required translation to seven languages and counting.

Bargain-basement market research

Most startups can’t afford international market research. That’s why they focus on their home market. But just as Paul Boag taught us about bargain basement usability testing, we can find affordable market research techniques, too.

Once you’ve settled on a country to target, go to ProZ and look for a translator or agency based there. Brief her about your project and send your prototype or an access to your beta. Ask her to translate the key screens. Even at this stage, you can get lots of feedback: “Are you aware your app name can hardly be pronounced—let alone remembered—by Brazilians?� “I’m sure having Acme Inc. as a client is a great reference in the U.S., but nobody knows them here.� “This photo of a blond-haired, blue-eyed guy probably won’t resonate with a Turkish market.�

Then ask your translator to run a user test using her network of proofreaders. You don’t need hundreds of people—with only ten participants, you’ll uncover any major cultural faux pas. You’ll also gain a general understanding of whether people are interested in the project, what their main questions are, and whether they like the visual design.

Finally, discuss your personas with the translator: Maybe Harriet should be renamed María and relocated to Valparaiso. And what about adding Hugo, the typical backpacker from the Netherlands? With localized personas, all your users will be given equal consideration throughout the design process.

Of course, you’ll need more precise data eventually. But this quick-and-dirty research is enough to get you started. You’ll iterate from there.

Your new teammate

When you start translating early, you make the translator part of your team. Chances are this will be a very rewarding experience. At Novius, my company, it’s changed the way we work.

For major projects, we now create and feed a glossary—or as I like to call it, a “style spreadsheet.â€� CSS stylesheets are understood by both designers and developers and guarantee style consistency across an entire website. Similarly, glossaries are by and for the whole team and ensure the consistency of content. Just like you want a color scheme that’s thoroughly followed, you also want to make sure “module,â€� “plugin,â€� and “extensionâ€� aren’t all used to refer to the same concept. Le fond et la forme.

We have also learned that a quality translation begins with the code. Developers strive for reusable code, and strings are no exception. Depending on how a developer handles them, he could make the translator’s job straightforward, or virtually impossible.

When dealing with sentences like, “1 person has this question� and “X people have this problem, including you,� translators are often asked to translate strings like: “person has,� “people have,� “this,� “question,� “problem,� and “including you.�

Even with context, deconstructing these sentences is a translator’s nightmare. For languages with gender, the string “thisâ€� is untranslatable (e.g., esta pregunta and este problema in Spanish). In many languages, like Russian, plurals take several forms (e.g., for the plural “persons,â€� you would say four человеÌ�ка, but five человеÌ�к). And the list goes on.

Since language isn’t code, developers and translators have a lot to learn from each other. Translators will tell them the software they use has translation memory, so there’s no need to avoid repetition. They will discuss how to handle variables in text. They will also decide together which internationalization system (such as gettext) and text file format (like XML or PO) to use.

Not a one-off thing

I won’t lie to you. Once you’ve translated your website, you’re in for good. People don’t care that they’re using a translated version. For them this is the only version. So you’ll have to keep translating.

They will hate being considered “second-rateâ€� users. Once you’re out of beta, 90 percent translated is not OK. How would your users feel if every website update resulted in a buggy mobile version? Users of translated versions experience this all the time, with English text suddenly popping up out of nowhere. To make it worse, the newest features—proudly announced and long-awaited—are usually the ones left partially translated. Users do get the message: You’re not important enough for us to prioritize translation quality.

While good localization boosts conversion rates, bad or partial translation may ruin a user experience, giving users an uneasy feeling about the whole company: If they can’t even get their website right, how bad will the customer support be?

In fact, I recently chose not to purchase a service because of a pricing page that proclaimed, “Give a price to these ladders with your growing company.�

Guess what it was selling? Translation software.

A multilingual web

If I am selling to you, I speak your language. If I am buying, dann müssen Sie Deutsch sprechen.

—Willy Brandt, West German political leader

The language of the web is English as much as HTML. If the web had a capital, it would be somewhere around San Francisco Bay. Web professionals worldwide use English expressions in almost every sentence: Like, browser, responsive, Tweet, SEO, etc.

However, 73 percent of internet users don’t speak English, and their numbers are growing. We now enter the age of glocalisation.

In our move toward universal design, we must not forget languages and the people who master them. “Translating is writing,� said French writer Marguerite Yourcenar.

Today we can also say, translating is designing.


RSS readers: Don't forget to join the discussion!


Translation is UX

There is a world where Harry Potter’s arch enemy is “Du-weißt-schon-wer,� Facebook users click the “Me gusta� button, and the Dude is named “le Duc.� This world is a translated world.

We—the people who make websites—now study almost every aspect of our trade, from content and usability to art direction and typography. Our attention to detail has never been greater as we strive to provide the best possible experience. Yet many users still experience products that lack personality or are difficult to understand.

They are users of a translated version.

When we pledge to embrace the adaptable nature of the web—to make our websites responsive and even future-ready—we’re typically talking about diversity of devices. But the web’s diversity also comes in the form of different languages and cultures.

Translation affects users’ experiences—and our organizations’ success. It’s time we consider translation part of our jobs, too.

Waiting for C-3PO

“Do you want your forum clean like this?�

I had just set up a user forum in French when I stumbled upon this rather bizarre banner. “What makes the forum so clean?� I wondered. “Do they tidy the code every day?� I had to change the language back to English to understand it: “Do you want your own forum like this?�

In French, “propre� means either “own� or “clean,� depending on how it’s used. The rule is simple; any translator would know it. More precisely, any human translator. Google Translate, the system behind the French version of the forum, obviously wasn’t so sure.

It’s not just Google Translate, either. In the 1950s, Alan Turing, the father of computer science, devised a test to evaluate machine intelligence through conversations. The biggest Turing test ever was held last June to celebrate what would have been Turing’s hundredth birthday. The winner was probably the most advanced chatbot ever created, yet Eugene Goostman—as this bot is named—failed to fool the judges 70 percent of the time. When will machines pass the test? In the year 2029—maybe.

This should come as no surprise. Languages are amongst the richest and most complex systems humankind has ever produced. When machines gain the ability to really speak (and therefore translate), it will be possible to use Google Translate in a professional context—and no doubt we’ll also have Google Design and Google Copywriting by then. But today, Google Translate is to translation what the auto mode is to photography: a quick-and-dirty solution. It comes in handy when you need to get an idea of what’s being said about your project on Weibo (China’s version of Twitter), but it isn’t a good option when you need to translate your website into Spanish.

While we’re waiting for C-3PO, we need professional translators. We must also acknowledge their creativity and recognize them as peers.

Great design deserves great translation

Translating is a respectable, valuable, creative and worthwhile use of a human brain.
David Bellos, Is That a Fish in Your Ear?

Le Big Lebowski is a masterpiece. I would even argue that it surpasses the original. Everything is just perfect: the dubbing, the humor, the dialogue. The translators retained the essence of the film while adapting it for an audience that has no idea what a “dude� is. They managed to translate not just the words, but the Coen brothers’ genius as well.

E-mail service provider MailChimp is a masterpiece, too. Aarron Walter’s UX team has succeeded in creating a unique personality. Much of this personality manifests itself through copy: the greetings from Freddie, the company’s joke-cracking mascot; the always-relevant error and help messages; and—above all—the “funny but not goofy, informal but not sloppy� voice and tone used throughout the application.

Now, if MailChimp were to be translated into Spanish, Russian, or Chinese, what would become of this personality? What does it mean to be “informal but not sloppy� in Japanese? Should the mascot’s name still be “Freddie Von Chimpenheimer IV� in German, or could that be misinterpreted? Can you greet an Indian user with “Hi. You could be a part-time model�?

There are no easy answers to these questions. Translating is walking a tightrope. The challenge is to remain faithful to the original design while adapting it for a new audience, for a different culture.

If you think a machine can do this, take a look at this Google translation of MailChimp’s success message, “High fives! Your list has been imported�:

Cinco años de alta! Su lista ha sido importado.

Show that to a Spanish-speaking friend and you’re sure to get a bewildered look.

The road ahead

The web is home to plenty of innovation. But when it comes to translation, other industries are far ahead.

If we want to reap the benefits of translation, we must learn what it takes to do it well—and why it matters. Let me give you two examples.

Linguistic validation

The pharmaceutical business may not seem to share much with web design, but it has one best practice that could inspire us: linguistic validation.

Introducing a new drug into the market is a complex and controlled process that includes a long series of trials and reviews. Some of these tests involve the patients themselves, such as Patient-Reported Outcomes questionnaires, which assess whether a drug has actually improved a patient’s quality of life. These questionnaires are written in English by clinicians and then translated into hundreds of languages.

Ordinary translation is usually a two-step process: translation then proofreading (some even skip the proofreading). The linguistic validation of patient questionnaires has a few more steps, such as doing both forward and backward translations and pilot testing.

Why such a complicated and costly process? Two reasons: First, the original version is a precise research instrument. Nothing has been left to chance. Second, it is essential for patients to perfectly understand the questions, because what they report will serve as scientific data. The questionnaire must therefore be intuitive and patient-friendly.

Thoughtfully designed products, user-friendly interfaces—aren’t these what we aim for? If we care equally about all our users, it’s time we start thinking of translation as something slightly more complex than a word-to-word job.

Cultural expertise

Raving Rabbids is a humorous party game designed in Ubisoft’s Paris studio. The development team includes a localization specialist in charge of the game’s eight localized versions. She works hand in hand with designers to ensure their jokes, references, and altogether craziness are translatable. For the U.S., Rabbids’ biggest market, a duo of Americans from Nickelodeon even gave the team a little extra cultural insight.

It costs millions of dollars to produce a major video game, and even more to target international audiences. Because playing a game is such an immersive experience, the teams behind Rabbids and many other games have found that localization specialists are critical. They are not given a finished product to adapt—they take part early in the project, as their feedback on cultural matters may profoundly change the game’s design.

The game industry prefers the term “localization� to “translation� because the latter is too often restricted to text. This says a lot about how seriously game studios take cultural expertise. Because they know a cultural misfit can stall a game’s chances of success—and they know for every dollar invested in localization, there’s a $25 return.

Because they know that translation—sorry, localization—is UX.

Translate early, translate often

Most startups employ what could be called the lemonade tycoon approach: Start in your neighborhood, amongst the people you know; this is your best bet. Get it right at home before expanding into far-off lands.

I’m not saying you shouldn’t start in your own country. Local knowledge is priceless. But why wait to internationalize? Unlike lemonade selling, the web is international by nature. From day one, your website will be accessible to any person on this planet.

What’s more, procrastination has a cost. According to Smartling, a translation software company, “it can take companies 12-18 months to internationalize their code and launch their first foreign language site, absorbing much of the company’s engineering resources.�

Companies face the same problem when they develop a mobile version of their site afterward. Good thing many now adopt a “mobile first� process.

Perhaps they should consider “foreign first,� too.

It’s a big world out there

When you come from a non-English-speaking country, as I do, a “foreign first� approach is very likely to mean “English first.� But what if you’re based in New York, Manchester, or Auckland? Which language should you go for?

The answer is actually not to think “language,� but rather “opportunity� and “culture�—as these three companies have:

  • Wufoo is a popular form builder from Tampa, Florida. At the beginning of 2012, it launched Wufoo Español, its first foreign version. You won’t find the Spanish version at wufoo.es, but at wufoo.com.mx—because it saw an opportunity in a neighboring market, and language was a means to reach that market. Besides, Wufoo doesn’t mix up language and local culture: It plans to roll out additional localized versions for Spain and Argentina.
  • CanaDream is a Canadian RV rental company whose website is available in three languages. English and French are obvious choices, but the third one is trickier: German. Again, the company saw an opportunity—Germans love RV travel. But German people generally speak good English, don’t they? Yes, many do—but they will still prefer a company that attends to them in their own language.
  • Bla Bla Car is a car-sharing service born in France. Here we can see that “English firstâ€� isn’t always the rule. Bla Bla Car’s first foreign version was in Spanish. The car-sharing market was less competitive in Spain than in other European countries, which gave Bla Bla Car the opportunity to test-run its internationalization before moving on to other markets—which it eventually did. Car sharing is getting more and more popular in Europe, and Bla Bla Car aims for leadership in the region—and in a multilingual area, this has required translation to seven languages and counting.

Bargain-basement market research

Most startups can’t afford international market research. That’s why they focus on their home market. But just as Paul Boag taught us about bargain basement usability testing, we can find affordable market research techniques, too.

Once you’ve settled on a country to target, go to ProZ and look for a translator or agency based there. Brief her about your project and send your prototype or an access to your beta. Ask her to translate the key screens. Even at this stage, you can get lots of feedback: “Are you aware your app name can hardly be pronounced—let alone remembered—by Brazilians?� “I’m sure having Acme Inc. as a client is a great reference in the U.S., but nobody knows them here.� “This photo of a blond-haired, blue-eyed guy probably won’t resonate with a Turkish market.�

Then ask your translator to run a user test using her network of proofreaders. You don’t need hundreds of people—with only ten participants, you’ll uncover any major cultural faux pas. You’ll also gain a general understanding of whether people are interested in the project, what their main questions are, and whether they like the visual design.

Finally, discuss your personas with the translator: Maybe Harriet should be renamed María and relocated to Valparaiso. And what about adding Hugo, the typical backpacker from the Netherlands? With localized personas, all your users will be given equal consideration throughout the design process.

Of course, you’ll need more precise data eventually. But this quick-and-dirty research is enough to get you started. You’ll iterate from there.

Your new teammate

When you start translating early, you make the translator part of your team. Chances are this will be a very rewarding experience. At Novius, my company, it’s changed the way we work.

For major projects, we now create and feed a glossary—or as I like to call it, a “style spreadsheet.� CSS stylesheets are understood by both designers and developers and guarantee style consistency across an entire website. Similarly, glossaries are by and for the whole team and ensure the consistency of content. Just like you want a color scheme that’s thoroughly followed, you also want to make sure “module,� “plugin,� and “extension� aren’t all used to refer to the same concept. Le fond et la forme.

We have also learned that a quality translation begins with the code. Developers strive for reusable code, and strings are no exception. Depending on how a developer handles them, he could make the translator’s job straightforward, or virtually impossible.

When dealing with sentences like, “1 person has this question� and “X people have this problem, including you,� translators are often asked to translate strings like: “person has,� “people have,� “this,� “question,� “problem,� and “including you.�

Even with context, deconstructing these sentences is a translator’s nightmare. For languages with gender, the string “this� is untranslatable (e.g., esta pregunta and este problema in Spanish). In many languages, like Russian, plurals take several forms (e.g., for the plural “persons,� you would say four челове�ка, but five челове�к). And the list goes on.

Since language isn’t code, developers and translators have a lot to learn from each other. Translators will tell them the software they use has translation memory, so there’s no need to avoid repetition. They will discuss how to handle variables in text. They will also decide together which internationalization system (such as gettext) and text file format (like XML or PO) to use.

Not a one-off thing

I won’t lie to you. Once you’ve translated your website, you’re in for good. People don’t care that they’re using a translated version. For them this is the only version. So you’ll have to keep translating.

They will hate being considered “second-rate� users. Once you’re out of beta, 90 percent translated is not OK. How would your users feel if every website update resulted in a buggy mobile version? Users of translated versions experience this all the time, with English text suddenly popping up out of nowhere. To make it worse, the newest features—proudly announced and long-awaited—are usually the ones left partially translated. Users do get the message: You’re not important enough for us to prioritize translation quality.

While good localization boosts conversion rates, bad or partial translation may ruin a user experience, giving users an uneasy feeling about the whole company: If they can’t even get their website right, how bad will the customer support be?

In fact, I recently chose not to purchase a service because of a pricing page that proclaimed, “Give a price to these ladders with your growing company.�

Guess what it was selling? Translation software.

A multilingual web

If I am selling to you, I speak your language. If I am buying, dann müssen Sie Deutsch sprechen.
Willy Brandt, West German political leader

The language of the web is English as much as HTML. If the web had a capital, it would be somewhere around San Francisco Bay. Web professionals worldwide use English expressions in almost every sentence: Like, browser, responsive, Tweet, SEO, etc.

However, 73 percent of internet users don’t speak English, and their numbers are growing. We now enter the age of glocalisation.

In our move toward universal design, we must not forget languages and the people who master them. “Translating is writing,� said French writer Marguerite Yourcenar.

Today we can also say, translating is designing.


Designing Contracts for the XXI Century

A design contract is like a business card—it comes from the same desk, and bears the same creative mark. But it’s also the business card you hate handing out: a folder of legal gibberish with terrible formatting that reminds the client of everything that could possibly go wrong before the work has even started.

Is this just a necessary evil? Why can’t contracts evolve like everything else?

Actually, they can—and should. Modernizing your contract will not only make it match your carefully crafted brand, but it can also help you reach an agreement faster, and even strengthen your position when negotiating. This is not an easy task. Legal content is a delicate matter, and you definitely can’t start tweaking your contract like it’s a blog post.

Before we start modernizing contracts, we first have to understand their purpose, and how and why they got the way they are. It’s a long journey back.

Five Roman principles of contracts still valid today

The Romans developed a sophisticated system of commercial law that has become the foundation for pretty much all of the Western world’s legal systems. A design contract was probably signed to make the incredible decorations of Ara Pacis. Such a contract would have been created to accomplish something not that different from today’s products of design: defining what must be done, the deadline, the client’s approval, and the price. The concept of copyright did not exist yet, but unauthorized and fraudulent copies of literary works were socially unacceptable. (As for non-literary works, good luck copying those marble statues.)

While our work has evolved, contracts have essentially stayed the same—for a number of good reasons. In fact, several principles are just as important in today’s contracts as they were in Roman times.

1. Verba volant, scripta manent

Spoken words fly away, written words stay.

In a world where few people could read or write, a written contract was much more difficult to obtain—and therefore much more valuable than a handshake. Romans were the first to establish a now-universal principle of civil procedure: The burden of proof is on the plaintiff (onus probandi incumbit ei qui dicit). Therefore, a written contract protects the wronged party. This is still true today, so don’t only use a written contract before work begins; make sure every modification is documented in writing.

That’s a much easier task today than in Roman times. You don’t have to run to a scribe, or even a notary. E-mail has been proved legally binding multiple times, so to amend a contract, you can just drop a line like, “As discussed in today’s meeting, we mutually agree to modify the statement of work as follows…�

Some contracts even have a clause that requires all amendments to be in writing. If that’s the case, you’ll want to make certain you follow it; otherwise, the client can make excuses for not paying you for extra work.

AIGA’s standard agreement for design services uses a nifty solution to make sure all modifications are in writing and that there’s a limit to the number of modifications that can be requested:

4.2 Substantive Changes. If Client requests or instructs Changes that amount to a revision of at least 15% of the time required to produce the Deliverables, and or the value or scope of the Services, Designer shall be entitled to submit a new and separate Proposal to Client for written approval. Work shall not begin on the revised services until a fully signed revised Proposal and, if required, any additional retainer fees are received by Designer.

As you can see, it’s the same old verba volant, scripta manent still in use.

2. Aliquid dare, aliquid retinere

Give something, keep something.

The value of a project depends not only on what you put in a contract, but also what you leave out. This is particularly true for design, which is not strictly a product, nor strictly a service. It’s a hybrid set of “deliverables,� and the contract (not the e-mail with the design attached) is the place where you give them to your client.

Be wary of what you give and keep. If possible, hold onto copyright: Delay the assignment, or the effective date of the license, until the money is in the bank. This is the best leverage you have.

Clients will try to do the same with payment, of course. Welcome to contract negotiation.

On this inevitable battlefield, details make a difference. For example, imagine you are an illustrator who creates a set of characters for a story. Your client picks the ones they like, and those are the deliverables they buy. Why shouldn’t you keep the rest, and “recycle� them for future projects? If you don’t specify this in the contract, the client will be assigned all the work in connection with the project, including unused sketches.

Same thing if you are delivering code. It’s common to incorporate snippets of code into multiple projects, but just because that code ends up in that project doesn’t mean that client owns it. These are usually called “design tools� in a contract—which means instead of giving something away, you’re simply giving your client permission to continue using the tools.

3. Leges sine moribus vanae

Laws are useless without customs.

Just as graphical and technical standards are essential to designing, standards and industry practices play a crucial role in negotiating contracts. Following best practices not only lowers transaction costs and streamlines the process, but also fosters more balanced deals.

What are the contractual standards of design? The AIGA agreement mentioned earlier is a great start, but standards can also live in single clauses. Eric Adler, a lawyer who works with creative professionals, knows which clauses of his contract are more likely to be negotiated, and takes care to explain those to his clients.

An excerpt from Eric Adler’s contract annnotations.

When it comes to liability, Adler suggests that it’s standard to cover your asse(t)s up to the overall net value of the project. You could try to ask for more, but no one wants to make a client nervous over a legal boilerplate, and standards make sure this doesn’t happen.

Standards don’t just come from lawyers or unions. Andy Clarke’s Contract Killer is extremely popular among freelance designers—in fact, a version of his contract is one of the most viewed and downloaded items at my company, Docracy, which provides an open collection of legal documents. This is likely due to Clarke’s strict no-legalese policy. He even dropped the classic impersonal language, transforming it into a natural dialogue with the client: “What both parties agree to do.�

The result is a set of informal yet clear rules that cover essential legal provisions, like assigning copyright only upon full payment and reserving portfolio rights.

But where is all the horrible small print?

There is none. This contract shows that it’s possible to enter a binding agreement using everyday English. Your lawyer may not like it, because he may fear not being taken seriously enough, or feel uneasy not following his standard. Fortunately, this is something that has actually changed since the Romans. They had to use formulae and magic words to make sure the contract would be upheld in court, while we typically enjoy shared language and literacy skills.

4. Clausulae insolitae indicunt suspicionem

Unusual clauses will raise flags.

We all like standards, but let’s face it: Everything is negotiable, and people will always try to sneak advantageous clauses into the contract. You need to make sure you don’t sign anything you’ll regret, and spotting bad provisions is not a lawyers-only job. Scanning contracts is a necessity sometimes, so always look closely at the following parts:

  • Parties, particularly when companies are involved: Make sure the people you’re dealing with have the power to bind their companies.
  • IP provisions: Who owns copyright and when, and what the licensing limitations are.
  • Your representation and warranties—the fewer, the better: underpromise and overdeliver!
  • Termination: What happens if someone wants to get out of the deal early?
  • Dispute resolution: The clause no lawyer ever wants to give up. Watch this one, because you don’t want to let a client drag you to a court a thousand miles away. If you can agree to arbitration or mediation, even better.

The more contracts you read, the better you’ll get at spotting weird provisions. Trust your judgement: If something doesn’t seem quite right, it probably isn’t.

At minimum, you should ask for an explanation. This is never a waste of time. If you have a lawyer do this, just find someone who doesn’t bill by the hour, or this negotiation will take forever.

5. Pacta sunt servanda

A deal is a deal.

Both in Roman times and today, if you don’t deliver, it’s on you. Keeping promises is fundamental for a professional reputation. That’s why you have to be clear and consistent in the promises you make.

How do inconsistencies arise? One common way is having a statement of work (SOW) that’s not compatible with a master service agreement (MSA). This happens more often than you might think, particularly if no one has ever read that thirty-page agreement. If it’s not clear which one prevails (yes, you have to write it down), you can find yourself in a legal mess.

For example, capping your hours in the MSA is a great way to mitigate the fixed-fee or milestone-based pricing you agreed to in the SOW, but only if the cap prevails! Vice-versa, if you know you’ll only be looking at the SOW and all the special payment provisions are in there, then it should probably override any older pricing rule buried in that thirty pages of small print.

Even better, an MSA doesn’t really need to include thirty nasty pages of small print.

Making a modern contract

I bet you didn’t read iTunes’ latest Terms and Conditions before clicking “I Agree.� We try to read contracts when we think it’s important, but it’s not easy, for several reasons:

  • Contracts are optimized for print, but today we read mostly on screen.
  • They are often poorly formatted and typographically awful.
  • Many elements are difficult to read, like definitions and ALL CAPS PARAGRAPHS.
  • They’re full of legal jargon, not plain language.

The good news is, these problems can be fixed.

Typography

Let’s start with font. Designers and clients alike now mostly read on screens. Electronic signing is a reality, so there are few arguments for optimizing a contract for print.

If you’ve studied typography, you know how to use contrast, proximity, and alignment to create emotional and persuasive effects, and you can apply these same principles to legal text.

Matthew Butterick, author of Typography for Lawyers, has even developed a font optimized for legal text: Equity, a serif font that also looks good on screen—a nice compromise. Whatever you choose, ensure you give your contract balance and contrast.

Typesetting

Contracts are a very peculiar subset of legal documents. How can you use typesetting skills to improve their layout?

  • Structure them in nested lists. HTML does such a great job handling nested lists and headings, so why use a crappy text editor? You often see reckless tabbing and manual line breaks made by frustrated people desperately trying to keep order. Using tools of the trade like Markdown, LaTeX, and Illustrator, you can do better in no time.
  • Divide the boilerplate from the custom terms. Highlight relevant content like party names, important numbers, and percentages so they stand out from the boilerplates and can be easily skimmed.
  • Make important clauses stand out, but never use all caps. The law only asks the drafter, in specific situations, to highlight certain provisions—and there are ways to do that without sacrificing readability. If your lawyer thinks differently, she’s wrong.
  • Allow longer paragraphs. Words need to “breathe,â€� but contracts also need to cluster like clauses for readers. For this reason, line length is a delicate choice that depends both on the length of the clauses in your contract and on the font you choose to use. If you opt for a sans serif, you might get away with longer lines, but be sure to keep generous margins and line spacing (ideally, 120 to 145 percent of the point size, according to Typography for Lawyers).

You’ll also need to decide whether to justify or left-align text. The general rule is that justified text only works with proper hyphenation. This means you’ll have to manually input non-hyphenated breaks for the words you want to keep on the same line. Unless you’re drafting the contract yourself from start to finish, this is a daunting task. And, if your contract manages to have short paragraphs, ragged-right looks more natural, particularly on screen.

When we redesigned Docracy’s PDF typography, we opted for a longer line with lots of white space on the sides. This lets even the longest contract breathe, yet creates a compact final look:

Plain language

Now for the million-dollar question: Why are contracts written in legal jargon? Sadly, it’s because lawyers are too lazy and change-averse to rewrite their forms. The good news is, this is changing. And you can contribute; most formulaic “legalese,� like herein, thereof, or hereby, can just be replaced with “this.� You might even be able to remove entire lines, but better check with a lawyer to make sure.

Here’s an example of traditional contract language rewritten in plain English. Not only is the new version half the length, but it’s much easier to understand:

Before

After

Timing. Designer will prioritize performance of the Services as may be necessary or as identified in the Proposal, and will undertake commercially reasonable efforts to perform the Services within the time(s) identified in the Proposal. Client agrees to review Deliverables within the time identified for such reviews and to promptly either, (i) approve the Deliverables in writing or (ii) provide written comments and/or corrections sufficient to identify the Client’s concerns, objections or corrections to Designer. The Designer shall be entitled to request written clarification of any concern, objection or correction. Client acknowledges and agrees that Designer’s ability to meet any and all schedules is entirely dependent upon Client’s prompt performance of its obligations to provide materials and written approvals and/or instructions pursuant to the Proposal and that any delays in Client’s performance or Changes in the Services or Deliverables requested by Client may delay delivery of the Deliverables. Any such delay caused by Client shall not constitute a breach of any term, condition or Designer’s obligations under this Agreement.

Timing. Designer will prioritize the Services as may be necessary, or as identified in the Proposal, and will take reasonable efforts to perform the Services in a timely manner. Client agrees to review Deliverables within the time identified in Schedule A and to either (i) approve the Deliverables in writing or (ii) provide exhaustive written feedback. Designer may request written clarification of any of Client’s comments. Delays in the performance of the Services due to Client’s late feedback or requested Changes will not constitute a breach of Designer’s obligations.

Classical roots, contemporary documents

There are many reasons the core rules of contracts are still in place two millennia after the fall of Rome. But there are other elements that we can, and should, take to the twenty-first century.

If we want to address the readability problems unique to our era—and improve communication with our clients—then it’s time we fix the language, layout, and typesetting of our contracts. And who better than designers to do it?


  •   
  • Copyright © 1996-2010 BlogmyQuery - BMQ. All rights reserved.
    iDream theme by Templates Next | Powered by WordPress