UX Fluency for a better Front End

UX Fluency
for a better Front End

I’m a director of user experience at Shopify and have been working as
a front end developer in Toronto since 2008. Previous to Shopify, I had
been working at a number of diﬀerent sized agencies.
Monika Piotrowicz
UX Director, Shopify
@monsika
medium.com/shopify-ux

A bit more about Shopify - we’re a commerce platform helping merchants sell online, in store, and on mobile. My team designs and builds out our marketing materials on shopify.com

as well as features inside of our core product, especially developer-facing features for our API’s

and although i have a lot of diﬀerent disciplines on my team, today ‘ll talk about the front end at shopify - ﬁtting audience!

I just gave a super simple deﬁnition of front end, but i want to dive into it a bit more because i glossed over a ton of detail there - front end is super complex these days
Today
• Complexity of the “front end”
• Discipline Fluency
• Taking advantage of UX Fluency

• First, a little bit more about the FED team at Shopify
• Shopify began over a decade ago but the front end team has been around for less than half that time. When the team got formed, we were starting fro scratch
• We had to start answering some of bigger questions facing a brand new team
• Like what stack we’d choose, and how we worked with other disciplines, and what our mission and purpose was

So let’s get started with answering one the ﬁrst big questions we had to think about
So what is a front end developer?
It’s a bit of a funny question to be asking in front of you, because you’re at a conference called UP FRONT, so I expect each of you has an answer to this because you’re living it day in and day out
Defining FED
Hey UpFront, what do you do?

WTFED?
• HTML
• CSS
• JavaScript
Back when I started, the deﬁnition was pretty straight forward

But now, this simple list of 3 turned into a much longer list as languages and capabilities matured.
We have the rise in web applications, no longer just simple sites and at the same time, greater focus on earlier prototyping, more tools to build interactivity, and the rise of compilation and
bundling tools.
WTFED?
• HTML
• CSS
• JavaScript
• Node/WebPack/Sass/Gulp/PostCSS/jQuery/D3.js/SVG/
CSS Grid/Vue JS/Flexbox/npm/React/Animations/AMP/
PWA/Babel/JSX/OOSCS/BEM/Performance/TypeScript/
Ember/Browserify/Redux/functional/React Native

It’s a lot to take in and it can feel very chaotic, especially for teams trying to grow, or hire, or you’re thinking about your own career path.
Just last week i heard someone describe a role as being “full stack front end” and it really left me scratching my head. We don’t have the language even to describe this role, so how can teams
built, job descriptions well written, career paths deﬁned?
So we have to ﬁgure it out!
chaos

FED
Design “Back End”
So, taking a step back, in that ﬁrst, simpler model, you might have this range of skills.
And FED happily occupies the middle, right, it’s “the front” relative to the back, all the stuff that
happens on a users browser, in the client.

HTML
CSS
JS
So let’s keep it simple and keep calling it the HTML, CSS, JS part of your app

HTML
CSS
JS
😍
💖

FEDDesign “Back End”
With these 3 pillars, the parts in between are the ones that cause the chaos.

#
If we look to the right of this line, we are being much more rigorous with technical decisions - we know what jQuery soup and spaghetti code look like and we know it’s hard to work with. So
we’re looking at architecture and patterns, and including things like testing and even writing Javascrpt on the server - no longer the front!

#🏃
And at the same time, we might be the ones deﬁning the animation states of a design based on what we know is possible and performant in a mobile browser. Or building beautiful SVG’s,
tweaking their output and using complex Javascript to create amazing interactions.
Front enders might ﬁnd themselves doing some design!

#🏃
And so when we look at this whole range, we get into that chaotic state because we wonder, do we need to know it all?
And especially if we spend a lot of time worrying about this right side - about frameworks and tools - How do we decide between different options, what to focus on, and what features we need to
care about?

Talking each other’s languages
Discipline Fluency
And so this is where I want to talk about what i’m calling “discipline ﬂuency”

Fluency means being able to speak another language - and that’s vital when working with cross-disciplinary teams. When you know enough about that discipline to really empathize, to
understand how they approach problems, and their perspective, you build your own context, and it helps you better communicate your own perspective, because you can ﬁnd those
commonalities and better describe the distinctions. It’s that common language and even being able to step into that other role, dip your toes in - that’s why I like calling this “ﬂuency”.

If you’ve worked on cross disciplinary teams, you’ve probably experienced a lack of ﬂuency at some point, especially because front end does occupy that middle space so you might see it in two
directions.

FED
So we’ve experienced it ourselves, but ﬂipping that around,

FED
We may be guilty of this ourselves, and can do work to build our own ﬂuency of areas outside of FED so that we can make better decisions just like we hope others will.

So let’s start on this engineering end - I wager a lot of the chaos we talked about earlier actually comes from the fact that we are building more complex applications today than we were 5 years
ago, but we don’t yet have the technical conventions that might exist already in more traditional, longer standing software development - I’m talking principals of computer science and
engineering that, as front end developers, many of us might be less familiar with if we’ve spend most of our time working on the front end.

MVC vs Component
Static Typing
Functional vs OOP
Developer productivity
Maintenance
Where 5 years ago, not many front enders were thinking about these types of topics, but these are all long-standing components and discussions in other software development ﬁelds that have
already been long settled or turned into conventions. So, if we choose to dive in, becoming ﬂuent in those programming concepts outside of front end might help us make these types of
decisions in the front end as well.

This way, perhaps we won’t be as drawn in to the “ﬂavor of the week tool” debates

JavaScript fatigueOr even worse, developing Javascript fatigue - but that dread you might feel when there’s yet another new tool you feel you need to catch up on.

New tools are just diﬀerent solutions to those really hard problems we’re more recently seeing on the front end, and if we look into other areas of programming, we might ﬁnd a new perspective
on our own.

Great tools and great code aren’t
the end goal
The same thing can happen with this side of ﬂuency - closer to the design side

Good tooling itself isn’t
the goal
FED
User Experience
And more speciﬁcally, what’s in between this spectrum of design to Front End - the user experience of what you’re building, and when we spend a little more time here, it can actually bring a lot
of clarity back to this middle.

& the impact FED has on.. users!
UX Fluency
And so this is where I want to spend a bit more time - and talk about how we can develop and then leverage a UX ﬂuency

User experience is a person's entire experience using
a particular product, system or service. It includes the
practical, experiential, aﬀective, meaningful and
valuable aspects of human–computer interaction and
product ownership. Additionally, it includes a person’s
perceptions of system aspects such as utility, ease of
use and efficiency.
It’s not just the pixels on the mockup that are handed down to someone to code - it’s the full experience your user has, dependent on the user research you’ve done, the IA of the site, the
design, content, through to how well it was executed, how speedy it feels in someone’s hand on their device.

HTML
CSS
JS
😍
💖
Fed is really the FRONT Line of that user experience then - because all of that eﬀort culminates in the code being served in the browser.

All the planning, design, frameworks, and tools we use are reﬂected in the the HTML, CSS, and JS served on the device, experienced while in line at the bank, or relaxing on the couch, or
rushing from one meeting to another. And users just want to complete their task - buy a product, read your article, register for your event.

🛠
And users won’t care if you’re using isomorphic javascript, that you still haven’t upgraded to React, or that your webpack conﬁguration is a work of art. They care that your interface works and
they can get where they need to go. They may notice when things go well, but they’ll DEFINITELY notice when they don’t.

🛠
There’s something incredibly liberating about that - because while we don’t have to optimize for tools, yay!

🛠 😀 😀
😀😀
But it’s a reminder that we DO have to optimize for our users, and all the things they’re going to want to do - and that’s a huge responsibility.

Front end is integral
to User Experience
 
FED is integral to UX - it’s our JOB to build for users, this is why we’re here. Not to create the best framework, not to learn the ins and outs of one tool or another, but to create value for users.
Our tools help us, we need them, and to those building them, thank you. But for most of us, who consume and who hopefully do contribute back, we’re here to USE those tools, think about our
users, and do something that’ll be useful to them.

chaos
The good news, is that when we remember that, we can actually help ourselves get out of this chaos too because by scoping our work to satisfy our users, explicitly, we now have the rules w
need to decide how to spend our time, where to focus, and how to make decisions when it comes to technology. Our users tell us if we’re building the right thing.

• So how do we actually go about doing this? Growing our UX Perspective and putting it into practice?

And at Shopify - we’ve used this deﬁnition to actually structure our team.

So rather than being a specialty under engineering or on our own entirely, we group front end purposely as a part of our user experience team - right beside design, research, and content.

Design
Front End Dev
I’ve worked in this model before - waterfall - design hands oﬀ to development which builds without always knowing why. In this process, the ﬁrst question is “ok how on earth do we build thi
thing we’ve been handed”

Design
Front End Dev
Being part of the UX process means the process looks morel like this - with signiﬁcant overlap of build while design is iterating so we can inﬂuence each other.

Design
Front End Dev
At these tail ends, encourages design to help out in the ﬁnal QA and maintaining quality of build, while at the front, having more high level conversations like - Should we build this? Why?
Only when we know that can we eﬀectively answer the how
This allows the full team to gain the context from the rest of UX on the “why” of our project, and we use this to make better technical decisions. We learn what’s most
important, what’s ok to compromise on, and what’s an experiment we expect we’ll iterate on heavily. Each type of work leads to a different technical outcome.

This is a picture of a kickoff that happened just las week - this is several different projects teams, all under 1 product domain exploring user journeys together. This is a mix of
UXers from design, content, research, and front end, mixed with some of our support team, data engineers, and back end developers - all talking about user challenges. This is
what that diagram looks like in practice.

UX Fluency for a better Front End

• common, shared breakpoints as variables
• common, shared helpers (to show/hide content at breakpoints)
• shared mixins to apply media queries
• JS for responsive images, resize events, etc
• mobile testing lab
As we see repeat scenarios, it’s a strong signal that this might be something important to standardize, so we can start optimizing our toolchain for these known, proven use
cases. Such as:

Performance is another area where that close collaboration with design can help us make better decisions
Performance can be a big numbers game, like all these quotes show, but those numbers don’t always tell the whole story.

Hello world!
The fastest page in the world will be one without images styles or interactivity!

Going back to numbers, these shots hint at something interesting - on top is our speedindex score over the past year for one of our marketing pages
- It’s heading in the right direction, lower is better
- But below, we actually see some resources have increased in size at the same time
- The page is still rendering more quickly because we’ve since made a lot of optimizations, even though we’re doing more on the page.
- Both numbers would tell a different story if we didn’t see them together

Absolutely have a performance budget, but you have to arrive at that number as a team, not as a rule you have to force others to adopt. Instead of a policing tool, we use it for performance
monitoring and a tool for making informed trade oﬀs in our UX process.

For marketing pages, every byte counts, so we always strive to have strong rationales, and with that context, the implementation team can better decide on what options we have to explore,
what the performance implications may be, and how these interfaces are experienced in diﬀerent scenarios worldwide. This helps everyone make more informed decisions.

Accessibility
Accessibility is another area that’s very dependent on a healthy dialog between design and front end. This is something front end developers in particular need to be mindful of - we have a hu
impact but it’s still not something that’s reached a lot of understanding in our industry, or even tooling to help support it, unless we’re deliberate about it.

Accessibility
• prototyping
So with complex UI, we’ve invested the time prototyping options while still in design to vet accessibility and feasibility and work together with design on any adjustments. We understand the
purpose of the design so we can have a more meaningful back and forth during that process

Accessibility
• prototyping
These are just different ﬁdelities of prototypes, with feedback going back to design

Accessibility
• prototyping
And code improving with each round.

Accessibility
• Common abstractions
This is another instance where we saw repeat use cases which we then decided to abstract into our shared framework. We decided accessibility would be a higher priority and made sure we
focused some of our tooling time there because we knew it’d have real impact on users. So the tool is led from UX needs, built to support those needs

• user testing and research
Article: Running Accessibility Testing How-To
AccessibilityAccessibility
This next one is great example of diving in to ﬂuency in another discipline - Here’s a screenshot from a live user testing session with an experienced screen reader user, organized by a front end
developer. It was a great experience for the entire team and it was driven by the deep curiosity for how real users are interacting with the frameworks we’ve built

FEDDesign Engineering
We’ve talked about some UX implications of front end and how all of this context we gathered here

FED
#
Design Engineering
And how it’s helped us when we spend time over here - we know our code has to be performant, ﬂexible to account for unique interfaces, and accessible - and these are no longer abstract
ideas, we’ve seen them in action and have helped design the baseline with our entire UX team.

With that baseline set of features we’re opinionated about, that we decided are important, we can think of how to make those features scale, how we maintain them, and how we make them
approachable to everyone on our team

FED
#
Design Engineering
And when it comes to tooling, we can leverage this very same chaotic spectrum, because individual FEDs have expertise at points across this entire line, and as a team, if we bake each of those
points into our shared frameworks, then no one person does need to know it all! We roll that knowledge up and it’s now available to the entire team.

We’ve been building iterative styleguides for a few years now, and each of these facets has helped us do it. We began with sharing basic styles across projects, focusing on responsive and
accessibility behaviours,

And soon added in dynamic markup helpers and even an API we built in Rails to spit out the regular HTML and associated CSS classes for complex components. We went to the far right in that
case - front enders were spending a lot of time in a Rails back end, but it was in the service of building a great UX by the same team who’s helped deﬁne what great UX even is.

Sometimes we learned lessons the hard way - we had a period where we wanted to
modernize our stack with Browserify, but actually quickly saw
it only made maintenance and onboarding harder, without a positive impact on our
users. So we ripped it out and ﬁt was the right call!

Design FED
Iteration
Build
Review
Learn

Our shared design system
polaris.shopify.com
Polaris

chaosWe still haven’t solved this for front end developers

But we at least have a rubric, maybe not for predicting the future, but at least how to make decisions and what we might want to focus on. We’ve developed an opinion on what’s most important
to our team, and that’s our users. For us, great code and passing tests will never be enough. These principals have helped guide many of our decisions as a team, and weather the storm
happening in the industry. Your team may have different priorities or a different heuristic for decision making, that’s great - and if not, I urge each of you to pause and think of what yours is, or
could be - because this is what has helped us move past that chaos.

Team Growth
These principals also help us here - an area i’ve spent a lot of time thinking about.
*We better know how to structure someone’s growth on the team, and even how we hire and onboard. We know we’ll have to do more than a whiteboard sorting exercise when meeting someon
new.

Continuing to Scale
So what’s next? Still a lot of challenges for FED on the team.
Things on my mind:
How do we continue looking in two directions at the same time, building our ﬂuency in engineering and UX?
Responsive design was a huge shift for UI, what’s the next major change and how adaptive will our team be? Will our model still work

You don’t need to know it all!
• So coming to an end I’ve talked about how as front enders, we need to build our discipline ﬂuency over a wide range of topics can help us zone in on what we think is important.
• I talked about how focusing on UX can actually help us make progress in our FED-speciﬁc skills, tooling and frameworks
• The reason why that is, I think, is because that focus on UX takes us outside of our FED bubble and forces us to look at the external impact we’re having. Real users interact with what we build
and that’s why we’re here. So if nothing else, when you’re in the middle of fretting about which direction to go in, which new trend to dive into, consider its impact. Will it make you a better
developer? Will it help you solve a real problem? Will it be a fun exercise you’ll enjoy? Each is important, and each will lead to a different outcome.
• so don’t set yourself up to having to know it all, but instead strive to use what you do know, to make an impac

Thanks!
@MON SI KA
ux. shopify.com

UX Fluency for a better Front End

More Related Content

What's hot (14)

Similar to UX Fluency for a better Front End (20)

More from Monika Piotrowicz (8)

Recently uploaded (20)

UX Fluency for a better Front End