Our simple CMS for web designers, Widgetfinger, recently had a UI design interface overhaul. The workflow and content listed on most pages is effectively the same, but the aesthetic and general layout have been modernized quite a bit.
Before and after of users page:
The editor
This redesign process began with overhauling the editor. The editor is an important part of the application, and it’s what most users are in front of the most when they’re using it day to day (the editor is an in-browser wysiwyg-ish editing tool for clients to edit page content right on the page). We knew that the widgetfinger branding on the editor needed to change, and we knew there was room for improvement on the actual interface as well.
Before and after of editor:
Prototypes for fun and profit
This Widgetfinger editor redesign process started about a month ago, and while it was being redesigned, the same team of people at thoughtbot were simultaneously working on prototyping a new application that we are considering building as a product later on this year. Even though it was a mocking/prototyping process, we took it seriously and wanted to get the most out of the design process as we possibly could. We spent a decent part of each afternoon, for about a week, doing conceptual work on how the new application would look, and design mock work on how it would function — and at the end of the week we had a really solid looking prototype and complete confidence about where the value was, what features were version 1 or wishlist, and even how we would begin to market the product to a subset of its potential users.
Back to the future
Fast forward to early last week — we had completed this very successful prototype process 2-3 weeks ago, but now that was on the backburner and the WF design work was very much the top priority for the design team here. As we started the work to clean up the design, we started seeing some interesting connections between the work we’d done on our maybe-its-just-for-fun prototype and our this-is-important-to-redesign project.
Because of the simplicity and specificity we had held as important in the prototype process, we were able to take the resulting interface and — with surprisingly minimal effort (we completed the bulk of the layout conversion less than 24 hours after we even decided to attempt it) — we were able to implement the rest of the Widgetfinger interface redesign within the span of several days. This task would have otherwise taken weeks and had a ton of pressure about getting a redesign right. In fact, if anyone had even mentioned doing a redesign of the product instead of some small design improvements, we would have decided that it was absolutely not worth it. Because of our commitment to quality on something that Didn’t Really Matter, we were able to re-use that work on something which did — and then we even found time to add support for new features with the time we had left!
No names
During earlier application prototyping processes for ourselves or for clients, we’ve wound up going back and forth on a few different potential names for the application, and often consumed huge amounts of time in the process. This time around, we wanted to avoid this mistake—so now have an internal policy that all new product proposals are just given an alliterative, two-word name (Cyclone Cindy, Local Larry, Merry Munchkin, Rusty Ratchet, etc). This avoids the naming discussion, and aids thinking about the application by guiding conceptual discussions to be about features, not the name.
This wound up working to our advantage while building this application prototype (and as it turns out, this was the first thing we’ve actually prototyped under the new naming regime), because we did most of the design work without considering a specific brand or identity for the end product. We knew we’d change the name and logo anyway, so we didn’t even look at that part of the screen too much. We spent time making sure the fake name and logo looked good enough to not look bad, and that was enough. Removing this element from the picture helped us to really hone in on the interface, and focus on how the product was actually going to be used.
Best efforts
The biggest lesson to pull out of this is that it almost always pays to give something a best effort. Even if something is just a mock, or won’t ever be seen by the client, or isn’t for your real boss — or who knows what the excuse you’re making is — the best way to produce results (intended or not!) is to treat everything like it matters, and to really focus on quality and simplicity at all times.
We sort of tricked ourselves into believing that we were producing a prototype that was going to be put in front of possible investors, customers, partners, etc of a fake business we were starting, and that we really had to prove that it was worth their time and money. In reality, we were presenting it to ourselves for those purposes, but the suspension of disbelief was sort of liberating in how we went about the design process.
