Redesigning The Structure Of Our App’s UI

A Quest for Consistency

TL;DR

Here It Is In a Nutshell

Nearly 6 months into a massive overhaul of our core product, we noticed that the user interface was becoming less and less cohesive. In fact, it was becoming pretty fragmented. I was given the task of restoring order to the universe.

Sketching helps me refine rough ideas quickly

I approached the problem systematically, pulling apart each interface to identify what components they all had in common, listing out all the unique components, then sketching each UI again and again until I felt they were all aligned.

Since learning about React, I think in terms of components — I can’t help it!

Our team’s lead developer and I arrived at 4 basic layout components that could be used to compose any of our current views, and provided a turnkey solution for future layouts.

My familiarity with ReactJS was extremely helpful when collaborating with developers

Finally, I turned to my trusty combination of ReactJS + MeteorJS to model these components in code and do the visual design. This has always worked great for me because developers can usually copy/paste sections of my code, saving all of us time.

All this refactoring resulted in a much cleaner interface, consistent responsive behavior, and a more powerful set of patterns and components to guide the design of future interfaces.


The Full Story

Here’s a more detailed version of how the project unfolded.

Our Problem

The components we were using for our layouts were pretty fragmented. Depending on the view, you might see completely different design patterns employed for the same problem, and different components used for essentially the same interface element.

In my assessment, we were accumulating clutter and I knew it would be hard to end up with a clean design system the longer we let this go.

Clutter stems from a lack of intentionality, a steady drip of one-off implementations, and losing sight of the forest for the trees. It manifests itself visually, in crowded, confusing interfaces, and behind the scenes in the code. Even though we’re using React, a framework that’s totally oriented around modularity and reuse, those principles hadn’t translated into our designs very well, particularly our layouts.

In interfaces, clutter stems from a lack of intentionality, a steady drip of one-off implementations, and losing sight of the forest for the trees.

We saw an opportunity to fix a lot of these issues before they ballooned into something more serious. I argued that this kind of refactoring would help us move faster when building additional views, adding quality through the process instead of at the end.

The Original Idea

In the beginning we knew we wanted a “fullscreen” responsive app, i.e. where our interface would fill the entire width of the screen and have some degree of vertical responsiveness.

Some of my early sketches

We ultimately landed on just two layout components — one that would subdivide space vertically, the other horizontally — and by combining and nesting those two components we believed we would be able to create any layout we needed.

It’s really important to consider the responsive behavior of any layout, especially when it’s full-width

Our First “Real” Implementation

Besides a prototype that we threw together in two weeks at the very beginning of the project (mostly to prove out certain technologies), this was our first stab at really implementing all these components.

How I Went About Making Changes

1. Identifying existing components
Before embarking on any redesign, it’s important to examine what you’re about to redo, take it apart, acknowledge the reasons why something was designed that way in the first place, and decide whether it needs to be reconsidered. I tried to do this first, then made some decisions about which components should be unique to just one view, shared across multiple views, or shared across all views as a site-wide convention.

I inventoried all the unique components and decided which of them should be shared across views

2. Sketching
At this point, it was time to see how my ideas would hold up in more realistic UI concepts. Sketching the same view in multiple states forced me to wrestle with a lot of usability considerations, and keep iterating until I felt like everything was falling into place.

For me, sketching, wireframing, and prototyping are different design methods with largely the same purpose — seeing whether an idea will actually work in real software, with all its constraints

3. Wireframing
This is where the constraints really come knocking. How will these interface elements respond at narrower widths? What if this string length exceeds n characters? How will this toolbar work? When we introduce this feature, where will it go?

I found myself considering features that didn’t yet exist because I recognized that I wasn’t just designing a series of “templates,” I was designing a flexible design system, one that would still need to work when we implement all kinds of features later on. When I got the question, I was prepared to respond because I had thought about it already.

With such important layout decisions to make, I knew I need to consider features we didn’t yet have — like filters

4. Prototyping
This is one of my favorite parts — jumping into the code. I’ll be perfectly upfront about the fact that I’m not a Javascript developer. I’m completely self-taught and at this point I haven’t gone deep into the logic, but I do leverage the power of something like React to build out reusable UI components. ReactJS + MeteorJS are hands-down the best combination I’ve found for rapid prototyping with code.

Plus, the developers I work with love that they can just copy/paste portions of my code. It saves us all lots of back-and-forth, and it gives me a greater stake in the end result, even recommending a specific structure and naming scheme for our components if I so desire.

A little bit of React + JSX from my prototype

Our Second Implementation

We changed a bunch of things under the hood and made some significant improvements to the visual design of the app. What excited me the most, however, were the site-wide patterns that were introduced and consistently applied.

The app was now better poised to scale — visually and architecturally. This increases the likelihood that future designs will fit into a consistent application experience, improves usability, and helps our designers and developers become more efficient.