Designer’s Field Guide
How to Get Started Designing for Developers
4 things you have to know
--
So, you want to design developer experiences?
Awesome! Your timing is great. The employment picture is bright for folks who know how to create products for programmatic or declarative developers. Your first step is to develop empathy for these people by learning what it is like to spend your working life inside a computer.
Inside a computer is an odd place. Everything is literal, nothing is implied. A thousand words are worth more than a picture and being creative means following strict rules perfectly. Not only this but actually getting stuff done means working alone, staring at a screen, while at the very same time actively collaborating with other developers who are themselves working alone, staring at a screen!
Developing empathy for developers means understanding what it is like to spend one’s working life inside a computer.
Bottom line is that the only way to understand this way of working is to experience it personally— at least a little bit. I’ve mentored a few non-technical designers through this learning process and what I am sharing in this post is a roadmap I’ve worked out for getting there in the shortest amount of time possible.
Now, don’t expect magic; working through this 4 step plan will take you at least a day, probably more like two. However, your return on this investment will be high: you’ll get a feel for how it is to work as a developer and insight about what these people expect from their tools.
1. Programming Model
A critical epiphany to understanding developers is realizing that they are writers. They spend their day in a text editor, turning ideas into symbols, words, and expressions, just as does a novelist, screenwriter or poet. The difference, of course, is that instead of a book, movie or poem, the developer’s output is code: the hyper-literal instructions a computer can read.
A critical epiphany is realizing that developers are writers.
The grammar of code is made up of concepts that are consistent across all programming languages:
- values & variables
- operators & statements
- objects & arrays
- loops & functions
You have to understand this programming model because it is central to how developers think.
I recommend you learn this model by reading the introduction and the first four chapters of Eloquent Javascript by Marijn Haverbeke. The book is available online for free but my preference is the nicely made print version.
This book will teach you the programming concepts that are part of every developer’s experience, but only if read the chapters and play with the code. Do this using the inline code editors or the associated interactive playground.
The going gets rougher after chapter 4; you can worry about the later material some other time. ;-)
2. UNIX
UNIX is a computer operating system invented at Bell Labs fifty years ago that remains central to computing today and for the foreseeable future. The relevance to you is that UNIX is — by a large margin — the most common environment in which professional coders operate.
UNIX is incredibly broad and stunningly complex. But don’t worry, all you need to know is how to talk to it and navigate around in it using a command-line interface (CLI).
All you really need to know about UNIX is how to talk to it and navigate around in it.
On a Mac, you get a CLI for talking to UNIX just by opening the Terminal application. PC users have to work harder: first, install some kind of UNIX distribution like this one, and then a terminal emulator like this one.
I like to think of the command line as a chat experience, except I’m chatting with a machine instead of a person. And, just like with any group chat you are on, you have to use a special kind of slang. The best way to learn how to do this is by reading the short and sweet Learning the UNIX Operating System. I honestly believe this will turn out to be some of the most interesting two or three hours you will ever spend in front of a computer!
Once you’ve got a basic familiarity with the command line, you need to practice with it. A good habit is to use a terminal to do the kind of file management task you’d usually do with the Mac Finder or the Windows File Explorer.
3. Git
Another great way to practice speaking command line is to use Git, the version control system developers rely upon to enable that odd way of working that involves being alone and collaborating at the same time.
Developers rely upon a version control system to be able to work alone and collaboratively at the same time.
Git was invented by Linus Torvalds, the same genius who made open-source possible by giving the world LINUX, a free version of the UNIX operating system.
Because developers spend time in Git (or something similar) every single day, being comfortable joining them there has a huge upside for growing your understanding of their experience. The downside is that Git has a very steep learning curve. You can get started with this gentle introduction but getting comfortable with Git means time in the saddle using it to manage files that actually matter to you. If you can, use it on a real project with your developer partners, but if that’s not available to you then fake it by:
- running Git locally (for Mac users Git is there by default, Windows people will need to install it),
- getting a Github account,
- making a repository for your design files,
- backing up your work locally and to the remote throughout your workday.
This not only gives you an online back up for your work — always a good thing— it will also get you comfortable with Git, Github and the difference between them.
Be patient. Git is complicated to learn because it is solving a very hard problem very thoroughly. When you get stuck, and you will, ask a developer for help. Everyone who uses Git has been stuck plenty of times and will be happy to help.
Finally — friendly reminder — use Git from a CLI, not a GUI. That’s what developers do, so you should too.
4. Developer Workflows
The Programming Model, UNIX, & Git are the three systems that underlie the modern developer experience.
This experience also has 3 essential workflows:
- Programming
- Debugging
- Deployment
Understanding the programming workflow is easy for a designer because it is just a coding-specific version of the creative process you already know: make-test-iterate.
As far as the deployment workflow goes, all you need to understand to get started with DX design is the taste of it you get from grasping the local-remote concept in Git.
That leaves the debugging workflow, which you do need to pay special attention to for one simple reason:
whoever has the best debugging workflow wins.
This is so because of how super awful it feels to be stuck with a bad debugging experience. Let’s do a quick exercise to help you understand this pain. First, call to mind a time when you got so angry with your computer that you had to shout out loud. Got a memory of how that feels? OK, now imagine having (and having to work through) that feeling daily, maybe even several times a day. Tough right? Now, the last thing, imagine having that feeling while working against a deadline with your team not only counting on you to get done, but themselves stuck, dead in the water until you do. Yuck.
Unfortunately, every developer has to deal with this experience from time to time; it’s just part of the job. The point you need to internalize here is that even though developers accept this pain, they will value absolutely everything you can do to make those frustrating debugging experiences happen a little less frequently and feel a little less awful.
Doing this well is a hard design problem. I’ve got no magic bullet reference to share for how to design great debugging experiences, but I do have a framework for thinking about the problem that I find very helpful: design time vs run time.
Design time refers to whenever the developer is writing instructions that are being saved (explicitly or implicitly) as one or more static text files. Eliminating errors at this stage produces huge time savings later so a great design time debugging experience prevents bugs from happening in the first place. Standard design patterns here include syntax highlighting, autocomplete, linting, and validation.
A great design time debugging experience prevents bugs from happening in the first place.
Run time, on the other hand, refers to whenever the computer is running the code and executing the instructions for transforming inputs into outputs. Because this process is invisible to the naked eye, a great run time debugging experience helps a developer notice, find, understand and fix the bugs already in the code. There are two main standards. The first is the idea of test-driven development and the second is about exposing, as explicitly as possible, a step by step story of what the computer is doing as it runs the code.
A great run time debugging experience helps developers notice, find, understand and fix the bugs already in the code.
Know Enough to Ask Questions
OK, that’s a wrap, all you need to know to get started designing developer experiences.
You might be thinking, hold on Tim, all you’ve done here is point me at four topics that are each, separately, on their own, a ton of stuff to learn. That’s true but what I’ve found as a DX designer is that I don’t need to be an expert in any of these things, I just need to know enough to be able to ask questions about them. Because — end of the day — asking developers questions about their work, and their tools, is what really teaches you how to be great at designing developer experiences.
Asking developers questions is what really teaches you how to be great at designing developer experiences.
Follow us at @SalesforceUX.
Want to work with us? Contact uxcareers@salesforce.com
Check out the Salesforce Lightning Design System
