Picture yourself hiking a trail that gradually goes uphill. You barely realize the increased elevation until you come to a clearing with a beautiful vista. That’s the same feeling an elevated user experience gives you.
A well developed experience lifts users up, enabling them to do more, see more, and be more. But just as a trail has a mountain of granite under it, an elevated user experience needs a solid foundation that won’t crumble when trodden. That foundation requires everyone — including engineers — to think about how the things they’re building affect the end user.
Salesforce has always sought to elevate its users — whether by leveling up their skills or ensuring they can focus on their business instead of their software — and Salesforce Heroku is no exception. The teams working on the Heroku platform have built a best-in-class developer experience that our customers trust. The principles that guide Heroku are ones we can all use to create experiences our customers love.
Let’s take those principles for a hike. When you hit the trail, you’ll need the experience to lead the way.
Experience-Driven Development
You can’t slap a good user experience atop a disjoint menagerie of features. The desired experience must precede everything else in the design process.
Consider Amazon Web Services (AWS): there’s nothing unattractive about the web interface, but the myriad components it allows you to manage result in a daunting experience. Piecing them together to make an app that’s scalable, secure, and maintainable is anything but effortless (if you do want to learn how to work with AWS, there’s a Trail for that… but I digress).
Contrast AWS with Heroku, where experience comes first. Heroku was designed, from the outset, to be developer friendly. We identified our target user as ourselves and continuously asked each other if we were delighted by the experiences we’d created. Even today, much of Heroku’s infrastructure runs on Heroku, and with every interaction — whether it’s seamless integration with Git, automatically detecting the programming language, or scaling up a process — the feeling is effortless.
Your engineering decisions should be driven by the user experience you want to deliver. Every choice you make, new construct you introduce, and feature you roll out must serve to improve the user experience for your customers.
Simple is hard
Heroku encourages a maniacal focus on simplicity, which you can find evidence of everywhere. Deploying with git push heroku master, provisioning an entire Kafka cluster with heroku addons:create, and promoting your staging app to production with a single click — these are all examples of how simple Heroku can be.
Heroku teams often push themselves toward simplicity by saying “1 step is better than 2 steps” or even “there should be no step 1.” They always question if something can be simpler or if they can remove friction for the user. This applies to their work on the CLI, buildpacks, Add-ons, Postgres, and more.
It’s easy to state this value, but it’s hard to uphold. Keeping it simple for your users often means making it complicated for yourself. You may need to increase your operational burden to build an elevated user experience.
Be opinionated
Software is full of decisions that someone has to make. If you hand those decisions directly to the user, they’re forced to evaluate each option, weigh their choices, and form an opinion. So why make them decide at all?
Your customers will love you for the decisions they don’t have to make. It allows them to focus on the work that adds value to their business, instead of solving problems that just get in the way of the business.
One of the ways you can express your product’s opinions is by favoring convention over configuration. Some good examples are the Heroku CLI and buildpacks, which tend to “just work“ without any configuration. A user’s first git push heroku master will succeed because the platform makes decisions about their app for them — they don’t need to provide any configuration or change their code. There’s a much-coveted term for this: the “A-Ha Moment”! It’s the holy grail of new user onboarding milestones, and your goal is to get users to this moment as fast as possible.
There are times when configuration is necessary, but we need to wield it carefully. The history and overlap of Heroku’s Procfile, .buildpacks, app.json, and heroku.yml is an example of how one can go wrong when not careful. The product needs to be flexible enough that customers can solve their own problems, but there is value in a less flexible experience that just works. Create a machete, not a Swiss Army knife.
Do more with less
Do more and more with less and less until eventually you can do everything with nothing. This is the main tenet of Ephemeralization as defined by Buckminster Fuller, and it’s been a guiding principle of Heroku engineering and product design since the company’s inception. Internally, it helps Heroku teams succeed at building scalable and maintainable infrastructure. Externally, it guides them toward a lean product that has not turned into a Swiss Army knife despite ever-expanding capabilities.
For Heroku’s customers, the platform represents the ephemeralization of server infrastructure. Instead of managing their own servers, they run their apps in the cloud. Instead of managing virtual servers in the cloud, they manage nothing. Every product you ship should allow your customers to do more with less.
A good example of ephemeralization is the Heroku stack image, which provides an operating system with essential packages like gcc, libpq, and openssl. The stack is updated automatically for customers without them taking any action, which means the need to install security patches for severe vulnerabilities like Heartbleed literally disappears — it becomes ephemeral.
Developers, developers, developers
Developers are the new kingmakers but I think we can expand this definition to include anyone who is a maker. Every one of our products and every one of your decisions should serve to make their lives easier. This is how we beat our competitors.
I like to compare our biggest customers’ developers to kids in a toy store (I’m not saying developers are children, though, stay with me). Children don’t have purchasing power and they don’t make the final decision to buy something. But if the kid isn’t happy — if the kid doesn’t like the toy- — then the parent isn’t going to buy the product. Likewise, developers at Eli Lilly or Toyota don’t have purchasing power, but their love for our platform keeps them as customers.
So how do you know when you’re empowering makers? A good rule of thumb is: if you need to ask your users to do something, you’ve failed them. If they have to run a command to migrate their app or if they have to add a new file to their repo so that it works on Heroku, then there’s a good chance you could have done a better job.
Designers, designers, designers
In a sense, we are all designers. Whether we’re implementing a new cloud architecture, developing predictive models, or optimizing performance; the choices we make affect the customer experience. This is where the Heroku values come into line with Salesforce’s efforts to democratize design and enable everyone to be a designer.
Like any discipline, design is a skill that must be honed. One of the best ways to sharpen this skill is by getting close to customers. Pick one customer, and get to know them. Understand their journey, and learn what experiences they need. If you want to take a smaller step, follow the Design at Salesforce trail on Trailhead.
With good design, we can elevate our users and they’ll love us for it. But love doesn’t help our bottom-line. The real value of good design is that it ensures our customers spend their energy on the things that matter most to their businesses.
Elevate your users above the value-line
Salesforce Heroku will not race to provide every capability under the sun. Instead, it will keep its maniacal focus on the features that allow customers to contribute above the value-line — to elevate them. But doing so means making tough choices.
Heroku succeeded in building a revolutionary developer experience over the last decade in part because it was small and nimble. In the early days it could be opinionated because it didn’t have a huge established customer base that would push back against new ideas. But its customers have grown with the platform and today they still want Heroku to be opinionated. Salesforce is no different: we need to be opinionated because that’s how we’ll keep our customers.
A bad experience is a liability — it’s a risk to the business. At some point, a customer will recognize that the time and energy they waste on bad experiences is costing them money. When their makers spend time on work that doesn’t directly add value to the business, it will drive them toward better experiences on other platforms.
With every engineering decision you make, new thing you build, and bug you fix, ask yourself: are you elevating your customers above the value-line?
