Designing for Developers
Salesforce UX — Medium | Ben Snyder
Influencing adoption and efficiency of complex applications
In software development, familiarity is a product of repetition — unvaried behaviors involving keyboard shortcuts or routine coding are punctuated by strenuous but recurring events, such as setting up a build or learning a new programming language. This is apparent in usability tests where our team consistently observes a weariness of adopting new tools in the face of jeopardizing familiar workflows.
In retrospect, this all seems obvious, but it still represents a great challenge. How can we design experiences that bridge the gap between these mundane tasks and novel milestones? What can be done to provide value above and beyond that of familiarity? And how can we encourage users — in particular, developers—to try new tools that appear alien at first?
At Salesforce, we’re currently in the process of defining the long term vision for the Salesforce Developer Experience and through this vision, as well as from the success of others (check out offerings like Panic, Atom, Atlassian, and Heroku), three factors that impact these concerns are beginning to take shape:
We’ll have a look at each of these in more detail to see how they can inform more efficient and adoptable experiences.
Brrr… an Experience Iceberg
The Pareto Principle, where 80% of any given set of results come from only 20% of causes, is such a generally applicable rule that almost every system — natural or manmade — has been shown to follow a similar pattern.
Roughly applying this concept to product design, we can use an analogy of an iceberg floating in the ocean. Like the small portion of ice above the water that defines an iceberg, some fraction of features of any given tool define the majority use cases of that tool.
For developers, an example of an “experience iceberg” can be found in Git, the popular tool for distributed version control. Contributing to a repository — arguably the most common use case — requires just a handful of commands (tip of the iceberg). Yet, there’s a long list of commands available to the user (functionality below the waterline). A graph of a novice’s experience with Git might look something like this:
Graph of commonality of a Git workflow
The prevalence of the activities of a workflow can inform how we might design an experience. In the case of Git above, if we were designing for this flow, we could begin to surmise that the actions used sporadically might need be evoked separately, with meaningful user assistance.
Some fraction of features of any given tool define the majority use cases of that tool.
Understanding the entire scope of an experience allows a designer to organize the architecture of an application in a way that is streamlined for specific workflows or personas.
Augmenting Design with Documentation
Auto Complete in Adobe Flash Builder with accompanying documentation. Source
Proper documentation is vital to surfacing the “bottom of the iceberg” when it counts. Setting aside criticisms of Adobe Flash for a moment, one great illustration of this is Adobe Flex Builder (AFB).
Developers are able to evoke almost every aspect of the technology through interstitial navigation — things like autocomplete, hover bubbles, and command prompts that appear temporarily in the UI allow users to surface documentation, common interactions, and code snippets at-will:
A variety of Adobe Flex Builder interactions.
Most of this functionality highlights the abilities of the Eclipse IDE platform that AFB is built on, though the execution of integrated documentation is mostly what makes AFB a useful tool. Although Flash is on its way out and AFB will follow, these patterns are now common place in most code editors today.
Evocation, or the ability to summon knowledge and features at-will, is a skill that is indistinguishable from [keyboard] magic and encourages users to utilize new tools to master challenging subjects.
In fact, the power of evocation is so powerful that I used it to win a Salesforce hackathon, watch the short demo below.
In Jakob Nielsen’s 1993 book, Usability Engineering, the author proposed the now widely used statistic that 0.1 second is the amount of time an action should take to feel instantaneous to a user and anything beyond 1 second will interrupt a thought process.
Unfortunately, this metric of speed is often beyond the influence of design. Interaction shortcuts are only as fast as the processing ability of the software. An alternate objective is to design products or features that shortcut entire workflows.
The Salesforce Developer Console, for instance, is a web-based code editor that, despite limited design attention and a couple of well-known bugs, is the most popular Salesforce code editor. The reason it’s so popular? It is a major shortcut to Salesforce development because it’s accessed from the same runtime it’s used to build (a Salesforce environment). There is no waiting for an app to start or local workspace to setup.
The Salesforce web-based Developer Console
This speed does, however, come at a cost. The developer console lacks the support for frequent tasks such as managing a repository, executing build commands, or easily navigating a project. This divided experience represents a weakness of the console for a number of developers.
While other tools have been release to address this deficiency, including MavensMate, Force.com IDE, or Welkin, the Salesforce Developer Console remains very popular, proving that convenience is a powerful shortcut.
Continuity of Experiences
Resources such asthe Language Server Protocol allow us to describe and build services across platforms thereby promoting continuity of experiences. Features that users are familiar with on their desktop can now be implemented in web-based tools in similar ways.
Cloud9 is a fine example of such continuity:
Cloud9 IDE, a pleasant, but powerful, developer experience.
In Cloud9, a developer moving from their desktop will have fewer obstacles to adoption than, say, moving to the Salesforce Developer Console. Cloud9 mirrors the experiences developers are accustom to: keyboard shortcuts, true file explorer, real command line, custom context menus, and integrated debugging. This increases speed and the likelihood of adoption while limiting unorthodox factors that can lead to decreased quality of work.
Ultimately, the efficiency limit of an application should be informed by the ability of the user, not the processing speed of a computer. By introducing innovative workflows and familiar interaction paradigms, designers can surpass the restraints of technological performance.
The aesthetic-usability effect suggests that visual design influences the way users perceive the effectiveness of an application:
“… users have a positive emotional response to your visual design, and that makes them more tolerant of minor usability issues on your site”
—Nielsen Norman Group, 2017
Whether that means the colors and borders of buttons or the proper display of data in a chart, it’s obvious that proper visual design makes a difference.
The User’s Mental Model, Not Yours
Visualizing concepts in ways that are at odds with how a user might internalize the architecture of a system can have a detrimental effect on the success of a design.
During another recent usability test (sorry, no screenshots… the product is still in development), we introduced a design that was rejected by users. It turned out that our visual design betrayed the user’s mental model of how they expected the experience to look. The design may have been intuitive at face value, but it was spurned by professionals that understood the subject differently.
Usability tests highlighted that our first attempt to translate common Git branching strategies to a UI experience was not quite right.
Research suggests that the design of a system should conform to the mental model of the user, even if that model is based on belief and not facts. Understanding the user’s mental model through in-depth research will lead to a genuine understanding of the user’s perspective and improved visual designs.
Let’s have a look at a Git experience in the command line (CLI):
`git status` output compared to the same with color blindness simulator http://www.color-blindness.com/coblis-color-blindness-simulator/ Src: https://stackoverflow.com/questions/34571498/what-does-dirty-clean-working-directory-mean
This Git command (git status) shows the user changes in their workspace. As you can see above, the color indications are no longer as distinguishable for color blind users, requiring analysis of the text. Now, look at the same output from SourceTree, an app that surfaces the Git experience as a graphical user interface:
`git status` in SourceTree without and with the color blindness filter applied.
The file statuses are more distinguished and the use of iconography is distinct for folks that might be color blind.
This is such a minor example of how inclusive design has the power to delight a much broader variety of users, but it’s an important one to highlight as it requires designers to empathize with individuals that have unfamiliar obstacles to completing common tasks.
Metaphors and Cognition
Another instance of increased comprehension through visualization comes from Heroku where their focus on seamless developer workflows represent the cutting edge of quality design for developers.
Heroku Pipelines uses card metaphors to represent versions of an app.
Heroku’s Pipeline tool displays application versions represented by cards that are stacked into stages of a release process. Each card also displays key fields such as integration status, author, and time of deployment. This all resonates very well with a user’s mental model of release management.
Additionally, the data density and available controls represent a leap forward over traditional tools that might have involved pages of logs, queries, or CLI interactions.
By describing abstract concepts with strong visual design, a designer increases the ability of the user to interact with the tool in ways that amplify the other two factors of evocation and speed.
Mileage May Vary, Know Your Users
The practice of software development is astoundingly broad with millions of developers using a dizzying number of languages, ranging in skill from the ability to create an email using a WYSIWYG editor to writing mission critical software for rocket telemetry equipment.
Given this variety, the depth to which your audience should be exposed to the complexities of a given technology will fluctuate. Keep this in mind as you determine the scope of evocation needed, the shortcuts that can be taken for speed, and the critical mechanisms that need to be communicated through improved visualization.
We’ll be using this insight to help design more delightful developer experiences at Salesforce and I hope you can do the same.
Good luck and happy designing!
Thanks to Sean Calder, Amy Lee, and Raymon Sutedjo-The for the editorial assistance.