It’s Alive!

Turning design mock-up into reality

Designers have all the fun.

They work with the ideal case, the platonic solid of all mock-ups. Then they click export as... . No edge cases to interfere with impeccable typesetting. No missing APIs to force compromises. No long tail of support to address oversights or upgrades. Just perfect UI harmony.

What do you mean “error”?

I’m being slightly facetious — at some point designers have to deal with a developer, and by extension a computer that tolerates no ambiguity. Depending on the scope, this can be a long collaborative process with complex choices. The ideal case may quickly recede from reach.

That’s not to say the fun is over. Bringing a beautiful design into reality is a process I adore, and for a developer like me there’s an additional dimension of beauty to build into the real digital artifact: a clean, tractable API. From the outside, the API should be a minimal expression of requirements and economy of moving parts. From the inside, a compartmentalization of tasks.

Building towards both a clean API and beautiful design involves the acknowledgment of real-world complexity.

It is that process I would like to catalog. In this article I will outline some high level steps to take when evaluating and implementing a design, and I will frame those steps with a UI mock-up that inspired me.

Credit to Nikita Duhovny for this awesome design

Nice!

In the sections below I will refer to my implementation and the path it took, but you can also see the end result on GitHub.

To be clear, the goal for this specific example is to create a custom component for the scroll bar on the right hand side. It should be attachable to any scrolling content. It might interact with a list of contacts, but should be prepared to support sectioned content as defined by the developer using it. That means it will not be hard-coded with A-Z , or attempt to sort the corresponding collection.

Where to start?

1. Observe.

Unless you are specifically concerned with removing ambiguity, it’s easy to miss a flurry of details in the typical design mock-up. A full-speed demo animation can cruise past critical information in a few frames. If the mock-up is not composed of standard transformations offered by the system UI Toolkit, note those facts early. You may need to approximate the design rather than match it frame for frame, and your designer may decide to revise their approach based on your findings.

Additionally, designs often come with implicit assumptions. Root them out.

What information does the design assume is easily accessible? Is it presenting data you don’t have?

Does the design rely on non-existent APIs or events?

Can you derive missing information yourself, or will your API consumers be forced to inherit the extra complexity?

Does the design assume pretty real-world data? What would the implementation look like if the data is ugly?

When answering these questions, keep in mind your ideal outward-facing API. Building backwards from there, you can discover what minimal extra complexity would allow your component to function.