Many teams may have a front end developer among their ranks, but besides a title or area of responsibility, it can be difficult to pinpoint the exact craft of front end development. Expertise in web technologies is a good start, but we can't forget the users we actually build for. This talk will examine the impact of the front end on User Experience. I'll talk about how becoming more fluent across more UX concerns like content and user research can help front enders make better decisions, can bring more clarity to our craft, and result in building better experiences for our users.

1. UX Fluency
for a better Front End

2. 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 different sized agencies.
Monika Piotrowicz
UX Director, Shopify
@monsika
medium.com/shopify-ux

3. 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

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

5. and although i have a lot of different disciplines on my team, today ‘ll talk about the front end at shopify - fitting audience!

6. I just gave a super simple definition 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

7. • 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

8. So let’s get started with answering one the first 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?

9. WTFED?
• HTML
• CSS
• JavaScript
Back when I started, the definition was pretty straight forward

10. 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

11. 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 defined?
So we have to figure it out!
chaos

12. FED
Design “Back End”
So, taking a step back, in that first, 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.

13. HTML
CSS
JS
Design “Back End”
So let’s keep it simple and keep calling it the HTML, CSS, JS part of your app

14. HTML
CSS
JS
😍
💖
Design “Back End”

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

16. FEDDesign “Back End”
#
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!

17. #🏃
FEDDesign “Back End”
And at the same time, we might be the ones defining 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 find themselves doing some design!

18. #🏃
FEDDesign “Back End”
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?

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

20. 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 find 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 “fluency”.

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

22. Design “Back End”
FED
So we’ve experienced it ourselves, but flipping that around,

23. Design “Back End”
FED
We may be guilty of this ourselves, and can do work to build our own fluency of areas outside of FED so that we can make better decisions just like we hope others will.

24. FEDDesign “Back End”
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.

25. FEDDesign “Back 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 fields that have
already been long settled or turned into conventions. So, if we choose to dive in, becoming fluent in those programming concepts outside of front end might help us make these types of
decisions in the front end as well.

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

27. 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 different 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 find a new perspective
on our own.

28. Great tools and great code aren’t
the end goal
FEDDesign “Back End”
The same thing can happen with this side of fluency - closer to the design side

29. Good tooling itself isn’t
the goal
FED
User Experience
Design “Back End”
And more specifically, 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.

30. & 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 fluency

31. User experience is a person's entire experience using
a particular product, system or service. It includes the
practical, experiential, affective, 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.

32. HTML
CSS
JS
😍
💖
Fed is really the FRONT Line of that user experience then - because all of that effort culminates in the code being served in the browser.
All the planning, design, frameworks, and tools we use are reflected 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.

33. 🛠
And users won’t care if you’re using isomorphic javascript, that you still haven’t upgraded to React, or that your webpack configuration 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.

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

35. 🛠 😀 😀
😀😀
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.

36. 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.

37. 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.

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

39. And at Shopify - we’ve used this definition 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.

40. Part of the UX Process

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

42. Design
Front End Dev
Being part of the UX process means the process looks morel like this - with significant overlap of build while design is iterating so we can influence each other.

43. Design
Front End Dev
At these tail ends, encourages design to help out in the final 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 effectively 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.

44. 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.

46. • 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:

47. 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.

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

49. 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

50. 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 offs 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 different scenarios worldwide. This helps everyone make more informed decisions.

51. 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.

52. 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

53. Accessibility
• prototyping
These are just different fidelities of prototypes, with feedback going back to design

54. Accessibility
• prototyping
And code improving with each round.

55. 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

56. • user testing and research
Article: Running Accessibility Testing How-To
AccessibilityAccessibility
This next one is great example of diving in to fluency 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

57. Content!

58. Content!
Hemingway App

59. Tooling. Finally :)

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

61. FED
#
Design Engineering
And how it’s helped us when we spend time over here - we know our code has to be performant, flexible 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

62. 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.

63. 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,

64. 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 define what great UX even is.

65. 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 fit was the right call!

66. Design FED
Iteration
Build
Review
Learn

67. Our shared design system
polaris.shopify.com
Polaris

68. Building a Culture of Fluency

69. chaosWe still haven’t solved this for front end developers

70. 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.

71. 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.

72. 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 fluency 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

73. 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 fluency 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-specific 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

74. Grow for impact

75. Thanks!
@MON SI KA
ux. shopify.com