34. Data first
Being Data Driven - culture, objectivity, shared success
Tactical Examples
Signup clicks
Language lost
Confirmation recommend
Data Strategies - be scalable, decouple
35. Data driven
MVP/MLP
Steer UX/system direction
Data supported perspective/opinions
Halt gut-based choices, define questions not assert beliefs.
Avoid “religious debates” (Steve Krug “Don’t Make Me Think”).
Win email/office battles. Have you sent/received this email…
36.
37.
38. #putachartonit
Designer to Developer -- bad UX for aesthetic reasons
Designer to Business -- elegance, consistency
Developer to Business -- scope/time, understanding $ value
Developer to Designer -- technical preference, difficulty/complexity
Business to Developer -- conversions, hunch design
Business to Designer -- bottlenecks, conversion focus
40. Tactical: Signup click
// Signup link clicked.
$(‘a.signup’).on(‘click’, function(e) {
if (cookie.customer) {
// User sent to account.
location.href = ‘/account’;
e.preventDefault();
41. Tactical: Signup click
$(‘a.signup’).on(‘click’, function(e) {
logit(‘Signup link clicked’);
if (cookie.customer) {
logit(‘User sent to account’);
location.href = ‘/account’;
e.preventDefault();
42. Tactical: Signup click
$(‘a.signup’).on(‘click’, function(e) {
logit(‘Signup link clicked’);
if (cookie.customer) {
data.customer = cookie.customer;
logit(‘User sent to account’, data);
location.href = ‘/account’;
e.preventDefault();
46. Tactical examples
Signup clicks
Comments as logging
More ubiquitous collection
NEXT: Language lost...
Business value of data/metrics. So what?
Viable prioritization/debug strategy via data.
Cross-team buy-in: design, development, localization, execs, etc.
47.
48. Tactical: Language lost
var priorPrefix = parseUrl(document.referrer).segments[0],
priorLang = _.contains(prefixList, priorPrefix),
pageIsEnglish = pageSettings.langPrefix === '';
if (priorLang && pageIsEnglish) {
data = {referrer: document.referrer};
logit('Language was lost via link', data);
};
66. Data Strategy
Instrument everywhere
Scalable scenario coverage
Disconnect data gathering from analysis
Speed to insight
Find your sweet spot of data gathering, meaningful. Know what you need yet?
Avoid noise costs
67. Data Strategy
Passive: Page meta data, User details
Active: Form values/modes, Events/interactions
Team: optimization, demand gen, localization, design asking questions
Use in meetings
Watch for anomalies
68. Data Strategy
Breadth - Don’t just log events you care about today. Log it all.
Depth - Don’t just log properties you think matter today. Add them all.
Nirvana - Don’t just decide with data, let the application use the data.
69.
70. Data first!
Being Data Driven - culture, objectivity, shared success
Tactical Examples - Signup clicks, language lost, confirmation recommend
Data Strategies - be scalable, decouple
72. The phrase "Mobile First" was coined in 2009 by Luke Wroblewski, inspiring
a generation of app developers to simplify and focus on what matters most
to users. But the Firsts didn‘t stop there: "Cloud First" emerged as cloud
service providers began commoditizing scalability; as developers have
come to terms with real-world network conditions, even web apps have
become "Offline First."
In their years at Tableau, Josh and Eric have been compiling a list of things
to consider "first" when architecting new apps, sites, systems, and features.
In this talk they‘ll quickly expound on all the "firsts" you should be
considering, and dive deeper into what it means to be "Data First."
Editor's Notes
Introduce ourselves and Tableau
Explain the history story and the presentation concept
The OG concept
The actual first first.
An even more actual first. Getting started writing code… before mobile, or failing.
Keep it DRY.
BREATH
Layouts should accommodate all kinds of words and languages.
User generated content is often terrible.
Systems should separate strings from features.
Have you heard? Sometimes phones aren’t in the city.
You’re not going to host this thing yourself are you!?! Find out how the cloud services you want to use expect things… build on top of them.
You need to know WTF is happening in your application, for debugging and monitoring… or everything is an assumption.
“Analytics for everyone”
APIs, libraries/dependencies, docs, collaboration
Furthermore, configs should be separate from features.
Build things to be kicked off via command line then build an admin interface.
Debugging is the same stupid few things 90% of the time.
Deploying manually, not even once.
Make up fun name for you library, each subsystem, etc. The band name is the most critical part of starting a band.
Find the problems to solve, not the solutions.
User first
It’s a team project to design the workflow to accommodate that.
Is the primary interface a search mechanism?
Design for adjustments not static content.
Duh.
Allow for experimentation when you don’t know what you want.
Circle back to make the reproducible system. Make time to regularly check in with content creators on what needs to be systematized.
Example: whitepaper as interactive parallax stories.
Partnerships will be critical, so make them happy in your basic planning.
How should the UI feel?
Reality.
SOFT FIRSTS
Include several explicit examples!
Oh shit moment!
Entirely different tone.
Clear peek into available information
Shuts down opinion-based thread
Created a desire for understanding
Perspective voices
Advocates of concern
Naturally different motivations
Value proposition
Perception of difficulty to get started with logging.
All (good) code has comments.
Convert comments into logging.
Augment with additional available data.
Chart via...
Timeseries
Page actions
Facet by customer status
“DAVE”
Let the robots do it for you.
Just do it everywhere, rather than the one click.
Chart via...
Page views with referrer like
Facet by customer status
Rather then click page actions
Business value of data/metrics. So what?
Viable prioritization/debug strategy via data.
Cross-team buy-in: design, development, localization, execs, etc.
“DAVE”
Let the robots do it for you.
Prospect starts a trial. Very important signal.
Training is important, but how else do we make them successful?
Guidebook contains very useful tips for making visualizations useful
But is this the most appropriate thing to show prospects starting a trial?
Because we’re so Data First, we can do the analysis!
#DataFirst! We decorate every response with a “content type” and “title” attribute.
#DataFirst! We name all of our lead activity events.
With that, we’re able to see how popular our whitepapers are… Visual Analysis Best Practices is pretty high up there.
I’ve got a hunch! Maybe it’s not super appropriate for all of our personas.
One key persona is a kind of “business analyst”
#DataFirst! We also decorate lead activity events with key details about the lead, like job level.
Visual Analysis Best practices ranks higher, but some more data analyst-specific content bubbles up.
How about someone who’s more of an IT decision maker?
Whoa. Visual Analysis Best Practices doesn’t show up at all.
More big-picture trend pieces, analyst reports, etc.
You’ve made some great discoveries. Different personas prefer different types of content.
So what do you do? You fire up JIRA and open up a feature request, right?
“For the following persona, highlight the following whitepaper on trial confirmation.”
“For this persona, highlight this whitepaper on trial confirmation.
WRONG
#DataFirst dude!
All of the data you need to make a decision is already in your analytics platform.
That analytics platform probably has a an API! You could automate this!
“DAVE”
Make analytics data a first class entity in your system.
Let the robots do it for you.
When you do, you enable app administrators and users to self-serve
Automate some decision making.
Trying to control the end result first is impossible. There’s so much to think about, but you should really be thinking about all of them.