Building better front ends

19
BUILDING BETTER FRONT ENDS What is your product’s personality? Tulsi Dharmarajan

description

What's your product's personality? Is it welcoming, engaging, friendly? This presentation discusses some ideas to identify, follow a consistent tone through your application and establish best practices within your team.

Transcript of Building better front ends

Page 1: Building better front ends

BUILDING BETTER FRONT ENDSWhat is your product’s personality?

Tulsi Dharmarajan

Page 2: Building better front ends
Page 3: Building better front ends

About me

• Sr. Product Manager at Allegiance, a leading provider of VOC & EFM

Contact information: http://www.linkedin.com/in/tulsid http://twitter.com/tulsid

Page 4: Building better front ends

AGENDA

Product personalitySimple oversightsImproving requirementsCreating design advocates

Page 5: Building better front ends

Tone of the product

Do you know the personality of your product? Friendly Casual Cool Formal

Identify the tone that will portray the personality

Then, communicate this through the organization

Page 6: Building better front ends

Simple oversights

Examples of things to notice: Capitalization Spelling & grammatical mistakes Inconsistency Alignment & spacing Date & numeric formats

Include notes on the above in requirement documents Publish standards so they are avoided Communicate mistakes so they’re not repeated

Page 7: Building better front ends

Error messages

Avoid sending the user mixed signals

Page 8: Building better front ends

IMPROVING REQUIREMENTS

Page 9: Building better front ends

Improve error messages

Remember the tone! Talk like a person, not a database Slightly self deprecating and never blame the

user Let the user know what to do next

Page 10: Building better front ends

Error messages, continued

Examples of meaningful error messages from LastFMNing.

Page 11: Building better front ends

What do we call “it”?

Who is the user and what will they most easily get?

Is “Submit” or “Save” better? Should the button be “Add Batch File” or “New

Email List”

Remember the tone! Decide naming conventions early in the cycle Publish and share naming paradigms within the

organization

Page 12: Building better front ends

Blank slates

What will the user see when they visit a page for the first time?

Wufoo (top) maintains the personality – with the tone, color, and font. LightCMS (right) provides useful information on getting started and where to find more help.

Page 13: Building better front ends

Good defaults

Answer the most common questions

CampaignMonitor auto selects time-zone based on user location

Page 14: Building better front ends

Embrace minimalism!

Remember the 80/20 rule Minimize distractions Bring core content to the forefront Don’t add a feature unless absolutely needed.

(There’s always advanced options!)

TeuxDeux

Page 15: Building better front ends

Less is more

Less navigation = less training

eGain Service

Page 16: Building better front ends

CREATE DESIGN ADVOCATES

Page 17: Building better front ends

Spread the word!

Stress the details and share the stress Point out the little things to engineering & QA

– they will take notice! Inspire engineers & QA to get excited about

the things you are excited about

Page 18: Building better front ends

Example of guidelines

Capitalization Labels

Title Case. The only exception is for radio buttons/checkboxes. Avoid the use of articles (a, the etc) Should be as short as possible Avoid terms that are Allegiance specific. Instead find a familiar

word Buttons

Single word if possible. “Save” is better than “Save Survey” Title Case Avoid articles and conjunctions

Sentence case: Only the first word is capitalized Exception: Proper nouns

Title Case: All words are capitalized except: Articles (a, an, the) Conjunctions (and, or)

Page 19: Building better front ends

RECAPRemember the tone!Decide naming conventions early in the cycleSpecify error messagesRemember to include defaultsCreate standards for everything & spread the word