A Designer’s Wishlist, Part II
There’s a useless gap between design and code
So we’re a little closer to Christmas, and for those who remember Part I of this article, it’s still time for me to ask Santa for better ways to design. In fact, December 24th is also my birthday, which gives me a lot more power to be a capricious little prick than you, poor mortals. Not sure if this old bearded man from the north knows a lot about building interactive interfaces, but I’ll still be a child and give it a try anyway.
In Part I, we talked about how animation and interaction should be a lot more present in mainstream design softwares. Some readers told me about awesome projects such as Framer.js, InVision, Pixate, or Marvel App. I’m really thankful, and consider myself an admirer of all these guys that put a lot of thoughts into these issues and produced such quality work for our community. On the other hand, although I salute the performances, I’m rather disappointed about the fact that animation and interaction are not priorities for Bohemian Coding’s Sketch, which has become the flagship tool of UI design. Let’s not even mention Photoshop or Illustrator.
Today, I want to share another frustration of mine that has bugged me for too long, ever since I was a UI designer. I’ve started as a poster maker, or print guy, for I studied in the ink side of graphics. But as soon as I stated myself as available on the market, the odds wanted me hired as a UI designer in a mobile startup. How excited I was when I discovered the interactive side, and especially mobile. Geeks that won’t define themselves as such, a vocabulary that you suspect is made to bullshit newbies and clients, and the fact that it was, and still is, all new, all powerful, with endless possibilities. Everything was different. As well as the ways to handle projects. And I really liked it, because I discovered that my way of thinking was much closer to these people than from the print guys. They have different problematics, and they handle it differently.
Ever since I worked on a mobile project, I couldn’t ignore this bizarre feeling that things aren’t going the way they should
Being rather new to this world, I couldn’t help myself to realize that project management is a little weird on this side, though. Ever since I worked on a mobile project, I couldn’t ignore this bizarre feeling that things aren’t going the way they should. But as a matter of fact, project managers are not to blame. Technical limitations are.
If you are a mobile designer or developer, something should profoundly shock you in the way you are working as a team. In fact, you do things at least twice, and by doing so, the final product is being altered, drifting away from its original concept. Nowadays, creating an app is divided into several steps: wireframing, for ergonomic matters, designing the final version, for aesthetic and experience ends, exporting the assets, for development purposes, and coding, which is a very complex step by itself, but since it’s not my job and I don’t really know jack about it, let’s stay simple and call it one step.
Workflow can be very different from one folk to another. As for me, I can work differently from one project to another as well. But what I like to do, as I design only for iOS at the moment, is using my iOS UI Kit actions for quick prototyping. It is useful in this case, if you work on Photoshop, because it is very fast and accurate. Default iOS elements are created on-the-fly and placed on my mockup with the precision of a machine, so I know I have a solid base to work onto. Depending on how you like to work, UI and wireframe kits suit pretty nicely for this step.
You do things at least twice, and by doing so, the final product is being altered, drifting away from its original concept
Maybe you are convinced that reusing the primitive file is a good time saver and keeps the design fresh. Maybe not. And it’s cool, because the real deal is about the next step. We prototype, we add style, we export and document (sometimes in a poor manner), and then we drop the baby out to the developer, hoping that he can handle the whole front end part for himself. If it’s not perfect — which is always the case, obviously — we sit by his desk and try to explain how we see it, so he can translate the design rules into his own code. When you think about it, it’s silly. It means that the job is done twice, with different point of views. Honestly, I never got to understand that. What the hell? Picture a writer that just finished a novel, and passes his text to a layout and print guy. Now imagine that the latter tries to stick to the original version, but cuts into the sentences or modifies the writing style by trying to type the whole text by hand. You wouldn’t allow that as a writer! So why do you do as a designer? I’m not saying that all devs shamelessly slaughter our designs, but anyone will make mistakes trying to redo a job by hand. And yet, that’s how we roll. And for the record, I’ve grown very fond of these guys, because they have the ability to give life to our creations. How cool is that!?
Anyone will make mistakes trying to redo a job by hand. And yet, that’s how we roll.
I’ve seen developers recreate my designs using Interface Builder for quite some time. When Sketch came up, it immediately reminded me of it. And I figured that, if I get it right, the designer sets color, typographic, compositing and implicit behavior rules, and the developer does (almost) exactly the same on his coding software, while we both end up expressing our needs to about the same interface, yet in different softwares. Provided that you care about it, what would you do if you found a duplicate file on your computer? Unless you have a good reason, you would fix it by deleting one of them. So, what would you do when there’s a duplicate process in your workflow? Get rid of it! Although I’m conscious that Photoshop is too old-ish for that, Sketch seems to be the future for building interfaces. It seems that it speaks the same language than Xcode’s Interface Builder. Man, how sick am I of exporting assets. Tools like Slicy may be life savers for this painful task, but with the evolution of UI design these times, I think that it is time to see a little further, and completely get rid of this step that represents the bridge between designers and developers. Not to mention that the assets we provide are bitmap versions that are heavy, copied in several sizes, even if the original element is a simple vector shape.
With the evolution of UI design these times, I think that it is time to get rid of this step that represents the bridge between designers and developers
I found this cool script by Matt Zanchelli that makes the export from Sketch to Xcode possible. Let’s salute the effort! This is the future. Well done, man! This needs to be integrated into Sketch, but in a casual way for designers to handle. Think of the time it would save for developers, and the quality it would provide for the final app. When you manually transcript words from a source, chances are you will scratch the result, but when you copy/paste automatically, there is no room for mistakes.
Even people that are designer and developer at the same time are forced to build an interface on a design software, and export assets for coding the front end part, although they have both skills. I strongly believe that designers and developers will understand each other better and better for the years to come, and now would be a great time to blow the barriers that divide them. It would seem far more natural, for they work together on the same product.
Originally published at jeremypaul.me.
