Hello all! I’m a former software engineer, now a product manager.
Product Managers are expected to completely design the wireframes at my organization as part of the recently modified product development process before handing it off to the designers. Do you believe this is a sensible strategy for good UX design?
I also have a decent sense of design, but I’m not very good at creating UX or UI, so I’m not particularly at ease with it either. What am I supposed to do?
No. A UX designer creates interaction models, which include wireframes. The UI designer then makes the mock-ups using the model. The PM should outline all the various user situations or use cases that the tech team and design team will need to address.
@TerryAnthony, How about wireframes with very low fidelity? Should the UX designers handle that? It appears that our organization doesn’t have a dedicated UX designer, so in this situation, should this fall under the purview of UI designers exclusively or the PMs?
Not all businesses, though, have the luxury of time or finances.
In that situation, either you or the designer can complete it. There is no simple solution that works for everyone to this problem.
To find the optimal procedure, try experimenting with your team.
And by all means, use wireframes to communicate your views or ideas if you feel comfortable doing so.
Just keep in mind that implementation includes wireframes, and that solution space involves implementation. The ideal PM should be more problem focused.
Still, rather than explaining the actual design, I’d concentrate on the workflow.
I would only do it if we had a new, minor functionality and the design team was unable to produce mockups for it. I would then draw it out so the coders could see where everything should go.
Going against the grain, I’ll say yes and no, don’t treat them like wireframes, and keep it simple. I’ve made the design team aware of how much I value working together. Making a design sketch encourages me to consider the UX flow of the product we want to construct.
I informed them that this wasn’t the plan. I make sure to emphasize that point, .
But in this case, should it be collaborative, or I just make something and hope they do the right thing even if that means disregarding my wireframes? In the latter case, my only concern is what if I design something sub optimal?
You will design something that is less than ideal; don’t ask “what if.” The remark above acknowledges that reality and the fact that you must do it because your job requires it, even if the answer to the post’s question is actually “no,” which is not acceptable… Since it is simply a sketch, the final product will undoubtedly involve collaboration, as it should. If there is a better wireframe, disregard it because you, as the product manager, have the best vision for the finished product; otherwise, ensure that the functionality is maintained, even if that means imposing and disregarding some of that “collaborative” work. The best way to do this is to explain to the team why it should be that way.
Embrace Design doing something unique. Pay attention to empowering design. What user inputs are required, and what does the user need to understand? What standards do we now need to set for the user. What’s the result? what takes place next. This is preferable to saying, “I want a table here and fields here.” At this stage, I need to know the user’s location so that I may provide them the locations of nearby stores. The closest ones should be given priority, and the intended action is…
It makes no sense for you to work on something that you know you are “pretty awful” at since you will not only alienate and cause conflict with your design team, but it is also counterproductive.
Quite agree to @HerbertWarnick. Furthermore, this just feels like a highly CYA move by a member of the UX team dressed up as an efficiency test. The procedure is built in such a way that why should the PMs bear the brunt of the responsibility for a poor design, of all people? What is the assurance that, in this case, UX will double-check any of the generated wireframes?
I did, but the management was more concerned about saving the designers’ time by minimizing back and forth. It seems that if we provide wireframes in the specifications, they can finish the designs more quickly. I’m still considering a more comprehensive solution to this problem. Perhaps begin by giving out more luxurious ones.
I find it really odd that your manager would want you to build the wireframes when you already have experts in that field. The HOW portion of the equation belongs to designers and developers. Product managers ought to concentrate on the WHO, WHAT, and WHY sections. You spoke of going back and forth. Perhaps you should spend more money on the initial requirements document so that UX can make their points more quickly? Instead of executing their jobs, perhaps you could spend some time considering how to improve communication.
When PMs start doing wireframes, they get sucked into the rabbit hole of product design and development, and with that, any outward focus on markets and customers goes out the window as the PM becomes a slave to the day to day development process.
It’s between 20 and 30 percent, in my opinion as a former product designer turned PM. As a junior PM, I am not qualified to offer recommendations, but perhaps I can provide examples of what I’m doing to assist you in finding solutions.
In general, I would always offer acceptance criteria, user stories, feature summaries, and desired results (i.e., the PRD/spec), which is typically sufficient.
If I have strong opinions about a design, I’ll typically present a concept to the design team and we’ll work together from there, whether through iterative workshops or having them take full control.
The design team can assess my sketches and wireframes if I’m wanting to validate a solution or what I believe to be a good design solution.
Essentially, the design team is always swamped with prototyping work. Sometimes, to help move the needle and move things in the pipeline, I would kickstart the design process myself.