The document provides guidelines for how design and engineering teams at Square work together to achieve the best possible product outcomes. It begins with an example case study of how the teams collaborated to design an accurate one-pixel straight line. The presentation outlines that design and engineering are interdependent and cannot exist without each other. It emphasizes starting projects with all teams involved from the beginning, understanding requirements, designing all states, and engineers making designs come to life beyond initial visions. Common language and proper communication between the disciplines is key.

1. Hi. A bit about me.
Presentation has two parts.
1. Case Study of a project I can’t show you but I believe captures the spirit of how we work at Square. This part
will be fast.
2. Guidelines that illustrate how important the marriage of Design and Engineering is at Square. We’re still a
startup.
This may be a different kind of presentation but I hope it works for you all. Let’s start with a short video.

3. HOW TO DRAW
A STRAIGHT LINE
This is what I’d like to talk about first.
It serves to illustrate how the most basic design task can’t happen without an engineer and how both sides work
together and push each other to ensure the most perfect results.

4. Inevitable you will hear a presentation that talks about design being how you get from point A to point B. Instead
of talking in broad generalizations I decided to focus on that specific straight line.

5. This is how I draw a straight line. Not very good, right?

6. If we go back in history, Cave-person drawings were not much better. Straight as an arrow had a different
meaning back in 5,000 B.C. If we look at what they were doing it’s not bad given that they didn’t have
rulers.

7. Egyptians got a little better. The designers of the great pyramids got a little help
from the engineers.

8. who invented the plumb line and made one of the seven wonders possible.

9. y = mx +
b
then we get a mathematical formula for it with Euclid and all the theory behind that.

10. at this point you might be thinking, i got a plumb line. i can figure out some kind of saw. let’s make a
ruler and get on with it.
and this is where the case study begins. we obsess about the details and we want to make sure that we
create experiences that are as simple and as transparent as possible for our customers.
a ruler is just not good enough.

11. PRECISE
a ruler is precise

12. ACCURATE
a ruler is not accurate. we need to be accurate. there’s a whole other side to design at Square which deals
with the Wabi-Sabi aesthetic or imperfectness, but that’s a different case study.

13. So, in the 1800s a french engineer named Peaucellier invented the Peaucellier–Lipkin linkage. The first
machine to draw a perfectly straight line.

14. this is how the system works. finally we had an accurate line.

15. Then we got computers and this is how they draw lines
There are a few ways to they do it. Bresenham's line algorithm — optimized to use only additions (i.e. no divisions
or multiplications); it also avoids floating-point computations.
this is where we get to present day at Square. we are developing a new interface that calls for a straight line. and
we begin by questioning how can we make the best possible straight line. the engineers and designer sit side by
side to make this happen.
btw, i’m not the engineer so excuse me if i don’t do justice to their contribution.

16. 1
#html
2
.example
3
hr
4
5
6
7
8
9
10
11
12
13
14
html. this is option 1. we would do this 15 years ago.

17. 1
#css-­‐border
2
.example
3
.css-­‐border
4
!
5
!
6
.css-­‐border
7
border-­‐bottom:
1px
solid
black
8
9
10
11
12
13
14
css. then we did this. both begin to break down in certain scenarios, particularly
when dealing with iOS retina devices.

18. 1
#css-­‐shadow
2
.example
3
.css-­‐shadow
4
!
5
!
6
.css-­‐shadow
7
box-­‐shadow:
0
1px
1px
-­‐1px
black
8
9
10
11
12
13
14
css box shadow. So to correct for this engineers came up with the css box shadow. is everyone following
this? this is basically a 1 pixel line with a cropped shadow that comes close to recreating accurately in
Retina, but not quite.

19. 1
#svg
2
.example
3
svg
xmlns="http://www.w3.org/2000/svg"
version="1.1"
4
line
x1="0"
y1="0"
x2="100%"
y2="0"
5
!
6
svg
7
width:
100%
8
height:
1px
9
line
10
stroke-­‐width:
1
11
stroke:
black
12
13
14
svg. then this happens. this is a true 1 pixel Retina line. it is perfect and looks
amazing.

20. #html
#css-­‐border
#css-­‐shadow
#svg
this is what we knew we wanted but we had to keep at it until we achieved the best
possible result.

21. this is our case study and it’s going to be great, when i launches. :-)

22. designgineer
s
engaged
engaged
Let me be specific about how we get that done:
The key takeaway from this deck is that design and engineering cannot exists without the other.
Nothing happens without an engineer. They make it all happen.
It’s about how to make the designs not only pixel perfect, but come to life like you couldn’t even imagine.

23. s
s
engaged
-
understanding
kickoff the project with everyone in the room
the days of waterfall methodology seem ancient to me.
sit next to each other.
design in code.

24. s kickoff the
kickoff the project
project with
with everyone in
everyone in the
the room
sit next to
each other
-
methodologies
are outdated
design in code
understanding
kickoff the project with everyone in the room
the days of waterfall methodology seem ancient to me.
sit next to each other.
design in code.

25. s
s
understanding
-
!
understanding
define the audience, the goals and the metrics. performance is as much a part of the experience as is the photography.
understand form factors and breakpoints
design every state
explain the core of what you’re trying to accomplish, not just your proposed solution.

26. s define the
understand form
audience, goals,
factors and
and metrics
breakpoints
design
design
every state
-
defend
defend
your design
understanding
define the audience, the goals and the metrics. performance is as much a part of the experience as is the photography.
understand form factors and breakpoints
design every state
explain the core of what you’re trying to accomplish, not just your proposed solution.

27. s
s
communicatio
n
understanding
Common Language
- typography, styles, the grid. the framework for what you’re building. the system.
- annotate as much as they need but no more.
- know what ‘jank’ means, etc.
- understand bugzilla, jira, etc., know how to QA and submit feedback

28. s framework
the
of what you’re
building
know what
what
‘jank’ means
annotate more
than they need
know how to
submit feedback
understanding
Common Language
- typography, styles, the grid. the framework for what you’re building. the system.
- annotate as much as they need but no more.
- know what ‘jank’ means, etc.
- understand bugzilla, jira, etc., know how to QA and submit feedback

29. s
s
don’ts
define the scope and stick to it.
don’t compromise.
don’t compress their timeline.
don’t say it’s final if it’s not.
understanding

30. s
define the scope
and stick to it
don’t compress
their timeline
define the scope and stick to it.
don’t compromise.
don’t compress their timeline.
don’t say it’s final if it’s not.
don’t
don’t
compromise
don’t say it’s final
final
if it’s not
understanding

31. thank you