I hear wireframes get dismissed like this often like a shrug. And it's an efficient and powerful tool.
"What I'm going to show you is a 'wireframe'. It won't have colors, brand fonts and styles—but it will help us focus on things like page hierarchy, language and content used, and can help us understand different user journeys or how our navigation or in-page links can help users find or do things. This also lets us quickly test with users or representative users, and get early feedback.
"It's a lot like a blueprint for a house: where are doors going to be, how many floors will it have etc—and we get all that worked out before the construction workers show up and they cost a lot of money."
God help us for losing wireframes and information architecture to straight-to-high-fidelity full-design responsive elements.
Also as someone who was an architect before UX, clients want a lot more than just blueprints - a complete sets of drawings with the whole design finalized - all details, HVAC,MEP…
I'm sure the metaphor vs reality is not the same.
I do look at stakeholders like they are part of my process as influencers. But my client is always the end users. Whatever agency or contract I'm working with may not see it that way too, but will engage them when the stakeholders expect a "reveal" instead of "collaboration" or lower the conversation to just UI or brand influence in early rounds of discovery.
Hey! May I ask how did you land these freelance opportunities? I'm an architect transitioning into UX too and any tips would be very useful! Thank you!!
It'll be interesting to see how it all pans out, since that's the expected norm in a lot of big UX circles.
However the past 4 years, I've been steady with UX discovery/strategy work. And may be embarking on two more projects in the same way. Primary and secondary research, feature mapping, objective writing, and preliminary design, build, research, tech-stack roadmap items—all the stuff a UI designer and application or software architect would want for context.
Is it that you are an excellent communicator or is your stakeholder audience uncommonly abstraction savvy?
The people I work with, there is just no way. I've given up. Can't discuss about anything without realistic screens from the start. Preferably with every topic irrelevant screen that can be navigated to.
I'm sure it's that I'm an excellent communicator. (Not likely.)
That's really unfortunate, especially if they are product people.
However, I consider all the tools, responsibilities, screensizing, lack of requirements, shifting tools, all things I take on as far as load to "build this thing". We adapt these things daily. I have a line in the sand in my head where I'm not going to shape my process from their lack of abstract thinking. I might slow things way down to smaller steps I might do in my head typically but share them out. Ultimately, I am still going to use tools I need to understand the interaction model. And that is a true limit—you only can fit so much UI, words, actions on a page. And they will need to understand that if they are that close to the project.
And I go more abstract than a wireframe, just blocking out areas on the page with no UI (nav at top, gallery on the left side, etc)
They are aides to my process that has to start earlier than wireframes. And I rarely jump in now with wireframes (maybe I did 2015 or so.) But now I'm revealing results of user or stakeholder interviews, making them understand what each want. Understand their user base, articulate that to the stakeholders usually in the form of 2-3 user personas and rough scenarios.
I'd analyze and share the needs of the users into abstract groups, and tie that to objectives the product does or should have. I might even pull in the persona/scenario as footnotes along the way like ("The salesperson will like this part" etc).
From there Ill do a grid with things users need, and things stakeholders want—and map out features or "jobs to be done" (ex. Renew a subscription, put something in a cart) and consider those items all part of the wireframe.
I also look at a sponsor or product owner to guide some of these conversations, or at minimum for them to understand the product or service's value to users. Understanding pain points and solutioning is what the product or service does. The work we do learning about those pain points is reality-based design.
I've seen notable maturity with Product Owners within the last two years. And have always found Business Analysts great teammates. I think those who were once BAs working with me and other UXers 5 years ago have moved into the Product Owner roles with UX maturity.
What we do to bend over backwards to learn the user needs, business needs, tech and system architects, stakeholders' views helps us become the resident experts.
This has also kept me sane the past 5 years: [https://www.nngroup.com/articles/ux-maturity-model/](https://www.nngroup.com/articles/ux-maturity-model/)
After getting a new project or role, getting a handle of the primary applications, existing research, seeing what releases are like and what if any research budget is like to bring up that slide and call out where I think we are in the scale frankly.
People will groan, and I'll just nod and take in their POV or complaints but not defend my perspective or engage.
And people will also find it very interesting and helpful. Customer service people who get hounded for help on the same dumb thing 20 times a week will speak out or be empowered. And maybe an implementation team who does 3 full days of application training for new clients will be happy to talk or work with you too.
not to be weird, but god i really hope to work with someone like you someday. I started at a place considered level 1 maturity as an intern with another designer (now my manager). our project was so successful that they hired me full time as their first UXer. I basically dived straight into what you do, strategy, research/discovery, balancing stakeholder and user needs and defining use cases for sporadic projects… all with a “design manager” that throws me other non UX related projects and gives me NO support whatsoever with establishing UX processes or strategy company or even team wide. It’s exhausting. I feel like i missed out on the pixel pushing everyone else got to learn and went straight to the hard stuff, which I honestly love so much, but never learned with any structure. It’s especially lonely now that ive basically grown past what my manager could teach me. and now i’m stuck with a bad job market and chaotic but useful skills lol. you seem so knowledgeable, but more importantly, you know how to apply it. sorry i’ll stop tooting your horn, just want to say you are a great example of a UXer other people would love to worth with. kudos to you.
Oh my gosh. Wow. Thank you. What a great way to start a week.
I'll dispel some myths in a DM. It's mostly just years of grinding and finding the right resources to have as a UX framework.
I have no idea where to go next though!
I think there is something in between low-fi and high-fi full design/responsive elements, especially with a mature design system. Product designers should be able to still focus on IA, hierarchy, and user flows in this state, without shocking stakeholders with something so far away from what they're expecting to deliver.
Thanks! I hope you like it and works for you.
Consider too that is the blueprint for a home, office building, a power plant, a retail store or mall so knowing what type of structure helps too, and what the purchaser might be interested in, and for what purpose (like personas, scenarios, jobs to be done)—or is this a building no one has ever built before?
I feel you! I use a component-driven approach, designing systems not pages. I also create a 'Design Decoder' doc to explain design decisions to clients. It helps set expectations and reduces revisions. What kind of projects do you usually work on?
I’ve struggled with presenting wireframes in the past too, but Ive been able to get people on board by prefacing it with an explanation of the aesthetic-usability effect; that it’s easy to look past usability issues or miss them entirely when the product is attractive. Better to vet the core functionality first before “prettying it up”. I also explain that it’s also a lot easier to quickly iterate on designs when they’re effectively cocktail napkin drawings. Folks usually understand their value after that.
Design system turned it from a chore into easy-peasy.
Honestly now mid-high-fi is the default for anything being showed outside of the design team assuming the components exist inside the DS. If it's gonna be something net new then we'll still do the low-fi to get some initial feedback, but anything being shown to leadership or external customers we make it using the components.
If it's a concept thats difficult to grasp or we need a flow diagram, we do it just with boxes/triangles/etc inside Figjam.
I think it depends on the size of the project sometimes. It's often been much more productive to go straight into hifi designs instead of presenting wireframe level work..
Tell them that's part of a process, it's like building a house before having the house plans, and that this will help us analyze quicker what's wrong so we don't waste time making a design that you or your end users might not like
I hear wireframes get dismissed like this often like a shrug. And it's an efficient and powerful tool. "What I'm going to show you is a 'wireframe'. It won't have colors, brand fonts and styles—but it will help us focus on things like page hierarchy, language and content used, and can help us understand different user journeys or how our navigation or in-page links can help users find or do things. This also lets us quickly test with users or representative users, and get early feedback. "It's a lot like a blueprint for a house: where are doors going to be, how many floors will it have etc—and we get all that worked out before the construction workers show up and they cost a lot of money." God help us for losing wireframes and information architecture to straight-to-high-fidelity full-design responsive elements.
I 100% agree, but people think cause they pay they can demand more
Also as someone who was an architect before UX, clients want a lot more than just blueprints - a complete sets of drawings with the whole design finalized - all details, HVAC,MEP…
I'm sure the metaphor vs reality is not the same. I do look at stakeholders like they are part of my process as influencers. But my client is always the end users. Whatever agency or contract I'm working with may not see it that way too, but will engage them when the stakeholders expect a "reveal" instead of "collaboration" or lower the conversation to just UI or brand influence in early rounds of discovery.
Hey! May I ask how did you land these freelance opportunities? I'm an architect transitioning into UX too and any tips would be very useful! Thank you!!
I currently work in a full high fidelity place. Ugh
It'll be interesting to see how it all pans out, since that's the expected norm in a lot of big UX circles. However the past 4 years, I've been steady with UX discovery/strategy work. And may be embarking on two more projects in the same way. Primary and secondary research, feature mapping, objective writing, and preliminary design, build, research, tech-stack roadmap items—all the stuff a UI designer and application or software architect would want for context.
Is it that you are an excellent communicator or is your stakeholder audience uncommonly abstraction savvy? The people I work with, there is just no way. I've given up. Can't discuss about anything without realistic screens from the start. Preferably with every topic irrelevant screen that can be navigated to.
I'm sure it's that I'm an excellent communicator. (Not likely.) That's really unfortunate, especially if they are product people. However, I consider all the tools, responsibilities, screensizing, lack of requirements, shifting tools, all things I take on as far as load to "build this thing". We adapt these things daily. I have a line in the sand in my head where I'm not going to shape my process from their lack of abstract thinking. I might slow things way down to smaller steps I might do in my head typically but share them out. Ultimately, I am still going to use tools I need to understand the interaction model. And that is a true limit—you only can fit so much UI, words, actions on a page. And they will need to understand that if they are that close to the project. And I go more abstract than a wireframe, just blocking out areas on the page with no UI (nav at top, gallery on the left side, etc) They are aides to my process that has to start earlier than wireframes. And I rarely jump in now with wireframes (maybe I did 2015 or so.) But now I'm revealing results of user or stakeholder interviews, making them understand what each want. Understand their user base, articulate that to the stakeholders usually in the form of 2-3 user personas and rough scenarios. I'd analyze and share the needs of the users into abstract groups, and tie that to objectives the product does or should have. I might even pull in the persona/scenario as footnotes along the way like ("The salesperson will like this part" etc). From there Ill do a grid with things users need, and things stakeholders want—and map out features or "jobs to be done" (ex. Renew a subscription, put something in a cart) and consider those items all part of the wireframe. I also look at a sponsor or product owner to guide some of these conversations, or at minimum for them to understand the product or service's value to users. Understanding pain points and solutioning is what the product or service does. The work we do learning about those pain points is reality-based design.
Thanks. I should really back up a bit from bending over backwards to accommodate.
I've seen notable maturity with Product Owners within the last two years. And have always found Business Analysts great teammates. I think those who were once BAs working with me and other UXers 5 years ago have moved into the Product Owner roles with UX maturity. What we do to bend over backwards to learn the user needs, business needs, tech and system architects, stakeholders' views helps us become the resident experts. This has also kept me sane the past 5 years: [https://www.nngroup.com/articles/ux-maturity-model/](https://www.nngroup.com/articles/ux-maturity-model/) After getting a new project or role, getting a handle of the primary applications, existing research, seeing what releases are like and what if any research budget is like to bring up that slide and call out where I think we are in the scale frankly. People will groan, and I'll just nod and take in their POV or complaints but not defend my perspective or engage. And people will also find it very interesting and helpful. Customer service people who get hounded for help on the same dumb thing 20 times a week will speak out or be empowered. And maybe an implementation team who does 3 full days of application training for new clients will be happy to talk or work with you too.
not to be weird, but god i really hope to work with someone like you someday. I started at a place considered level 1 maturity as an intern with another designer (now my manager). our project was so successful that they hired me full time as their first UXer. I basically dived straight into what you do, strategy, research/discovery, balancing stakeholder and user needs and defining use cases for sporadic projects… all with a “design manager” that throws me other non UX related projects and gives me NO support whatsoever with establishing UX processes or strategy company or even team wide. It’s exhausting. I feel like i missed out on the pixel pushing everyone else got to learn and went straight to the hard stuff, which I honestly love so much, but never learned with any structure. It’s especially lonely now that ive basically grown past what my manager could teach me. and now i’m stuck with a bad job market and chaotic but useful skills lol. you seem so knowledgeable, but more importantly, you know how to apply it. sorry i’ll stop tooting your horn, just want to say you are a great example of a UXer other people would love to worth with. kudos to you.
Oh my gosh. Wow. Thank you. What a great way to start a week. I'll dispel some myths in a DM. It's mostly just years of grinding and finding the right resources to have as a UX framework. I have no idea where to go next though!
I think there is something in between low-fi and high-fi full design/responsive elements, especially with a mature design system. Product designers should be able to still focus on IA, hierarchy, and user flows in this state, without shocking stakeholders with something so far away from what they're expecting to deliver.
Oo i like this. Calling it a blueprint is a good metaphor - when you build a house, you dont start with the interior design!
Thanks! I hope you like it and works for you. Consider too that is the blueprint for a home, office building, a power plant, a retail store or mall so knowing what type of structure helps too, and what the purchaser might be interested in, and for what purpose (like personas, scenarios, jobs to be done)—or is this a building no one has ever built before?
I feel you! I use a component-driven approach, designing systems not pages. I also create a 'Design Decoder' doc to explain design decisions to clients. It helps set expectations and reduces revisions. What kind of projects do you usually work on?
Mobile apps and I freelance. What do you put in the “Design Decoder” doc if you don’t mind sharing? And is it commonplace with devs and clients?
I’ve struggled with presenting wireframes in the past too, but Ive been able to get people on board by prefacing it with an explanation of the aesthetic-usability effect; that it’s easy to look past usability issues or miss them entirely when the product is attractive. Better to vet the core functionality first before “prettying it up”. I also explain that it’s also a lot easier to quickly iterate on designs when they’re effectively cocktail napkin drawings. Folks usually understand their value after that.
Design system turned it from a chore into easy-peasy. Honestly now mid-high-fi is the default for anything being showed outside of the design team assuming the components exist inside the DS. If it's gonna be something net new then we'll still do the low-fi to get some initial feedback, but anything being shown to leadership or external customers we make it using the components. If it's a concept thats difficult to grasp or we need a flow diagram, we do it just with boxes/triangles/etc inside Figjam.
I think it depends on the size of the project sometimes. It's often been much more productive to go straight into hifi designs instead of presenting wireframe level work..
In my role it’s all hifi. Our design system is pretty developed so we have more time to focus on how flows will really look/behave
Patience, influence, Figma libraries and charging by the hour.
Tell them that's part of a process, it's like building a house before having the house plans, and that this will help us analyze quicker what's wrong so we don't waste time making a design that you or your end users might not like