Wireframes miss the plot on nearly every perceived benefit. Heres how to stop wasting your time and produce better designsfaster.Wireframing definitely doesnt double the amount of work for little perceived benefit and this caption certainly isnt being sarcastic.Wireframing has existed since the beginning of UX, and on the surface, designers assume it is a critical part of the process. Everyone in UX does it and insists its critical, so it must beright?But as time has passed, Ive seen more and more justification piled on top of wireframes, to the point where UX folk insist its an abdication of your responsibility if you skip the step. If you dont do wireframes, then you must be a bad designer, and you should feel bad! Or at least thats what people on Linkedin tellme.While specific benefits can come from wireframing, we must ask ourselves if the amount of effort invested is worth those benefits and if those benefits can be gained from othermethods.I used to be a huge proponent of wireframing. Still, as someone who converted to product design from UX and has never looked back, the justifications for wireframes are mostly smoke and mirrors, with nobody looking behind the curtain and asking why were doing something performative and wasteful.I swear to heaven, if I ever have a PM or BA tell me to update wireframes to match a visual design again, I will throw them out a metaphorical window.What wireframes originally were goodforThe world where wireframes came about is critical in understanding why they exist. At the time, design disciplines were still nascent, and the tooling for our craft needed to be improved. Even when I started in the mid-2000s, you were lucky to get access to Visiohell, I literally started in Microsoft Paint!This meant that the only place to really design an interface was in tools *not* intended for the taskphoto editing tools like Photoshop or publishing tools like InDesign, but change management was a total nightmare. Need to update a navigation across 100 views? Buckle up and get some coffee, its going to be a longnight.Because of this, an intermediate step where an interface could have the basics all figured out was needed. The layout would be approximate, typography abstract, and content FPO, and it needed to be cheaper and easier to make changes. Wed worry less about the specifics and focus more on the information architecture and interactions.And thus wireframes willed themselves into existence.What people claim Wireframes are goodforOver time, the UX discipline has added more and more justifications for why wireframes are an essential step in the process. This happened primarily because stakeholders and purse-holders didnt understand why so much time needed to be invested in some shitty greyscale impression of an interface, and in their defense its perfectly understandable. Wireframes *were* important because we still didnt have better tools to handle the things that we needed to solve iteratively:Hierarchy of content and features.Information architecture, verbiage, and copy definition.Process and interaction flow/sequences.Rapidly test new ideas and validate them withusers.Keeps stakeholders from focusing on visuals at the expense of other UX considerations.Photo by Jason Goodman onUnsplashWeve made wireframes synonymous with low-fidelity, but all they are is a low-fidelity option.But then more toxic reasons started to bubble upthat visual design was merely aesthetics, and making anything that looks like a final design would do nothing more than confuse stakeholders and users, and would take away from the vital work of defining interactions, content, and IA. A myth around back-end engineers being incapable of understanding a final design and can only comprehend wireframes emerged. I have even heard UX designers claim that users and stakeholders dont understand visual design and should only see wireframes.For what its worth, I have only seen users need clarification on wireframes, never by visual design. As for stakeholders, UXers could learn how to speak to them without saying, Ignore the layout/colors and just focus on the content.We dont do pretty! UX designers would proclaim! I do the real interface work, not the foo-fooUI.Why wireframes dont savetimeFast forward to the modern daythe times of using Photoshop for visual design have long since gone, and UX & product design has exploded in terms of growth. We have products and services up the wazoo and more interface design tools that I can count on. Figma, the behemoth nobody likes anymore, is worth a few billionbucks.This means that the tools we use to wireframe are *the exact tools we visually design with.* It is no different in terms of speed to select Arial as the typeface as it is to select the branded one. Selecting a brand color for interactive patterns is no faster or slower as it is the default blue. You are just as fast at laying out a greyscale option as you are a detailedone.And we have yet to mention design systemsthe advantage that wireframes had of deferring visual design choices is obliterated if your company has already invested millions into a design system that has already thought of all that for you. There is zero difference in using a wireframe UI kit and just using your existing design system. None. Stop wastingtime.Serhii Khyzniak, Wireframes vs Visual Design, is a great example of how the two deliverables have crept closer and closer to oneanother.Dirty Secret: UX is never final, even if youve moved into visualdesignTheres this myth that wireframes will get signoff by stakeholders, and only then well focus on visual design and aesthetic choices. But ask yourself thiswhen was the last time an interaction, content block, or feature set wasnt changed or modified during the visual design phase? Every project that I have done UX on with a distinct visual design phase ALWAYS had modifications to the work I had already done. I swear to heaven, if I ever have a PM or BA tell me to update wireframes to match a visual design again, I will throw them out a metaphorical window.Do you like low fidelity because it makes things easier for people to understand and give input on? Or is the truth that it makes things _harder_ for others to understand and that we _like_ that because it allows us to lord our expertise over others and avoid criticism? If a stakeholder isnt interested in commenting on the IA and cares more about other things closer to their expertise, then why are you trying to fight that?Sean Dexter, Wireframes are becoming less relevant, and thats a goodthingSo, we dont save time by wireframing anymore. However, we still need to focus on lower-level decisions before worrying about the presentation layer of an application (i.e., visual design, what I call the interactive design for your eyes). Weve made wireframes synonymous with low-fidelity, but all they are is a low-fidelity option.Fidelity is a spectrum, not a deliverableWe need to get it out of our heads that there is this binary in fidelity, and instead, we should think about fidelity as something that increases until the design goes into the backlog. Fidelity isnt a distinct step or an artifact you produce, but a constantly updated prioritization of what you need to work onnext.Dont have an image for a masthead? Sure, greyblock it. But maybe you should instead go and find an image until you can find a better one. Designing with placeholder content is never a good idea, even if that content is going to be iteratedon.So why do wireframes stillpersist?For many designers, its simply how to do design a UX interface. In the book, Wireframing is For Everyone, theres something telling:Wireframing is a language for communicating user interface ideas which helps developers, designers, product managers, and stakeholders think about and understand the big picture structure of a website or app without being distracted by the detailsAngeles, Barnard, & Carlson, Wireframing is For EveryoneWhy do wireframes endure? Partially in part because they retain the appearance of something technical and precise. They have the air of a blueprint or technical specification, ruthless in their disdain for anything but the most critical of elements.But given how much a design can change from a wireframe to a final design ready for production, that precision is imaginary.Photo by Jason Goodman onUnsplashWireframes are just shitty visual design because visual design is intrinsic, not optional.Heres the problemwireframes, whether UX designers want to pretend otherwise or not, are still a visual design. You are still designing an interface with visual language, and youre just punting on decisions still critical to the experience.You are still choosing typographical styling, just a wireframe one.You are still designing the layout, just not with realistic consideration.You are still blocking out elements in a concrete fashion, despite insisting a wireframe canchange.You are still choosing colors, even if 80% of them are grey and 20% of them are the wireframe blue.Many UX designers still light up like a Christmas tree if a visual designer moves an element. If wireframes were just about interactions and content, why are we getting in a tizzy if they move a textlink?Visual design is not avoidable or optionalit is as critical to usability, learnability, and cognitive load as any interaction or IA choice you make. And how do I knowthis?Fidelity isnt a distinct step or an artifact you produce, but a constantly updated prioritization of what you need to work onnext.Because wireframes are still a visual design, just a lazy one. And that means double thework.(I have an article on why visual design should be distinguished from aesthetic design, but thatscoming.)Do these Lofi activities instead of wireframingBy abstracting low fidelity away from wireframing, I have become 10x more productive as a designer. I have fed a backlog developed by 12+ engineers with months of roadmap by making low fidelity lower effort, but faster in defining my interface needs.With these options, you are focusing *exclusively* on the things we find essential about wireframes without using visuals to represent them. The speed savings are significant, and the work quality ishigher.Here are some things to consider doing instead of wireframing:UX State OutlinesThis is one of the most rudimentary, and I still use it regularly when I need to move fast. What are the needs of the interface state I am designing, and what is their priority?I then put all of that into a basic outline. I move things around. I delete things. I can also quickly use them to link a flow together without worrying about designing a dropdown or abutton.These are crazy fast to generate and iterate on, and Im not worried about what interface particulars.Grey BlockingSometimes, I need to get a WAG (wild-ass guess) on how much space I can / should allocate to patterns. But instead of wireframing, I greyblock.Grey blocking is nothing more than roughly out a layout with grey blocks. Think of everything you put into it as FPOits just there to give you a feel for how much space might beneeded.I often use these with a state outline if I really need to figure out if I can single-state a feature or if it needs to be designed across multiplestates.Think of grey blocking as a designers WAG (Wild AssGuess)Design systemI mentioned this before, but why cant you wireframe with a design system if your team is already usingone?Designs can be final once theyre ready for the backlog, and that doesnt change if the primary interactive color is already defined or if layout standards are established.If youre worried about pixel perfection, dont be concerned about pixel perfection! You can tighten a design and mature it as you work on it. Again, fidelity is a spectrum, not a step. The process is sped up significantly because youre not wireframing and ONLY THEN transitioning it to your established system, which just doubles up thework.If your team has an established design system, then grey-scale wireframing is even more of a time waster. The visual language is already established foryou.Whiteboarding / Napkin sketchingThis is a practice that many of you already do, but the problem is that youre doing it *before* wireframing rather than in lieu of it. Get your design to vomit onto a board or piece of paper quickly; dont be precious about it, and then get to designing.Note: Do *not* confuse these for the only other design practice I find more useless than wireframingpaper prototyping. Avoid that design theatre at all costs. Its a seductive distraction that burnseffort.Its hard finding images of whiteboarding that Im legally allowed toshare.UX Grammar / Conceptual GrammarsThe following two are effectively an evolution of page state outlines. While more formal than PSOs, they produce fantastic work in spaces where the problems or workflows are detailed or complex. Daniel Rosenberg speaks at length about UX grammar in his book UX Magic (https://www.amazon.com/UX-Magic-Daniel-Rosenberg/dp/1708061614)," which I strongly recommend.Javier Aragones also has a fantastic article on this new tool and why its so valuable:https://uxdesign.cc/have-conceptual-grammars-finally-arrived-to-ux-design-26c088edc5d9Object-Oriented UXOOUXI wont lie, this is my new favorite, and Ive strongly advocated it over the past few years. Sophia Prater is onto something extraordinary here, and I thoroughly recommend her training courses on the subject. OOUX is related to conceptual grammars, but far more codified and cross-beneficial.OOX does a fantastic job of breaking down all the needs for individual patterns in an interface and, more importantly, the relationships between them. Its a distinct visual thats very easy to grasp for non-designers. If your stakeholders need help staying on task with wireframes or visual designs, OOUX is surprisingly effective as it strips out anything confusing about an interface. They can focus exclusively on priority, hierarchy, and relationships between objects..ORCA mapping also helps you simplify the number of patterns you develop for the same information/content, making your project more scalable and sustainable for engineers (who, in my experience, love a good ORCAmap).Object Oriented UX | OOUXTimothe Goguely has a great ORCA Map for figjam thats a fantastic starter artifact: https://www.figma.com/community/file/1120705007006600427/oouxIn conclusionWireframing had its place and time, and I dont mean to say that the process doesnt have some value. But as designers living in a world where weve failed to justify our value to stakeholders, we MUST be mindful of how we spend our time and how we can be more effective and productive.This isnt 2004 where we needed final_final_really-final_designs.psd. We arent stuck using Omnigraffle or other tools that are not purpose-built. Question the orthodoxy around wireframes, and you might be a better designer. I certainly am.Stop wireframing (but still start low-fidelity) was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.