Applying (And Ignoring) Wireframing Feedback
And then applying and ignoring feedback. So after you have that conversation and after you send the work out to them and you're hearing their feedback, you have to be the gatekeeper of what responses you get. So a lot of times, you might hear something like, "Well, my daughter really likes the color blue. Can we make it blue?" Or, I don't know. "Snapchat's really in right now. Should we make the website temporary?" Or any kind of thing that you feel like, "Well, that doesn't seem right." If that's your response, think about the goals and objectives you set. Think about your users. And hold those two things up next to each other and compare them. Is the feedback you're getting in alignment with your goals, in alignment with the objectives, in alignment with how you think the users are gonna use the site? If yes, try it, put it in there. Make it work. If it doesn't, maybe try and dig a little bit deeper. Maybe there's another problem that's popped up that you need to solve for, or maybe ...
it's just not a piece of feedback that needs to be incorporated. But the most important part is to always go back to that information and research that you did before and make sure that that's what you're applying, that that's what you're using to apply the feedback, not your personal preferences or the preferences of your stakeholders. So these are some of the big takeaways of what we reviewed in the wireframing right now. Just a high level of what the most important stuff is. So wireframing is a skeleton of content and functionality. It's not a visual design, it's not coded design, it's not the final product. Ask everyone questions, ask them even more questions. And that is to make sure you know what you're solving for. Always be thinking about what you're solving for and always be thinking about your users.
You up for one question before we take a quick break?
Yeah, absolutely. I love questions.
So this is gonna be a two-parter. Part from Karen W, and I'm adding a little component myself.
Do you take responsive design into consideration from the beginning when wireframing, and how often do you design for mobile first?
Great, great, great question. Absolutely take responsive into account the whole time you're wireframing. That should be part of your criteria when you're talking about what this project is. So if you know that your stakeholders want the site to be used on mobile, think about how often. If it's like this restaurant, and they're checking what time the hours are open, it's probably a very good chance that they're gonna be on mobile and it's an important place to make sure you're getting everything right. If it's filing their taxes, probably not as likely that they're gonna be doing it on mobile. So maybe make sure it looks good. Maybe have a different version of it that is going to get people to where they need to be, but not necessarily recreate the whole site onto mobile. And then mobile first is definitely a philosophy that a lot of people use, and a good one to do. I sort of go back and forth. It really depends on your use case. So in my work at my job right now, pretty much everyone is using our products on their computer. So we designed computer first because that's where it's most important. It's very unlikely that our users are gonna be doing it on their phone. If we were designing something for mobile web, or obviously for an app, I would go mobile first. So think about what you're solving for and then use that to guide you on how to get started.