Refining Details: Making an Enterprise Experience Better

A natural inclination of designers is to make things look “pretty”. This is not a bad urge. Humans are attracted to attractive things. The problem is when you spend time refining a solution which is fundamentally wrong. Every design decision must have a purpose, and the design as a whole must meet a need.

Once you’ve built something worthwhile, the obvious next step is to turn it from an ugly duckling into a swan. That’s the proper order of things.

In late 2014, I joined Sonatype as a UX developer. At the time, they were in the midst of developing Nexus 3, the next major version of a popular repository management tool used by tens of thousands of developers. Milestone 2 (M2) had just been released.

Repository managers are a fundamental part of modern software development. Software is rarely written from scratch. Instead, you produce and consume binary components that couple together to form a complete application stack. One popular site, Maven Central, does nothing but host these software components.

In order to build your software, you need reliable access to these components. You can run a local Nexus instance to pull down components as needed and cache them for future use. You can also publish your own components, allowing other teams and organizations to use them.

When I started, Nexus looked something like this:

Nexus 3 Milestone 2

This is a perfect example of a valuable tool in need of visual refinement. The goal is to take a tool that is useful and turn it into a tool that is pleasing to use. As a designer and front-end developer, I had the unique opportunity to take full ownership of these improvements. From prioritization to design to implementation, my job was the care and feeding of the Nexus user experience.

Styling improvements

By the time milestone 5 was released, Nexus 3 looked like this:

Nexus 3 Milestone 5

To get the UI to this point, I made a number of refinements. First, I shifted the colors to draw the eye to the most relevant part of the interface. White is a bright color. I wanted to reserve it for the header and content area of the selected feature. Other areas of the interface received darker shades of grey to deemphasize them.

Next, I removed the border underneath the feature icon and title to reflect the way the tool scrolls. In a typical grid view, the icon, title, action buttons, and filter input are fixed to the top. The grid scrolls. To make this relationship clearer, I gave the aforementioned elements a shared white background.

The header received the next batch of changes. The active mode is indicated by a blue background. Because the active mode is such an important visual clue for orientation, I made it full bleed in the header. I also tied it to the rest of the page by adding a caret.

In addition, I revised the header icons from grey to white. This boosted contrast and gave the modes more pop. Finally, I aligned the version number with the baseline of the header title to make the overall effect more cohesive.

With respect to the content area itself, you might notice that M2 had significantly more buttons above the grid. All of these buttons, save one, require that a grid row be selected first. To simplify the UI and make this relationship clearer, I removed the buttons from this view and added them to the detail panel that appears when a row is selected.

Typography played another key role in the improvements. First, we updated the font itself to Proxima Nova, used in our other products. Then, we boosted the size of the feature title to help orient people.

The last thing you might notice is the right-hand carets, one per row in the grid. I added these as an affordance to hint at the result of clicking a row in the grid. I’ll describe this drilldown interaction more thoroughly in the next section.

Replace modals with drilldown

Modals are often a case of lazy design. They are commonly used to enforce a linear workflow. In M2, we used them extensively. One of my goals was to replace modals with a more thoughtfully-designed alternative.

Before drilldown

The alternative I chose is something called “drilldown”. Instead of a modal, when you make a selection, the panel slides to the left and your selection slides in from the right. It includes a breadcrumb, so you can easily navigate back, and supports an arbitrary number of panels. This is handy when traversing a file hierarchy or navigating a wizard.

After drilldown

Replace subpanels with drilldown

Creating and editing objects are very similar tasks. In M2, these tasks had very different UI. Modals were used to create new objects, while editing resulted in a subpanel.

Before drilldown

Thanks to drilldown, I was able to use the same interaction pattern for both. The result? Better consistency across the experience.

After drilldown

Improve optional fieldsets

Optional fieldsets are a control which, when enabled, reveal additional form elements. They declutter a form by hiding non-essential sections of the form.

Before fieldset improvements

In M2, these subpanels shared the same background color as the parent panel, which made them hard to distinguish, particularly when nested. I was able to remedy this by giving each nested subpanel a progressively darker background.

After fieldset improvements

Change sensitive save/discard

Forms become dirty when unsaved changes are made. Dirty forms must be submitted for the changes to persist on the server.

Before save/discard improvements

When not dirty, saving a form is a noop. This is wasteful and doesn’t help the user see if a save is needed. I updated the visual styling of forms to indicate when saving is necessary. If not necessary, the save button is disabled.

After save/discard improvements

Responsive layouts

Fixed layouts have obvious downsides. M2 was not built responsively. Because total responsiveness is a big change, I settled on a smaller change to help us kick the wheels and inform future improvements.

Before responsive layout

Now, the UI has the concept of tiles. Tiles live within the content body, and may be either full width or a smaller, fixed width. In the latter case, they flow based on the available width of the screen.

After responsive layout

Information hierarchy

In M2, content was very flat. Only slight differences in typography and no framing of content.

Before hierarchy improvements

In addition to adding tiles, I also standardized the UI on several tiers of font sizes. These help the eye scan the page and establish a clear hierarchy.

After hierarchy improvements

Prevent accidental discard

Nexus has no concept of undo. When an object is deleted, it cannot be recovered. The problem is obvious. When people accidentally delete something, getting it back is not trivial.

Because of time constraints, we decided against implementing a fully-fledged undo feature. Instead, I implemented a simple warning modal when people make a change to a form and try to navigate away without saving. This was a simple but effective way to accomplish the same outcome.

Discard warning modal

Breadcrumb truncation

Because the drilldown panel can extend to an arbitrary number of panels, and each name can be rather long, I implemented a simple truncation algorithm to prevent the breadcrumb from wrapping or overflowing off the screen.

The algorithm itself is quite simple. Given a number of breadcrumb elements, try to fit them into the available screen width. If they don’t fit, truncate the longest element. Repeat.

Breadcrumb truncation

Lessons Learned

Evolving a legacy experience is entirely possible. The trick is doing so in a way that doesn’t disrupt the development process. As a designer who can code, I have the luxury of taking UX improvements outside of the critical path of development. However, there are still risks.

  • You risk making UX improvements at the expense of making the framework more brittle. If you break things, you could be mopping up bugs for months.
  • You can end up working in a silo. Collaborating with the dev team is a better long-term strategy.
  • You become responsible for writing tests, documentation, and educating other team members on the code you write.
  • As you get closer to GA, UX improvements become seen as a bigger risk, and are easier to defer. This is another reason to work with the dev team, instead of by yourself.
  • UX improvements fit into two buckets. Small, iterative improvements, and improvements which fundamentally change the experience for the better. The former you can tackle by yourself, but the latter requires a team. You’re more likely to be effective at framing the vision and collaborating with the dev team as a whole to make the vision come to pass.

This was a rewarding experience for me, and I highly recommend it to designers who are interested in becoming more vested in the code. The ability to code comes with power and responsibility, but it’s important to weigh it against your long-term goals as a designer. How would you rather spend your finite hours, coding or designing?


Daniel Sauble is a UX designer, speaker, writer, and one-time runner of ultra-marathons. He is currently writing a book about Offline First Development, to be published by Packt by the end of the year.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.