Uploadcare Widget Redesign
Uploadcare Widget is a flagship feature: an ultimate file uploader aimed at forever replacing <input type="file">. The widget recently underwent a deep redesign: we revised its UI and layouts. I’m Anton, a UX/UI guy with Uploadcare, and I will walk you through our interface decisions and the reasons they were implemented. Also, I will share some experiences, so you don’t make our mistakes when building your thing.
The old way
The previous widget design was good for 2012. It worked well, and the feedback was mostly positive. But everything ends, and we got to the point where that design was getting old. The problem was it became inconsistent due to the growing number of features, and that started to look tatty. We had a good number of poorly linked various screens and layouts for a single widget. Time for a big cleanup.
The first redesign attempts were made in 2015. I wasn’t a part of the team back then. But those who were decided to outsource the design. “As a startup, you’re focused on learning and iterating fast: getting more traction. In a setting like this, outsourcing the UI seems like a good idea,” said Igor, our CEO. “However, it can be hard for an outsourced designer to keep up with your pace of change. Especially, if you are full of ideas on how your interface should work and tend to always add up to the designer’s input,” he added.
In the end, the number of various sketches was excessive and unreasonable, while there were, literally, zero layouts or stylesheets. Another thing was the contract with the outsourced designer was about to end 😕 “Well, we’ve got so much stuff put together as sketches. We could use a frontend dev to lay it all out,” thought our CEO back in the day.
The Frontend
That was when Zarema, our current Senior Frontend Dev, appeared on stage. Uploadcare got self-sufficient and started growing at a fast pace. She was the first engineer to join the growth team. And her very purpose was to make our widget blossom. The senior frontend dev had a great UI background and seemed like a perfect person to handle the widget thing once and for all. Working on something new usually arises many questions. In our case, those were related to both the look and UX of the new widget design. And, communicating with an outsourced designer was a quite a problem. See, it has been months since the design was ready, and that external designer was up to another project. Sure, she did not refuse to support the project after it has undergone our QA, but this workflow did not prove productive.
I was working with another team around the same office area when we first discussed the widget and its designs with the frontend. Our dev was mostly about these three things: consistency across widget screens, responsive layouts, and better tech like BEM and flexbox. I decided to try and draw certain widget screens, and the more I did it, the deeper I was getting interested in actually working on the design together with our frontend. And when I was told the widget was designed to potentially replace tons of different file inputs across the web, I got into it and asked CEO if I could join Uploadcare.
“Folks showed me their design concepts, and I got a hint that such a team of two have already done a better job in certain aspects than the outsourced designer alone,” noticed the executive.
Inventing a better wheel
Alright, the widget team is put together. Let’s get to work. I’m a UX/UI guy, so I’ll cover the interface aspects.
There is a lot of talk in the modern UX community about making your design work for your business. Stuff like marketing and business processes are integral parts of a design today. But, that was the case when instead of digging around user motivations, we switched to understanding the task straight-forward: make a file uploader.
See, when you want to build something that aims to replace worldwide standards, you should first adopt the currently neglected principle of banality. And, then you make it your best friend and start declaring it across your workflow. And, as it turns out, it’s hard to think the Captain Obvious way. I guess this has a lot in common with designing OS GUIs.
The tech-oriented nature of the widget imposed its requirements. Concerning the UI, we were to keep all stuff as minimalistic and uniform as possible: no extra RAM or CPU time could be wasted on my visuals. We kept in mind we were designing a button.
If we combine those technological constraints with the fundamentals of UI design and think of some cool names, here are the criteria we get.
1. Neutrality
Prefer patterns over inventions
That’s about flawlessly embedding your thing in a UI of any popular platform. Uploadcare Widget is a modern thing replacing your native file input. Hence it should have that “default” feel and behavior on different platforms.
2. Polymorphism
Prefer flexibility over a perfect local fit
With just a few lines of code, our users can embed the widget in their page. Same goes for changing how the widget is laid out. And UI should be in line with all kinds of the documented states. The variety of possible states is quite wide; our widget supports custom tabs: kind of a plugin engine. For example, we made a custom tab that allows editing uploaded images. Since there is no way to draw all possible widget states, UI must be adaptive and accept changes without breaking down.
3. Clarity
Prefer simplicity over bells and whistles
With design, clarity is fundamental. It’s important to have it together with Polymorphism. Running on flexibility, we need to double-check every decision branch for clarity to avoid complexity.
In other words, that means if we can’t make a thing universal, we are better off without it. For instance, this has to do with the mobile widget layout, main screen. At first, it just copied the desktop one. It was later on when I came up with a couple of simple rules to handle specific cases.
They talk a lot about design systems now; there even exists a special conference. I’m a part of this flock and always look to bring order in the process of designing things. It simplifies teamwork, reduces bus factor, and syncs designers with coders.
Being a design systems fan, I then translated my criteria to visuals: from basics to layout structures. Here is how.
Colors
No extra meaning, branding or mood. The simplest color scheme for on-screen UI is grayscale and blue. Blue, primarily because we don’t associate it with any of the specific states like an error, warning or success. The color has many other benefits too. I also tweaked some gray shades and reduced their number: the scheme got easier to maintain and gained a better overall contrast.
Fonts
Following the no-extra-resources rule, it’s irrational to waste tens of kilobytes on a button, so custom fonts aren’t an option. Luckily, in 2017, there is a way to be relevant and “default” at once: use system UI fonts. Also, such fonts help slightly shift the UI towards any system thus creating a more “native” feel.
Elements
By design, widget elements lack their own “sound”: their rounding radius is average, proportions have almost no dynamics, line thickness does not stand out. And, of course, a blue button is the most common button in today’s digital world. For icons, I stick with choosing form clarity over styling, you know, like applying an actual blur to a blur icon.
Layout
To reject inventions and authenticity for good also means keeping successfully working solutions. So, the basis of navigation, vertical tabs and button positions, were not changed. However, we did a deep remastering: overall padding and margin rules got simpler: everything is now visually aligned and consistent. The mobile layout was almost completely rebuilt, and the tab bar got a cleaner look and a breakpoint to define when users see full tab names.
When you declare the fundamentals, the rest is mostly about communications between Design and Development: discussions and mutual corrections. In short, teamwork.
Team
You already know I’m in it with our senior frontend dev. Our teamwork stack is simple: Zeplin, Slack, and empathy. I’m not just gone for a couple of weeks and then magically get back with a ready-made thing. It’s an iterative team process.
Our workflow is not overly formalized. Every day, we check each other’s decisions for usability, consistency, and aesthetics.
All the design and development took about three months to get the widget done. It’s not a finish line, tons of work ahead: we plan to revamp the social upload sources workflow. And I know this time it’s going to be easier since we built a solid foundation. We know exactly where and how to move forward.
“Our designer says it took three months to redesign the widget. But I know it took way more than that. The first design efforts together with the lone frontend wander lasted about three times longer. If your plan a redesign of a tech thing, make sure to get a great team first,” added Uploadcare CEO, as he read through the conclusion.
However, that’s a design article, and the final word rests with me here 😎 I’m grateful to the guys that make Uploadcare grow and helped the widget to get its third major update.
But, we wouldn’t build the design without user feedback. It is a major component. Users know how they use your thing while you often guess how they should.
by Anton Nesterov, UX/UI @ Uploadcare. Stay tuned: follow us on Twitter to be the first to get our updates 🚀
