-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
425 lines (335 loc) · 38.8 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
<!DOCTYPE html>
<html lang="en" dir="ltr">
<head>
<meta name="description" content="Sarah Li is a Product Designer in San Francisco.">
<meta http-equiv="Content-Type" context="text/html; charset=UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="p:domain_verify" content="bd94de80f86392d5433c6d0bac312a36"/>
<!-- Fonts -->
<link href="https://fonts.googleapis.com/css?family=Playfair+Display:900|Karla:400,400i,700" rel="stylesheet">
<link rel="stylesheet" href="https://unpkg.com/[email protected]/css/tachyons.min.css"/>
<link rel="stylesheet" type="text/css" href="scripts/css/style.css">
<!-- <link rel="stylesheet" type="text/css" href="scripts/css/zoom.css"> -->
<link rel="icon"
type="image/png"
href="images/favicon.png">
<!-- start Google Analytics -->
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-63335278-1', 'auto');
ga('send', 'pageview');
</script>
<!-- end Google Analytics -->
<!-- start Segment -->
<script>
!function(){var analytics=window.analytics=window.analytics||[];if(!analytics.initialize)if(analytics.invoked)window.console&&console.error&&console.error("Segment snippet included twice.");else{analytics.invoked=!0;analytics.methods=["trackSubmit","trackClick","trackLink","trackForm","pageview","identify","reset","group","track","ready","alias","debug","page","once","off","on","addSourceMiddleware","addIntegrationMiddleware","setAnonymousId","addDestinationMiddleware"];analytics.factory=function(e){return function(){var t=Array.prototype.slice.call(arguments);t.unshift(e);analytics.push(t);return analytics}};for(var e=0;e<analytics.methods.length;e++){var key=analytics.methods[e];analytics[key]=analytics.factory(key)}analytics.load=function(key,e){var t=document.createElement("script");t.type="text/javascript";t.async=!0;t.src="https://cdn.segment.com/analytics.js/v1/" + key + "/analytics.min.js";var n=document.getElementsByTagName("script")[0];n.parentNode.insertBefore(t,n);analytics._loadOptions=e};analytics._writeKey="KQJJ0R6DwhY9DaGaROGr3UZiQM3NgpFx";;analytics.SNIPPET_VERSION="4.15.3";
analytics.load("KQJJ0R6DwhY9DaGaROGr3UZiQM3NgpFx");
analytics.page();
}}();
</script>
<!-- end Segment -->
<!-- start Fullstory -->
<script>
window['_fs_debug'] = false;
window['_fs_host'] = 'fullstory.com';
window['_fs_script'] = 'edge.fullstory.com/s/fs.js';
window['_fs_org'] = 'G66Y2';
window['_fs_namespace'] = 'FS';
(function(m,n,e,t,l,o,g,y){
if (e in m) {if(m.console && m.console.log) { m.console.log('FullStory namespace conflict. Please set window["_fs_namespace"].');} return;}
g=m[e]=function(a,b,s){g.q?g.q.push([a,b,s]):g._api(a,b,s);};g.q=[];
o=n.createElement(t);o.async=1;o.crossOrigin='anonymous';o.src='https://'+_fs_script;
y=n.getElementsByTagName(t)[0];y.parentNode.insertBefore(o,y);
g.identify=function(i,v,s){g(l,{uid:i},s);if(v)g(l,v,s)};g.setUserVars=function(v,s){g(l,v,s)};g.event=function(i,v,s){g('event',{n:i,p:v},s)};
g.anonymize=function(){g.identify(!!0)};
g.shutdown=function(){g("rec",!1)};g.restart=function(){g("rec",!0)};
g.log = function(a,b){g("log",[a,b])};
g.consent=function(a){g("consent",!arguments.length||a)};
g.identifyAccount=function(i,v){o='account';v=v||{};v.acctId=i;g(o,v)};
g.clearUserCookie=function(){};
g.setVars=function(n, p){g('setVars',[n,p]);};
g._w={};y='XMLHttpRequest';g._w[y]=m[y];y='fetch';g._w[y]=m[y];
if(m[y])m[y]=function(){return g._w[y].apply(this,arguments)};
g._v="1.3.0";
})(window,document,window['_fs_namespace'],'script','user');
</script>
<!-- end Fullstory -->
<script>
window.onscroll = function() {scrollFunction()};
function scrollFunction() {
if (document.body.scrollTop > 200 || document.documentElement.scrollTop > 200) {
document.getElementById("back-up").style.bottom = "0";
} else {
document.getElementById("back-up").style.bottom = "-100px";
}
}
</script>
<title>Sarah Li, Design</title>
</head>
<body>
<h1 class="ml4 ml6-l ml5-m f2 mt5-l w-80 w-70-l">Sarah Li is a Product Designer in San Francisco. This is an archive of her work.</h1>
<div class="ml4 ml6-l ml5-m w-80 w-50-l">
<div class="mb6">
<p class="f5">Leading <a href="https://paste.twilio.design/">design systems at Twilio</a> since 2019 and always looking for an <a href="https://kottke.org/18/08/the-carrot-is-not-important-chasing-it-is" target="blank">arbitrary stupid goal</a>. Also a <a href="https://eand.co/if-the-point-of-capitalism-is-to-escape-capitalism-then-whats-the-point-of-capitalism-bedd1b2447d" target="_blank">giver</a> of <a href="https://vimeo.com/59384516" target="_blank">gifts</a>.</p>
<p class="f5">From 2017–2018, I was a Product Designer on <a href="https://www.lendup.com/" target="_blank">LendUp</a>’s Arrow Card and led the design of the iOS and Android apps from launch to over 15,000 users. I also worked on cross-platform projects that reached 850,000+ customers.</p>
<p class="f5">Before that, I was at <a href="https://www.hightail.com/" target="_blank">Hightail Spaces</a> (acq. by OpenText), <a href="https://angel.co/clementine-labs" target="_blank">Clementine</a> (acq. by Dropbox), and <a href="https://girlswhocode.com/" target="_blank">Girls Who Code</a>.</p>
<h2 class="f3 mt4-ns">My work</h2>
<p class="f5">📱 <a href="#case-dashboard">Redesigning the Arrow Card dashboard</a></p>
<p class="f5">👩👩👧👦 <a href="#case-system">Managing a design system</a></p>
<p class="f5">💳 <a href="#case-payment">Improving bill payment conversion</a></p>
<p class="f5">👩💻 <a href="#more-work">Branding, icons & more work</a></p>
<p class="f5">Pssst, need a 📄 <a href="https://docs.google.com/document/d/14z84NU9-KIbLrhp-P6zZGDxeVgKqUyeQkkbgNqTwUJk/edit?usp=sharing" target="_blank">résumé</a>? Or just reach out at <a href="mailto:[email protected]">[email protected]</a>.</p>
</div>
<!-- <h2 class="f4">Getting to know our customers</h2>
<p class="f5">There were plenty of popular misconceptions we knew were untrue about our customers when we looked at the data. Our customers skewed older, most were homeowners, and they often knew their finances down to the cent but didn’t have the liquidity to help keep them permanently afloat.</p>
<p class="f5">But—just by virtue of being employees at a Bay Area tech company—we knew we weren’t our customers. We were always conscious of striking the right tone in our product features and copy. There was a fine line between being patronizing and being helpful.</p>
<p class="f5">We used a variety of research methods to avoid designing in a silo and make sure we knew who our customers were. This included <em>ethnographic research, design sprints, usability testing, shadowing customer support calls, outbound customer feedback calls, a dedicated social impact team, and <a href="https://www.consumerfinance.gov/data-research/research-reports/financial-well-being/" target="_blank">industry</a> <a href="https://www.theatlantic.com/magazine/archive/2016/05/my-secret-shame/476415/" target="_blank">reading</a></em>.</p> -->
<!-- <ul>
<li><strong>Ethnographic research</strong> to answer <em>Who might our customers be? Who aren’t our customers?</em></li>
<li><strong>Feature validation</strong>, <em>i.e.</em>, design sprints, to answer <em>Do customers care about any these features? Will they like the way they’re framed?</em></li>
<li><strong>Usability testing</strong> to answer <em>Did we satisfy the customer goals? Can people do the things we want them to be able to do?</em></li>
<li><strong>Shadowing inbound customer support calls</strong> to answer <em>Who are our customers? How does our product succeed or fail at providing utility for them?</em></li>
<li><strong>Post-release outbound customer calls</strong> to answer <em>Who are our customers? How do they feel about and use the product?</em></li>
<li><strong>A dedicated social impact team</strong>, <em>i.e.</em>, our financial health ombud team, who drove financial health surveys, their own ethnographic research, and provided financial health measurement indicators</li>
<li><strong>Industry reading</strong>—Some highlights were <a href="https://www.usfinancialdiaries.org/book/" target="_blank"><em>The Financial Diaries</em></a>, <a href="https://www.theatlantic.com/magazine/archive/2016/05/my-secret-shame/476415/" target="_blank"><em>The Atlantic</em>’s reporting on income volatility in the middle class</a>, and <a href="https://www.consumerfinance.gov/data-research/research-reports/financial-well-being/" target="_blank">research by the CFPB</a> (Consumer Financial Protection Bureau).</li>
</ul> -->
<div class="mb6">
<h1 class="f2" id="case-dashboard">Redesigning the Arrow Card dashboard</h1>
<p class="tc">
<img class="measure-narrow-ns" src="images/dashboard-hero.png" alt="Screenshot of finished Arrow Card mobile app" />
</p>
<p class="f5">LendUp provides loans and credit cards to customers who are often denied access to credit by traditional banks. Driven by a social mission to improve people’s financial health, LendUp builds products with financial education, transparency, and dignity in mind.</p>
<!-- <p class="f5">The experience of the mobile app also mirrored the direction that LendUp wanted to move in as a full financial partner to our customers. Traditionally, LendUp provided loans, which are low-touch experiences (customers logged in to take out loan, then logged in just once more to pay it off), but credit cards could drive far more engagement.</p> -->
<!-- Graph of loans vs. cards engagement, checking balances, multiple payments, checking transactions -->
<p class="f5">I led the redesign of LendUp’s Arrow credit card mobile app account dashboard. I worked alongside a product manager, copywriter, and front-end engineer, and regularly checked in with the design team.</p>
<!-- <h3 class="f5">Why the mobile app matters</h3>
<p class="f5">Our data showed that the mobile app:</p>
<ul class="f5">
<li>drove higher daily engagement than web (a <a href="https://cfsinnovation.org/research/eight-ways-to-measure-financial-health/">measure of financial health</a> according to the CFSI)</li>
<li>on average, monthly payments on the mobile app were 20% higher</li>
</ul> -->
<h2 class="f4 bb mt5">The problem</h2>
<p class="f5">Our support team receives calls with basic questions about customers’ balance, credit, and the payment process. In mid-2017, these calls drove about 30% of total call volume.</p>
<p class="f5">After digging into these calls, we knew there were improvements we could make in the usability of the account dashboard where we showed customers that information.</p>
<p class="tc f5 i caption mb0">The Arrow Card dashboard in 2017</p>
<p class="tc">
<img class="mw5 ba br3" src="images/dashboard-old_app.png" alt="Screenshot of Arrow Card mobile app in 2017" />
</p>
<h2 class="f4 bb mt5">Goals</h2>
<p class="f5">At a high-level, our goals were to:</p>
<ul class="f5">
<li>Decrease the number of customer calls about known issues, including the lack of clarity around available credit, credit line, and payment information. <!-- This would be <em>quantitative and measurable</em>. --></li>
<li>Discover and address usability issues given time and resource constraints, which meant we were limited in considering a broader redesign. <!-- This would be <em>qualitative and testable</em>. --></li>
</ul>
<h2 class="f4 bb mt5">Research & testing</h2>
<p class="f5">From past research, we already knew that our customers needed to know their <strong>available credit</strong> more immediately than their current balance, and often also wanted to know their <strong>credit line</strong>. Since our customers were credit-constrained, the amount of credit they had was always top of mind.</p>
<p class="f5">To discover any unknown issues, we decided to run usability tests on the dashboard and found that people</p>
<ul class="f5">
<li>Didn’t want their <strong>credit score</strong> to be prominent for privacy and emotional reasons</li>
<li>Were intrigued but weren’t sure why <strong>credit utilization</strong> was shown</li>
<li>Couldn’t figure out <strong>how to contact support</strong> but would instinctively scroll to find information they couldn’t immediately find</li>
<li>Weren’t always sure <strong>if a payment was due</strong></li>
<li>Often had to squint or bring their phone up close to read text in the app</li>
</ul>
<p class="f5">The findings confirmed much of what we knew—that the dashboard information hierarchy was unclear, that the app needed to suit audiences with different vision abilities—but it also uncovered much we didn’t know, especially around the emotional experience of checking your account information.</p>
<h2 class="f4 bb mt5">The framework</h2>
<p class="f5">For this project, we adopted the framework in Jason Fried’s article <a href="https://signalvnoise.com/posts/3047-the-obvious-the-easy-and-the-possible" target="_blank">the Obvious, the Easy, and the Possible</a> (OEP) for hierarchy discussions with stakeholders. This helped direct conversations that could’ve derailed with a comment like, “Can you make the font bigger?” to more productive discussions around what information to prioritize.</p>
<p class="f4 f3-ns ml3 ml5-ns">Instead of discussing isolated components, we were now discussing trade-offs.</p>
<p class="f5">From this framework and our research, I landed on a hierarchy for the dashboard.</p>
<p class="tc">
<img class="mw6-ns" src="images/dashboard-OEP.png" alt="Obvious, Easy, Possible chart for the mobile dashboard" />
</p>
<h2 class="f4 bb mt5">The proposal</h2>
<p class="f5">With stakeholders aligned on hierarchy, these are the solutions I proposed for the dashboard.</p>
<h3 class="f4 mt5">Larger type, more linear information flow</h3>
<img class="mw5-ns ml4-ns" src="images/dashboard-proposal1.png" alt="Old vs. new information flow. Animation of account carousel" />
<p class="f5">The dashboard now prioritizes the information that customers need most immediately: available credit, minimum payment information, and making a payment. We moved information that was less desired upfront into a tabbed carousel.</p>
<h3 class="f4 mt5">More discoverable contact form and settings</h3>
<img class="mw5-ns ml4-ns" src="images/dashboard-proposal2.png" alt="Animation of scrolling to footer" />
<p class="f5">Customers can get to their settings and the contact form right on the dashboard instead of having to guess at whether it might be revealed by a side menu icon.</p>
<h3 class="f4 mt5">A simplified, more human payments card</h3>
<img class="measure-narrow-ns" src="images/dashboard-proposal3.png" alt="Moved payment information onto separate payments screen" />
<p class="f5">We moved unnecessary payment information off the main dashboard and onto a separate payments screen to keep the payments card as obvious as possible. I worked with our copywriter to humanize the language around making payments.</p>
<h3 class="f4 mt5">Modular card UI system</h3>
<img class="mw6-ns" src="images/dashboard-proposal4.png" alt="Modular card UI system" />
<p class="f5">This project was a testing ground for our <a href="#case-system">new design component system</a>. I developed a modular card system that we could use for a variety of flows and information types so we could scale our UI and front-end efficiency with new features on the credit card and loans products.</p>
<h3 class="f4 mt5">New visual identity</h3>
<img class="ml4-ns ba br2" src="images/dashboard-final.gif" alt="Full dashboard animation" />
<p class="f5">During this project, LendUp had adopted a new visual identity, and the mobile app was the first customer servicing touchpoint designed to reflect the new brand.</p>
<h2 class="f4 bb mt5">Releasing and iterating on the new dashboard</h2>
<p class="f5">As much as upfront testing helps, releasing the first version of the new dashboard to the public meant there were still issues to be discovered. Thankfully, we had the opportunity to iterate by:</p>
<h2 class="f3 tc">1</h2>
<p class="f5"><strong>Further condensing top-level information.</strong> An earlier version kept credit utilization and the pending transaction amount in the first account summary card where they weren’t needed.</p>
<!-- <img src="" alt="Multiple iterations of the account summary card." /> -->
<h2 class="f3 tc">2</h2>
<p class="f5"><strong>Refining the meters in the carousel cards.</strong> We tested iterations where we changed color or did away with the meter altogether, but ultimately kept them because they helped customers anchor their spending.</p>
<!-- <img src="" alt="Multiple iterations of the carousel meters or the meter style guide" /> -->
<h2 class="f3 tc">3</h2>
<p class="f5"><strong>Testing prototypes that demonstrated even broader redesigns of the dashboard</strong>. This helped us further identify what information customers prioritized.</p>
<div class="tc">
<div class="caption i f5 mb3">Two of the prototypes we tested that I built in Framer, then Principle</div>
<img class="mw5-ns br2 ba" src="images/dashboard-remix1.gif" alt="Card-based redesign of the dashboard" />
<!-- <img class="mw5" src="images/dashboard-remix2.gif" alt="Redesign of the dashboard focused on placing elements offscreen" /> -->
<img class="mw5-ns br2 ba" src="images/dashboard-remix3.gif" alt="Tile-based redesign of the dashboard" />
</div>
<h2 class="f4 bb mt5">Results</h2>
<p class="f5">Since launch…</p>
<p class="f5 ml3">Balance and payment inquiry call volume <em>decreased by ~38%</em>.</p>
<p class="f5 ml3">We ran usability testing again, and participants <em>identified available credit, payment, and contact information faster</em> than in previous tests.</p>
<p class="f5 ml3">Customers now show <em>more focused interaction</em> with the dashboard on the actions we want them to tap on.</p>
<img class="br1" src="images/dashboard-hotspots.png" alt="Evolution of touch hot spots on the dashboard" />
<p class="tc f5 i caption mt0">The evolution of touch hot spots in the app</p>
<p class="f5 mt4">Customers have also sent in great feedback about the app:</p>
<div class="quote pa2 ph3 mw6-ns fl-ns">
<p class="f4 ph1 pb1 pb2-ns mt2 mb0">James Y.</p>
<p class="f5 ph1 mt2">So far so good…Funny enough I actually get more info about my account using the app than desktop login. Love the modern, easy to read design too.</p>
</div>
<div class="quote pa2 ph3 mt1 mb4-ns mw6-ns fr-ns">
<p class="f4 ph1 pb1 pb2-ns mt2 mb0">Misael G.</p>
<p class="f5 ph1 mt2 mb0">App is awsome [sic]…very easy to use and helpful</p>
</div>
<p class="f5 mt4 cb">The Arrow Card app is available now on the <a href="https://itunes.apple.com/us/app/arrow-card/id1228440036?mt=8" target="_blank">App Store</a> and <a href="https://play.google.com/store/apps/details?id=com.lcard_app" target="_blank">Play Store</a>.</p>
</div>
<div class="mb6">
<h1 class="f2" id="case-system">Managing a design system</h1>
<!-- <img src="" alt="Design system flowchart for engineering, design, and source of truth" /> -->
<p class="f5">In late 2017, LendUp adopted a new visual identity, Upswing. We had new styles and some basic components but still had a long way to ago before it could scale across all our products and platforms.</p>
<p class="f5">In other words, we had a few components but <em>no design system and still needed a plan to roll out Upswing</em>.</p>
<p class="f5">The design team knew that to have a functioning design system, we needed to establish processes upfront, not just design components. Figuring out how to manage components across design and engineering would be just as important as building them in the first place.</p>
<p class="tc">
<img class="mw5-ns" src="images/system-goals.png" alt="Components circle inside design system circle" />
</p>
<p class="tc f5 i caption mt0">Components are just one part of a larger design system.</p>
<h2 class="f4 bb mt5">Goals</h2>
<p class="f5 mt4">I created goals for managing our design system so it would be:</p>
<ul class="f5">
<li><strong>Usable for customers</strong>—It should be easy to design components that are intuitive and accessible to our customers.</li>
<li><strong>Usable for the design team</strong>—It should be easy to share components across the design team.</li>
<li><strong>Scalable</strong>—It should be trivial for front-end engineers to extend components to new states and use cases.</li>
<li><strong>Trackable</strong>—It should be easy for the design and engineering teams to check in on progress.</li>
</ul>
<h2 class="f4 bb mt5">Proof of concept</h2>
<p class="f5">Working with a front-end engineer, I used our credit card mobile app as a testing ground for how we might start applying Upswing. Because the app’s codebase was fairly isolated, it made it easy to test there first without major ripple effects.</p>
<p class="f5">After applying Upswing to the app and building out missing components, we validated its usability during the <a href="#case-dashboard">redesign of the app dashboard</a> to make sure components worked well together and were intuitive for customers.</p>
<p class="tc">
<img class="mw6-ns ba br2" src="images/system-cards.png" alt="New components: Card system design guidelines" />
</p>
<h2 class="f4 bb mt5"><span class="strike">Failing</span> Learning fast</h2>
<p class="f5">With this momentum, each designer held initial talks with their product managers to discuss how we might start applying Upswing across the board.</p>
<p class="f5">We realized we could quickly sell product managers on the importance of a cohesive identity. However, it’d be hard for <em>them</em> to turn around and sell the idea of committing design and engineering time to a major “visual redesign” project.</p>
<p class="f5">What we ended up agreeing on was that any new projects on the product roadmap would be built with our new system. I’d already set up components in Sketch so designers could build mockups with them in less time than with our old design language. On the engineering side, there’d be a little overhead per project, but the piecemeal effort was an easier sell than a team-wide commitment of work.</p>
<p class="f4 f3-ns ml3 ml5-ns">Any work done now with Upswing would contribute to less design and technical debt down the road.</p>
<h2 class="f4 bb mt5">The proposal</h2>
<p class="f5">With the product team’s buy-in, we could start honing the design system and processes.</p>
<h3 class="f4 mt5">Designing components</h3>
<p class="f5">Even with all this talk of internal processes, customers were still our #1 priority. Since we were creating so many new components at once, we needed a set of usability standards.</p>
<p class="f5">We adopted accessibility checklists and Eva Kaniasty’s <a href="https://www.lendup.com/blog/design-quality.html" target="_blank">CARMEL</a> guidelines to score the quality of our work. We built on top of the <a href="https://signalvnoise.com/posts/3047-the-obvious-the-easy-and-the-possible" target="_blank">Obvious, Easy, Possible</a> framework and started mapping relationships between an element’s hierarchy and an appropriate component style.</p>
<p class="f5 caption i tc mt4">How OEP mapped to our button components</p>
<p class="tc">
<img class="mt2 measure-ns" src="images/system-OEP.png" alt="Mapping button styles to OEP" />
</p>
<h3 class="f4 mt5">Sharing components</h3>
<img class="ba br2" src="images/system-abstract.png" alt="Our Sketch libraries in Abstract" />
<p class="f5">We settled on Sketch libraries and <a href="https://www.goabstract.com/" target="_blank">Abstract</a> as a way of sharing and managing our components. I helped manage a library of shared global components, while each team managed their own library of product- or platform-specific components.</p>
<p class="f5">Since we were creating components piecemeal, we held frequent design reviews to make sure we were all in sync. Reviews were helpful for identifying components that could be used across teams and could then be promoted to the shared library.</p>
<h3 class="f4 mt5">Scaling components</h3>
<p class="f5">We approached every new project with the assumption that a component or screen design wouldn’t be a one-off solution. Because our CARMEL guidelines emphasized <strong>coherence</strong> and <strong>efficiency</strong>, the quality of our work was directly evaluated on whether it reused existing Upswing components.</p>
<img src="images/system-card_examples.png" alt="Card component examples" />
<p class="f5 caption i tc mt0">The card component could be extended to different use cases across products.</p>
<p class="f5">This in turn made conversations with engineers easier when we knew upfront what components could be adapted with minimal engineering work.</p>
<h3 class="f4 mt5">Tracking progress</h3>
<p class="f5">I landed on a simple shared text table to track touchpoints, ownership, status, and relevant documentation so we knew what we still had left to do. We had too many non-digital touchpoints <!-- (<em>e.g.</em>, credit card plastics, physical mail assets) -->or ones that couldn’t easily link to existing issue tracker tools. Sometimes, the best way to PM just ends up being a text doc.</p>
<p class="f5">On the engineering side, I collaborated with an engineer to build a developer menu to audit components on the mobile app. On web, engineers leveraged <a href="https://storybook.js.org/" target="_blank">Storybook</a>.</p>
<p class="tc">
<img class="mw5-ns" src="images/system-dev_menu.png" alt="Screenshot of developer menu" />
</p>
<p class="f5 caption i tc mt0">The in-app developer menu</p>
<h2 class="f4 bb mt5">Results</h2>
<p class="f5">The processes that helped us ship Upswing made us more efficient at producing quality work and communicating with our teams. Bringing product and engineering into the design system process meant we all had a shared language to talk about hierarchy, components, and visual style—conversations that could otherwise end in cross-functional misunderstanding.</p>
<p class="f5">Setting usability and quality standards meant that the design team presented cohesive work to our product and engineering teams, but <em>more importantly</em>, to our customers.</p>
<img class="ba br2" src="images/system-final.png" alt="Final design guidelines" />
<p class="f5">For our customers, who are already time-, resource-, and money-constrained, it can be hard to tolerate one more frustrating, time-consuming, and disappointing interaction, especially with their financial institutions.</p>
<p class="f5">Our new processes meant that we could ship cohesive experiences faster. And a cohesive experience means that our customers could likewise be efficient in accomplishing what they needed to in our products, thus enabling them to take care of what actually matters outside our products.</p>
<h3 class="f4">What’s next</h3>
<p class="f5">This project made it clear how important a source of truth is for a design system. For designers, that meant a global Sketch library. For engineers, that meant using a shared React component library while <em>also</em> consulting specs for screen mockups. But all of these were functionally different.</p>
<p class="f5">Inspired by <a href="https://airbnb.design/sketching-interfaces/" target="_blank">work from Airbnb’s Design Technology team</a>, a few other designers and I started thinking about how to create a single source of truth for both design <em>and</em> engineering. We wanted to make managing the Sketch library obsolete, make it trivial to go from wireframe to code, and reduce the need for engineers to inspect mockups, instead making it easier to grab CSS right from an already markup-rendered component.</p>
<p class="f5">In mid-2018, we started work on a <em>new</em> new design system, using Storybook and a simple JSON structure for components with attributes for status tracking, type (<em>e.g.</em>, form field), variant (<em>e.g.</em>, currency field), and a link to a file where we rendered each component state (<em>e.g.</em>, error, focus) in HTML/CSS.</p>
<p class="f5">We called it Swingset.</p>
</div>
<div class="mb5">
<h1 class="f2" id="case-payment">Improving bill payment conversion</h1>
<p class="tc">
<img class="measure-narrow-ns" src="images/payment-hero.png" alt="Screenshot of final mobile app payment review step" />
</p>
<p class="f5">The original Arrow Card mobile app payment flow was designed assuming that customers would need to see all their payment details on one screen. While this approach worked for our first few hundred customers, its usability flaws became clear as we scaled.</p>
<p class="f5">Through data and support calls, we saw that customers were confused during the payment process and especially unsure how to continue when the app threw an input error.</p>
<p class="f5">
<p class="tc">
<img class="mw6-l br1" src="images/payment-old.png" alt="The Arrow Card mobile payment screen: please select a bank account error" />
</p>
<p class="f5">Customers paying their bills on time is fundamental, not only to the business, but also to their credit scores. Both reasons made it important for us to make this process as clear as possible.</p>
<p class="f5">For this project, I led the design of the mobile app payment flow and collaborated with a product manager, credit analytics manager, researcher, copywriter, and two engineers.</p>
<h2 class="f4 bb mt5">Goals</h2>
<p class="f5">Our goal was simple: increase the percentage of people who successfully schedule a payment through the app.</p>
<p class="f5">A secondary part of this project was to increase payment amounts through behavioral nudges but only after the redesigned payment flow seemed stable.</p>
<h2 class="f4 bb mt5">The framework</h2>
<p class="f5">In the payment flow, there were three basic choices for customers to make: amount, date, and checking account.</p>
<!-- <p class="f5">From past research, we knew that payment amount was the most sensitive and emotional part of the process. Customers were time-constrained and price-sensitive, and the slightest hurdle or lack of information could cause drop-off.</p> -->
<p class="f5">I wanted to make it as hard as possible for customers to ever run into an error when making any of these choices. Customers should feel as though they were continuously progressing through the flow.</p>
<img class="mt3" src="images/payment-framework.png" alt="New payment flow" />
<p class="f5">Errors that aren’t as preventable upfront might still exist (<em>e.g.</em>, we couldn’t let customers pay more than their current balance), but they should be supported by helpful recovery text.</p>
<h2 class="f4 bb mt5">Testing behavioral nudges</h2>
<p class="f5">On the behavioral nudge side, we already had insights from research we’d done a few months earlier. (Briefly, <a href="https://en.wikipedia.org/wiki/Nudge_theory" target="_blank">nudge theory</a> is the idea that simple suggestions can influence behavior)</p>
<p class="f5">We’d sent an email campaign that encouraged customers to pay more than their minimum amount by offering a variety of financial incentives, as well as no incentive but pure encouragement.</p>
<p class="f4 f3-ns ml3 ml5-ns">Results showed that just pure encouragement, with no material incentive, increased payment amounts.</p>
<p class="f5">This time around, our hypothesis was that customers were being anchored to their minimum payment amount in the payment flow, and we could try to counteract that effect. (For more on anchoring, see <a href="http://coglode.com/gem/anchoring-bias" target="_blank">Coglode’s anchoring bias explanation</a>)</p>
<p class="f5">With the insights from past research in mind, I mapped where we could show encouraging nudges to customers onto the new payment flow:</p>
<img class="mt3" src="images/payment-nudge.png" alt="Payment nudge timeline: When can we nudge?" />
<p class="f5 mt5">We decided to run some initial qualitative research on six different nudge types varying in amount, type of encouragement, and timing to better understand whether the tone of our nudges was appropriate and which types might be more successful when we launched.</p>
<p class="tc">
<img src="images/payment-prototype.gif" alt="One of the nudge types we tested with an interstitial after customers selected payment amount" />
</p>
<p class="tc i caption f5 mt0">One of the nudge types we tested</p>
<p class="f5">After I built the nudge prototypes in Framer, we tested them in-person with research participants and ended up with a spectrum of reactions. Some people found the nudges encouraging while others didn’t understand why they’d want to pay more, or said they just couldn’t pay more, which discouraged and even angered them.</p>
<p class="f5">There were, however, a few patterns that arose. Participants overwhelmingly disliked social proof as a motivator (<em>e.g.</em>, “People like you pay $<em>x</em> on average”). Finances are very emotional and personal, and social proof overstepped those boundaries. (For more about social proof, again see <a href="http://coglode.com/gem/social-default-bias" target="_blank">a Coglode explanation</a>)</p>
<h2 class="f4 bb mt5">The solution</h2>
<p class="f5">We launched the redesigned payment flow in mid-2018, monitoring customer behavior for a few months before launching the behavioral nudges.</p>
<h3 class="f4 mt5">Multi-step payment flow</h3>
<img class="mw5-l ba br2 ml2-ns" src="images/payment-solution1.gif" alt="Animation of multi-step payment flow" />
<p class="f5">The single payment screen became a multi-step flow. A customer could feel a sense of progression through the whole process, rather than being stuck on one screen. This also gave us space to add contextual information along the way.</p>
<h3 class="f4 mt5">Improved error recovery</h3>
<img class="mw5-l ba br2 ml2-ns" src="images/payment-solution2.gif" alt="Animation of adding bank account as a step in the payment flow" />
<p class="f5">The multi-step flow also allowed for validating a single input at each step. This meant that we no longer had to throw an error like “Please enter a bank account,” thus risking a customer not being able to figure out how. Instead, we could build secondary flows (like adding a bank account) into the main payment flow when necessary.</p>
<img class="mw6-l" src="images/payment-solution3.png" alt="Different types of errors in the payment flow, prevented upfront or with more help text" />
<p class="f5">For other types of errors, I decided to prevent as many as I could upfront (<em>e.g.</em>, disabled inputs or buttons). For errors that might result from less predictable, open-ended inputs, our copywriter developed messaging that was contextual and action-oriented to help customers resolve their issues without leaving the screen they’re on.</p>
<h3 class="f4 mt5">Customized amounts</h3>
<img class="mw5-l ba br2 ml2-ns" src="images/payment-solution4.gif" alt="" />
<p class="f5">The final name we gave our behavioral nudges was <em>customized amounts</em>. People reacted negatively to “recommended” amounts in research but said they liked when their products were <em>personalized</em> (there were legal issues with using that one).</p>
<p class="f5">The final design also provided more information about how nudge amounts were calculated or why we might be suggesting them. During testing, people indicated that more information made them feel more in control of their choice.</p>
<h3 class="f4 mt5">Counteracting the anchoring effect <em>lite</em></h3>
<img class="mw5-ns" src="images/[email protected]" alt="Rearranged payment amounts so minimum payment isn't the first" />
<p class="f5">If customers were truly being anchored by their minimum payment, one lightweight nudge we decided to include was a simple reordering of payment amounts. I moved the statement and current balance choices above the minimum payment—roughly in a recommended order.</p>
<h2 class="f4 bb mt5">Results</h2>
<p class="f5">After launching the redesigned payment flow, <em>payment conversion increased from 78% to 92%</em>. Calls from mobile app customers also lowered by 49%.</p>
<p class="f5">For the behavioral nudges, we launched a test of four nudge types along with the reordered payment amounts and a control group, but it’s still too early to tell what the results are. It’ll take a few months to collect statistically significant results because of customers’ payment cycles, and even longer to tell if we’ve effected long-term habits.</p>
<p class="f5">Stay tuned!</p>
</div>
<div class="mb6">
<h1 class="f2" id="more-work">Need more?</h1>
<p class="f5">I’m on 📸 <a href="https://www.instagram.com/serifluous/" target="_blank">Instagram</a>, 📝 <a href="https://medium.com/@serifluous" target="_blank">Medium</a>, 🐙 <a href="https://github.com/serifluous" target="_blank">Github</a>, and 🏀 <a href="https://dribbble.com/serifluous" target="_blank">Dribbble</a>.</p>
<p class="f5">Always looking for interesting projects and down for coffee or tea. Reach out at <a href="mailto:[email protected]">[email protected]</a>.</p>
<h2 class="f4 bb mt5">Work from past lives</h2>
<p class="f5">🎨 <a href="riley/v3/past-art_direction.html">Art direction & branding</a></p>
<!-- <p class="f5">📈 <a href="riley/v3/past-activity_feed.html">Activity feed</a></p> -->
<p class="f5">💬 <a href="riley/v3/past-commenting.html">Commenting engagement & discoverability</a></p>
<p class="f5">📞 <a href="riley/v3/past-iconography.html">Iconography</a></p>
</div>
</div>
<div id="back-up" class="w-100"><p class="tc tr-ns pb0 pt0 pb3-l pr5-m pr6-l">🕴 <a href="">Elevator up</a></p></div>
<!-- @fat's jQuery zoom plugin https://github.com/fat/zoom.js-->
<!-- <script src="scripts/js/zoom.js"></script> -->
</body>
</html>