I've encountered this as well. I am a proponent of just using low fidelity shapes for mocks instead of high fidelity renderings of what it should actually look like.

If you put enough work into the design system, and implemented it well for use in code, all you should NEED is a low fidelity shape telling you where to put existing components, and how to string them together. Everyone already knows what a modal looks like, behaves like, etc. they don't need it designed for them every time it comes up. That just wastes everyone's time.

I second this. The most efficient frontier in communication between engineers and designers is about striving for simplicity by stripping visualization to stick figure like representation.

Exactly!

Design is about how it works. That’s more important than how it looks. Low fidelity focuses designers on the app workflow, lets more of the team get involved in design, promotes UI component reuse, and avoids confusing managers about what’s actually finished.

A few days ago I was searching for a cloud native, low fidelity mock up tool, and liked https://gomockingbird.com/

I have no affiliation with them.

I'll check it out, thanks for sharing! Looks promising from one one minute scan.

In a similar vein (also have zero affiliation) I discovered https://whimsical.com today, which also has a few other promising looking tools like flow diagrams, post-its etc.

Marvel App is a nice one. Sketch, photograph, wire photos together into a workflow mockup.

App Cooker on iPad is really nice too, though no longer maintained. It exports the storyboard of all the UI screens connected by transition arrows.

This is true.

It makes it really easy to first building a design system (like Bootstrap, Material Designs, Antd,etc). Which are a bunch of components, from basics like headers, list, to modal, message, cards, etc.

Then just place those components into the wireframe.

If anything need to update, it will be updated from the design system, then sync to the project

We use a shared Figma component library, which gets implemented as a shared Storybook library for front end developers.

In theory, this means the designers are designing with components which are already represented in code, and as long as they update the library with any new or modified components, it should be straightforward: a change in the Figma library represents a change that needs to be reflected in Storybook.

But that's just the theory. In reality, designers often need to work quickly, and the idea of design debt is just as real as tech debt. Indeed, it's probably more of a problem, since there's no such thing as pull requests or automated regression testing for design, so it's harder to spot problems.

Figma already has a way to at least partially address this issue: they provide analytics that show you which of your components are getting detached, as well as a lot of other useful stuff. Unfortunately, the tier that allows this feature costs about 4x as much as the normal pay tier most people use.

What impact is Storybook.js having on your team?

I’ve recently started using it with my team and the impact has been positive. Component sandboxing seems to encourage developers to encapsulate CSS within web components. Sandboxing also seems to encourage thinking about web component APIs and designing them for reuse.

How well is Storybook.js catching on as an emerging standard in UI development?

We like Storybook a lot. It's made communication between Design and FE a lot smoother. I wouldn't say it clears up all ambiguity, or eliminates all redundancy, but it's a noticeable improvement over relying on institutional knowledge alone!

When I joined about six months ago, the team was already using it, and keeping it up to date had become ingrained in the culture. I had nothing to do with it, so I can say it's been a good decision.

I have no idea if it's catching on in the wider world! Anecdotally, of the five places I interviewed at last year, two of them claimed to be using it.

There actually is proper version control for design! Abstract being the most fully featured, although only Sketch was supported the last time I checked. But yeah, in my case design debt is usually mainly born during exploration or when designs have a tight deadline and I don't take the time to organise my files and creating reusable components. I often end up with duplicates that I have to manually fix from there on out.

That’s not figma’s fault, that’s a team communication and workflow issue. We have that at work too and the solution is to communicate. Have a big red box with text saying the modal is not ready, or simply don’t have a modal until it’s ready. Better stick, create placeholder components and use those. Replace when ready.

Agreed. In my company, your responsibility as a developer is to implement the design as shown on figma, pixel perfect. If something is incorrect on the design, someone will usually have noticed it and fixed it before I get the chance, because there are 4 sets of eyes on it (CTO, PM, Designers, Developer)

It depends on what is being built. Pixel perfect on the first iteration is not a great idea. Because on the first iteration we are usually trying to figure out “does this even solve the problem” and show that to users. After many iterations you have a rough plan. Then you build a quirky mock with existing components you have. Then you let users play with it and find existing rough edges and smooth them out.

Then you build a much nicer version (perhaps pixel perfect) and then have a lot of users play with it, and then your analytics funnels tell you where the bottlenecks are. So you make even more iterations until you make something that solves the problem in a delightful manner and users are going bonkers about it.

The TLDR is, there is no point getting pixel perfect in the first iteration. Good software requires tons of iterations and the entire pm-design-eng-user workflow should be optimized for faster iterations and learning.

A good design system + mockups get your that.

I hope this is sarcasm.

Seems pretty reasonable to me.

If it’s a rough wireframe it can be just that, rough.

If it’s a pixel perfect mockup then it’s a contract for final product IMO.

Of course whether there are that many sets of eyes on it depends how big a co you’re working for!

Pixel perfect? So if a css box-shadow is 11px instead of 12px someone will notice? ...I don't think so

Maybe if the pixel perfect design is diff'd against the final product...

Here's the thing: higher ups, more often than not, have no imagination. If your mock-up is not explicit and realistic, you'll get complaints and worries that it's not polished or that not a lot of work went into it.

Yeah, this is very real to me. Even after explaining what a wireframe is, I’ve had execs very confused why I’m proposing the UI look like black lines on white background. And not just just execs - I’ve had devs try to implement wireframes as-is as well!

Higher ups have imagination... its just not used the way you are thinking...

Their imagination is running wild that the mockup being used in the presentation to them means its an unknown time until its ready to ship..

They are imagining that is past whatever deadline they have in mind for it lol

You're mixing up wireframes and mockups. Wireframes should be used for exploration of ideas and generally laying down different ideas in their simplest form and mockups (high fidelity, in this case) would then be built based on the existing components or displays new features and views.

If the modal in your case doesn't support a feature, it would be caught during the wireframing, before anyone has invested too heavily into any particular design.

Also, if the mockup resembled the actual UI but still differs ever so slightly, it's a sign of an inexperienced designer. Either they haven't properly made the actual functionality clear and the visuals are confusing (should it differ from the current features or not) OR the team is in need of a design system which would be used as a basis for all design visualisations and implementations.

Agreed. And I think there's a certain personality of people who are employed in UX that lean more towards the design than the conceptual side that often get lost in the weeds with this stuff, too, and you'll end up with a series of mocks that look great, smell great, and gosh darn it people like them... but are missing all error screens, corner cases, more complicated states, and leave developers in the dark on the bigger picture.

Back when I was doing iOS development for a bit I had one designer forcing us to go through every single screen and manually override the default vertical font spacing and kerning settings away from the (company wide) framework we were using -- a change that was fairly trivial on Android but a pain on our iOS stack -- and this ended up taking hours that could have been spent on functionality. And made the app harder to maintain, on top of that. But this was really important to this person that the font spacing match their preference, and also be identical to Android's.

I miss simple wire frames. Some of the more productive projects I was on when doing front end work were done like this: product manager / designer gives a rough idea of layout and flow; developer works with them to throw together the simple flow as just raw HTML, really. Iterate, change, modify based on what does or doesn't work. Then the lipstick came later, once that's all nailed down. Less time wasted.

For my own sanity I've avoided front end work at all now, and have been doing systems level work instead.

I think the reality is that most people who originally got into design did so not because they were passionate about user experience, but because they had some artistic sensibility, and design was a field that would let them utilise that sensitivity for aesthetics while also paying them a salary.

Over the past five years or so, the landscape has changed considerably, and many designers have been forced to make a decision to either head down a more UX-oriented path or do something else entirely. The result of this is that we now have a lot of UX designers who never really wanted to do UX, but were forced to adapt and take on a new role due to a changing industry.

Of course it’s leaky, but obviously the cases where engineers built the right thing on the first try because of the clear design are harder to measure.

Also, look! Engineers are talking to designers.

> obviously the cases where engineers built the right thing on the first try because of the clear design are harder to measure.

That's a fair comment.

> Also, look! Engineers are talking to designers.

I think most good teams have had engineers talking to designers since well before Figma :)

I think it helps enormously if the designer responsible for the designs understands about the tech used in building it. I don't think that every UX designer needs to be a full stack developer as well, but when you have the ability to actually talk about the tech, you can also translate the design into something that non-design folks might understand.

I often ended up sitting next to one of the developers, working along-side with him, helping him on the technical issues (reading Stackoverflow and github issues on various repos for example) while he helped me with the designs by challenging and testing as we were wireframing ideas. Kinda like aöpair programming, but for designers and less siloed.

Ah yep of course, I’m just pointing out that those kinds of back-and-forths, Figma derived or not, are a sign of a healthy org. A lack of grumbling around miscommunication often means that no communication is happening, not that it’s going swimmingly.

You're being downvoted, but you're spot on. I can't quite put my finger on when the term "software developer" when out of vogue, but I suspect it has to do with titles at FAANG companies more than anything.

At Google in Canada we are no longer supposed to refer to ourselves externally as software engineers, for legal reasons. We're software developers again. Which is how I have always thought of myself.

Well, back in the 90s I called myself a "programmer." I miss that, too.

I guess there are levels. Computer engineering is a proper science, much much more deep and broad than mocking up a web page. And people study the science for years, the same as civil or aerospace engineers do, and get a label for that, called 'engineer'.

Same with a doctor. You study for that, get the label. You cannot/should call yourself a doctor if you just read some Wikipedia articles and listen to grandma tips and go applying band-aids and aspirins.

> Well, back in the 90s I called myself a "programmer." I miss that, too.

Oh man, so true. I miss it so much. Developer is such a vague term.. but in my little heart I still consider myself a programmer.

Computer engineering is a science that shares common habilites and tasks with those your grandfather had. Maybe a website is more similar to build a garage than a bridge. And maybe building an operative system is like building a skyscraper...

"a person trained and skilled in the design, construction, and use of engines or machines.." - [https://www.dictionary.com/browse/engineer]

I guess what it comes down to, is software a machine/engine? Also, the person who does the "slicing up a design, authoring markup and CSS, and sprinkling in a JS plugin or two" is or should be the designer, not the developer.

Building a bridge isn’t anywhere near as complex as maintaining a javascript build pipeline.

If this is humor it really got me.

Because software development in the real world is hard. Hard computer science is hard. We're still in the infancy of the profession and have a long ways to go. I could honestly see it comparable to bridge building or rocket science.

Then reading again and seeing "javascript build pipeline" just made me LOL. Cause that's rocket science too.

With the latest SpaceX, JS is literally being deployed into space. So, rocket science, literally.

had a 200 screen mockup in invision handed to me. it was obvious that a few different teams at the design agency had worked on it:

screens 1-25 had a certain nav bar

26-39 had the same nav bar, but everything a few pixels off with a slightly smaller font in off-white, vs white.

screens 40-70 alternated between the first to nav bars, and introduced pull down select boxes with multiple checkboxes in them. the multiple checkboxes represented - in some cases mutually exclusive combinations of things which contrasted with other nav options.

... and so on. Things had to look pixel-perfect - "look, it's a design agency, they put a lot of work in to thinking about how this is supposed to look and work". So.. you'd make the screens exactly the same ('just export all the CSS for each page', etc). But then, when using the app in development, if you went between various screens, and saw the discrepancies - font sizes changes in nav, for example - that caused more negative feedback - "this is broken!".

I tried to demonstrate the design screens were the problem themselves by just paginating between the invision slides - you could see the font sizes jump/change immediately. "now you're just being negative".

I didn't last very long on that project...

It's not just Figma; a project that I'm on has been having basically the same challenges with Sketch/Sympli, and Axure before that. Breaking it into two separate "wireframe" and "mockup" steps has helped, but folks are still rushing to the "mockup" step too soon IMO; lots of things that could have been caught in the wireframe stage are still having to be corrected in the mockup stage instead, pretty much as described by parent. It's a fairly recent change for us, though, so I am hoping that things will get better with practice.

Personally, I'd rather just implement the wireframe (or something like it) and try to iron out the interaction wrinkles there where it's much easier to update the design and you don't have to worry about fonts and spacing nearly as much; once the interaction implementation is nailed down, then I think it's a better time to move on to the mockup. Hopefully we'll get an opportunity to try this at some point, but it was enough of a struggle to do a separate wireframe at all that I'm guessing it'll take awhile ;-)

Yea, we've had the same problem. I've started to ask our designer just show the thing that should be changed, with 0 other context.

An idea for Figma to mitigate this problem: make a browser extension that can export pages to figma documents. That would make it much easier to have up-to-date designs when doing web development.

This is a failure mode I've seen before in other distributed collaboration situations: there is a giant artifact that either clueless participants or homeless tools force everyone to carefully reexamine every time a change is made. If Figma really were all that I guess it would accommodate the futuristic technology called "diffs". Even if your excellent extension idea weren't available, ISTM designers should just maintain a current representation of production in Figma if only to themselves have some idea what's going on.

Possible solution to that problem:

Have a plugin which could turn the unfinished modal for example into a wireframe look & feel and then when you have the right icon, turn it off again.

I remember back in the days Expression Blend had some functionality to apply sketchy lines style (based on Bill Buxton's book - Sketching User Experiences).

Also, the prototyping functionality is still rather basic. Axure is much more powerful and ideal for the early sketching and testing phase.

But I'm sure Figma will have more sophisticated prototyping features in the future.

What does RP exactly do that you can't do in Figma? With the right plugins and component libraries, I dare say that Figma is definitely more powerful than Axure's offering.

I use Axure to prototype enterprise apps, i.e. lots of forms and data grids.

Last time I checked, Figma didn’t support interactive form elements or prototyping conditional branching based on what you type in a form field.

Being able to prototype business logic without having to get developers having to develop something, saves a lot time at early stages when you explore new features with business users and you can also iterate faster and it’s better for user testing as well, as it’s more than just clickable hotmapped images.

I know you could achieve the same with Framer, since you get access to the code, so that’s useful for designers who can code.

Axure is great for designers or product folks who can’t code.

Is the above possible in Figma now?

I tried to switch to Adobe XD, but sooner or later you can't do some sort of thing that is simple in Axure and you are stuck. Simple example. You have a settings page like this:

Setting 1 name [toggle]

Setting 2 name [toggle]

Setting 3 name [toggle]

You want to turn any toggle on and panel with subsettings should appear underneath clicked setting name, shifting down all other settings below. In Axure it is just a checkmark "push widgets below".

Are there powerful prototyping plugins for Figma? I'd love it if the answer is yes.

Axure is horrible for wireframing and a non-starter for visual design, but it has the most powerful prototyping features I've seen by a long shot. Framer is straight up writing React code, so I don't count that as an option for the vast majority of designers.

Why do you think Axure is horrible for wireframing?

I guess that isn't fair. It doesn't have all the layout assistance and plugins that Sketch and Figma have. It is perfectly fine as a wireframing tool.

Ha! If you think Figma is bad for, check out Axure at some point.

I got sucked into using Axure a few years ago and had a blast making interactive, data driven mockups that utilized custom JavaScript to build components.

It was awesome to get some key concepts across but then one day I realized I spent more time fighting the mockup software than if I had just coded it up.

Oops!

Our designers have solved this by making anything that’s still in the mock up phase completely black/white.

Anything that’s actually ready uses the primary/actual colors. It’s actually pretty great apart from 80% of the design being grey at any point in time.

Eh, that line of questioning should be handled by designers at the very beginning or even before sharing designs and can be addressed more generally for all of their designs before sharing any specific one.

Been there, done that. Usually is because you need stronger design/front-end glue (front-end developers with higher than average design skills).

I have experienced this same situation in Zeplin and Invision, so I suppose this is not just Figma.

Seriously that interaction gives ma a headache. Hand-drawn mockups on papers is where I'm at baby. Know HTML, CSS and SVG as the back of your hand. Code 10 modals and dropdowns and you won't even thing about it anymore.

Sounds like a person problem not a tool problem.