Technology is often uncomfortable. Using new applications meaningfully requires learning an alien user interface, with all of its quirks and bugs. It’s no wonder that the top 1% of app publishers generate 80% of all downloads. When people have a choice, they choose familiarity.
In business, we can’t avoid new tech. We use tools that exist to get the job done. When we encounter new problems, we need new tools.
It’s easy to focus on the price tag of these tools, but it’s just as important to remember the costs they incur on our employees’ brains. Even tools with good user interfaces require patience and learning. Bad user interfaces frustrate, confuse and demotivate.
In our industry, everything is configurable. Our user interfaces have to reflect that. This requires serious thought from teams that are not only good at designing things visually, but that understand product data. People using software to access this data need to be able to view every option available. Seeing it all at once, though, can be like drinking from a fire hydrant.
At DistributorCentral, we’ve set about solving these tricky user experience problems for our OneSource customers. It’s our goal to make every page of our applications as approachable and intuitive as possible. We want to design carefully. We want to think deeply about how the information on a page will be understood and used.
But we don’t have time to sit in a laboratory and analyze each pixel on the screen. Our customers need us to respond to their feedback quickly. We need to move fast.
Here’s how we’re doing that:
We’re using the best, newest tech we can find to create our interfaces. The tools we use include:
- Material-UI, a set of pre-designed components.
- Storybook, a web application that can be accessed by everyone in the organization to view the UI components we’ve developed.
- Sketch, a Mac application our design team uses to create high-fidelity mockups that we convert into real user interfaces.
At the atomic level, our applications leverage Material-UI, a collection of pre-built user interface components (things like buttons, form inputs, surfaces, and tables). These components are small and focused, yet powerful. Using them maintains a familiar look and feel across applications.
If you use Google, Gmail, or have an Android phone, you’ve already been interacting with these components. Material-UI is continually developed by engineers at Google and is employed in a wide array of Google’s products—it’s a solid starting point for us.
Material-UI provides us with many advantages, but speed isn’t necessarily one of them. If we build our applications only from tiny pieces, we’re bound
to re-create bundles of these pieces everywhere, with no way to identify one bundle as being similar, if not identical to, another bundle.
To solve this, we’ve centered on a process of creating “building blocks” from these small pieces. Our building blocks are slightly larger (yet still re-usable) components designed for specific purposes. We craft blocks deliberately, then debate them, fine-tune them, and finally introduce them into our design-develop workflow.
This makes developing interfaces fast and straightforward. When we need to create a new page, we simply snap blocks together. For example, if we need to display a collection of product images somewhere, we might create a “MediaGallery” building block from Material-UI’s Avatars, Icons, and Grid layouts. The next time we encounter this problem, we simply plug in a “MediaGallery” where it fits.
Telling Stories with UI
Storybook is the factory where building blocks are made. It’s also the warehouse we use to store our components before they see the light of day within our customer-facing applications. Using a separate application for creating components allows us to think about them in isolation and results in components that are immune to the pressures of their eventual surroundings.
In addition to acting as a sandbox for component development, Storybook facilitates the creation of “stories,” which are essentially copies of components configured for different usages. Stories help visually answer questions about components such as “When a button is pressed, what happens?” or “What does this container look like when it’s collapsed?”
Best of all, because Storybook is a web application, we can deploy it on the web and make our components visible to everyone within our organization.
Tightening the Design-Develop Loop
The last piece of the puzzle was improving the workflow between design and development teams. Building interfaces from simple building blocks is a dream for developers, but everything starts with a designer’s mockup.
Early on, our design-develop workflow looked like this:
This one-way flow was not ideal. The design team had little input into the actual components developed and the developers were forced to either 1.
Ignore specifics of the mockup to create “good enough” components or 2. Painstakingly bend and shape components to fit the mockup exactly.
Neither of these choices were ideal.
We decided it would be better if the workflow looked like this:
To this end, we created methods for converting our React components in Storybook to a format usable by Sketch, the application our design team uses to create mockups. The result is that the designers can create mockups using our actual UI components. This makes decisions simpler for both teams and reduces tension and confusion between them.
So far, the results of our efforts have paid off. We recently used these methods to develop the user interface for a Product Review page that will include, among other things, product data, media, decoration locations and charges—both at the product and product part level. The amount of data accessible from this single page is immense, but because of the cooperation between our teams, we were able to create a clean, readable, and attractive interface that we’re very pleased with. We think our customers will be too.