As product designers, we navigate complexity for a living.
But as I’ve progressed in my career, and as I’ve worked on bigger teams and on more complex projects, I’ve realized that there is a lot of pain and lost productivity on a really simple, ugly, boring process problem: how we manage assets.
The best, most organized designer fails at this often. It takes us years to develop a system, that system is constantly changing, and the moment our career evolves from “design team of one” to a real design team, that system goes out the window.
Even when you are a design team of one, there are best practices that we often overlook in the interest of speed, and the best tools are the ones that encourage high-quality results. An example of this is forgetting or skipping alternate states when designing views. This is a disaster in production, but we all do it. Having a dev yelling at you for completely forgetting to design the error state of a search view is not how you build efficient, trust-based teams.
I’d like to share with you a product idea, and I encourage discussion, dissent, and reinterpretation. This idea is at the highly-refined sketch phase, so criticism won’t sting too hard. I’m proposing this as a real solution to a very real problem.
UI/FS
My proposal is for building a GUI that replaces the macOS Finder for the purpose of designing and developing software. The (placeholder) name is a bit misleading—this would not be a replacement to the file system HFS+ or the upcoming APFS. It would instead be a scaffolding build atop the Finder (and, importantly, backward compatible with it) that accomplishes the following:
- It must be directory agnostic. Companies must have the flexibility of having their teams save files to a local directory, to a cloud service like Dropbox Business, or to a company owned server. Built-in VPN would be a nice touch.
- It must take a state-and-interaction oriented approach to organization.
- It must be tool agnostic, with initial support for Photoshop and Sketch.
- It must support versioning.
Design for the Problem You Have
Over the years, I’ve developed an arcane, methodical, and downright embarrassing system for managing my designs: I’ve basically hacked Photoshop into a file system. Let me show you what I mean.
The above example is from work I did on an early version of Vidme’s iOS app. What you see is essentially a 10k+ pixel squared PS file (though lately, I’ve had the same problem with Sketch assets), with a whole bunch of linked layers to files elsewhere in my file system.
Some interesting notes:
- Rather than hunting through my Finder, every morning I’d just fire up this one file, and double click on the layer of the view I wanted to work on. PS would then launch that file, I’d save my work, and when I returned to the “scaffolding” file, it would show an updated preview.
- When Adobe introduced linked layers versus embedded smart objects, my scaffolding files decreased from multiple gigabytes per project to tens of megabytes.
- I would create ad-hoc flow diagrams using separate layers within the the scaffolding file.
- I would build these at the wireframe phase. Then, when moving on to visual design, I would have a bird’s-eye view of exactly what regions of the app still needed to be completed.
There are problems with this approach, though. It does not easily or clearly show alternate states. Linked layers in PS are a nightmare with teams of more than one person. It never supported Sketch.
A State-and-Interaction Approach to Asset Management
UI/FS would start with a quick setup flow.
You would tell the app something like: I’m starting a new project, here is the directory where I want it stored (so the app can check if a structure already exists and if so, import it), its name and version number (e.g. Instagram version 8.0), the platform it’s designed for (e.g. iOS 9+, iPhone only), a target resolution (iPhone 7), and the software I want to use (Sketch).
What happens with all that information? Well, in the scenario above, the app would securely connect the company’s server, and create a directory called Instagram/iOS/iPhone/8_0_0/ with a file in it: RootView.sketch.
Within that Sketch file, would be three Pages (each corresponding to the device sizes supported by the version of the OS you selected, in this case a Page for the iPhones 5/5S, 6/6S/7, and 6 Plus/6S Plus/7 Plus). The default Page would be that of your target resolution device (iPhone 7), and in that Page would be five empty artboards (named appropriately), one for each of the states you need to be designing for: Ideal, Error, Partial, Loading, and Empty.
To go even further, stock UI elements like the iOS Status Bar could be automatically generated for every artboard.
When going back to UI/FS, you’d see a live preview of the view you just designed, a collapsed stack of designs for each state, and the option to make a new view. Behind the scenes, a new Sketch file has been created in a nice, consistent way on the company’s server.
Clicking on the stack (with the Ideal State on top) could “explode” out the stack to show all five states to give you an overview of where the project’s punchlist stands.
Back to the Interface
So let’s say you’ve designed your root view. Let’s switch examples and say you’ve designed Instagram’s root view: a stream of photos. In it, you’ve designed a classic 5-item UITabBar. The next thing your manager assigns is the Search View.
In UI/FS, you could go about this in two ways: you could create a new isolated view, or you can make a connection between the original view and the new view.
You could Option+Click roughly where the search tab is in the preview window, and drag over to the “Create New View” UI element. In this flow, we already know the name and version number (Instagram version 8), platform (Android API level 19+), target resolution (Google Pixel), and software (Photoshop). All I need to do is give the new view a name. I go for the obvious: Search.
In this scenario, we’d create a directory called Instagram/Version_8/ with a file in it: SearchView.psd, and automatically open it in Photoshop. It would have the artboards for the five states we’re designing for. But now when I’m finished designing, and I return to UI/FS, I’d have the beginnings of not only a complex file structure, but also a flow diagram and spec.
In the native file system, you’d have something like this:
What Could We Do with All This?
A lot of things. Imagine being able to easily version your designs. Or to package them up and archive them? On bigger teams, what if Product and UX could work on the entire structure of the empty scaffolding together, and export it as a sitemap? What if UX could populate the empty scaffolding with wireframes, and then hand them off to UI?
What if you never had to remember where you saved a certain version of a view, or whether you designed an empty state? What if artifact creation and communication to Product and Engineering, from sitemap to wireframe to visual design, could be automated?
What if you never forgot to upload a version of a design to your company’s servers? Or if your teammates could check out versions of your apps, or even sections within the same app?
If something like this exists, I don’t mind having written all this, just someone show it to me. I’ll use it every day. But I haven’t seen anything like this. UI/FS is a cross between the macOS Finder, OmniGraffle, Git, Folio, and Client Folder Maker.
I’d love your feedback, thoughts, questions, riffs, etc. This is all just a concept, and I strongly believe in sharing your work, documenting your thought process, and collaborating to improve.
I’m on Twitter if you want to @ reply me to discuss further. I’m also on Dribbble, where I’ll be posting random snapshots of the design work for UI/FS.
Nick Dazé is a Product Designer with 10 years of experience building beautiful, usable digital products for humans. In addition to Information Architecture, User Experience design, User Interface design, and Interaction design; he has experience in managing creative teams, product management, leading scrums, art direction, presentation, public speaking, writing, and more.
He also wrote this children’s book, cares deeply about science, technology, and the environment, and dreams of meeting Animal from the Muppets someday.
