What are some tips for a designer to use Interface Builder effectively? [closed]

Question

I work at an iOS app startup. We have 3 engineers (including myself, the founder), and a part-time UX designer. I'm trying to get the designer to use Interface Builder, and he complains strongly saying it's not a good tool for designers.

I agree and empathise, but I've tried to point out that if he wastes an hour more wrestling with IB, but engineering saves two hours, it's time saved for the team as a whole. It's the team's productivity that matters, not that of any particular individual.

The problem I'm trying to avoid is that design gives a PDF, or some other format that can't be directly used in an iOS app. This requires reimplementation, which is a massive waste of time. In a previous job, it took my team two months to implement what was in a 80-page PDF file, after UX took two months to design it.

Re-implementation also often results in lower fidelity. My designer complains about this exact same issue in his other job, saying that engineers implement it only with 60% fidelity, but he's unable to see the link with the tooling issue. This degenerates into a blame game where designers say engineers are not skilled, or have insufficient attention to detail, and engineers say that designers don't understand the constraints of the platform they're designing for or they timelines there are asked to keep to. I've been in multiple of these arguments and have no desire to recreate them again in my startup.

Getting the designer to use IB makes him aware of what's easy to implement and what's not, so that he takes that into account when designing.

Basecamp, for example, says that they skip Photoshop for UI design and go straight to HTML/CSS. I believe that's the same issue I pointed out, namely that of designers using different tools from what engineers have to use. HTML/CSS for Basecamp translates into Interface Builder for us, since we're an iOS app rather than a web app.

Have you as a designer ever used IB? What are some tips for designers to make effective use of IB? What workflow works, what doesn't work? Any advice is greatly appreciated.

Answer 1

From a designer's perspective, Interface Builder wasn't designed. At all. It is undesign. And it's utterly impenetrable unless you know what it's trying to abstract from.

From a coder's point of view, Interface Builder looks like it might be making design possible inside Xcode and be somewhat similar to design apps. It's not.

Without a good understanding of the operational paradigms and processes of using UIKit, UIViews and all their little bits and pieces, Interface Builder is a complete disconnect from the imagined realities of UI and UX design. These fields of design endeavour start in and deal in ideals, not the problems and limitations of the frameworks they'll be made within.

This might seem strange, but it would be far more effective to find ways to motivate the designer to read up on, and learn about, UIKit, UIViews and their components.

The problem is that I've never found a good entry point to UIKit and UIViews from the perspective of anything other than code. Whilst better than Interface Builder (which presumes understanding of code and some understanding of the frameworks) designers are code resistant, for very good reasons.

So you might have to personally discuss with him, in an hour a day settings, how UIKit and UIViews actually work, with a whiteboard.

Then, much better than using Interface Builder, he will eventually be able to express his desires for responsiveness in the exact terms and technologies that the coders actually use.

Even grander, he'll begin to conceive of ways to exploit the way UIKit operates and is, understand how things work within it, and design expressly to these capabilities and paradigms in ways he can express in these elements and components and their relationships.

Answer 2

I don't have experience with interface builder. But I've done C++ based desktop app with QT Widgets which has a similar concept and implemented my UI using code and I also implemented some websites. I completely disagree with Basecamp. When you design you are basically using a divergent thinking process: you are discovering, thinking and creating many ideas/ solutions for problems on the fly. This process is already hard when you are not worried about code (it consumes willpower and memory from your brain). Good design is about "removing stuff" and I change things several times. I don't design only the "skin" but the flow of steps to complete actions and I think that code is too slow to create that many iterations and ideas. Sometimes I after I place 3 elements in my canvas, I find a way to kill them with one or even the entire page, but if that was handed to the dev that would make him/her frustrated because they just got that built. I'm also a believer that tools puts constraints in your process when you code you are worried about making it work so you might avoid naturally certain solutions (because it would cost too much time), who needs another bootstrap implementation? But what if that new idea or interaction model would make a huge difference for your app? Think about the Tinder Swipe. When I do the design I forget about code and I focus on the best solution for the user, which could be even beyond material or iOS design guidelines. If you check Fantasy's work they have better interaction models for some apps than current trends and those guidelines I just mentioned. https://dribbble.com/shots/3030037-Seat-flow-for-Tinder-Travel-concept-by-fantasy

Now, I do think that is important for the designer to implement and learn front-end programming to do better design. Going back to the Tinder example, the guy who created that (Jonathan Badeen) has a background in both front-end dev and design. I think that code really helps you design better (if you are interested).

Now, potential solutions to your problems:

1-To create an incentive for designers to code you need to find a specific type of designer. Some designers are artistically inclined, in game design, they are called artists. These folks might better take other paths to improve such as doing marketing design, illustration, branding, or moving into animation, motion graphics and videos. Another type of designer is more logical oriented like me, I'm interested in the big picture of the system, and how the logic of the front-end works in relationship with the user, what kind of widgets are better for certain problems but still fascinated about the visual aspect. This is the type that would be interested or someone who is already in front-end to willing to learn design. I think that this is more about personality than anything, just like you won't convince a developer to do repetitive accounting work even if you pay him more.

2-if you believe that your guy is more designer than an artist, he needs time to focus on the visual aspect and not do the two at the same time. If your process is too rushed it will be too much stress to switch in between the two disciplines. I might be wrong but I think that the process of programming occurs on another part of the brain, so when I code I need to focus just on that and I don't want to open photoshop, and the reverse also occurs. So allow your designer to have time to finish his screens first.

3-Pay him better. If you want a designer to perform other duties such as managing people or coding, don't expect him to do developer's job but making half of the salary.

4- Stop using photoshop. I've used photoshop for 15 years and so far it's my favorite app of all time, but it's not the current best tool for UI work. It was developed to be a photo editing tool but it became too bloated. If you are MacBased use Sketch if you are Windows based use Adobe XD. I recently switched to Adobe XD and my workflow is 10x faster. It's vector based, it removes the need to use layers, it's easier and faster to use and way faster to export, not mentioning that you can connect the screens and make clickable prototypes. Adobe XD can export in different PPI's and it has also a developer's hand-off add-on: https://www.youtube.com/watch?v=Jdp8A4Vmt4g