I worked in a small shop and built wireframes out of necessity because we didn’t have dedicated UX designers. I was helping my team with some of that overhead. Now I’m in a larger org and we have dedicated UX and architects, but I still provide stakeholder and product feedback to these teams. I will make “dirty” mock-ups when the UI/UX teams are overwhelmed.
2 Likes
I’m going to go in a bit different direction. I require the PMs that I manage to create high level wireframes for new features and complex features. It forces us to think through the edge cases and think through what we are asking for and how it can affect the rest of the product. We use that to walk design and engineering through our initial ask but design has full freedom to change the flows once the ask is fully conveyed. I’ve seen way too many PMs create specs and only think of the feature at hand and forget things like error states or help links. I really can’t stand when PMs don’t work through the details, tell a designer or engineer to use their best judgement to fill in the details, complain about it and ask to change it later because it doesn’t match what they had in their head.
2 Likes
A good reason for not doing this is so designers are not influenced in any way. They should bring a fresh set of eyes towards the interaction that would solve the problem. By sharing wireframes, even lo-fi wireframes, it can stem the flow of ideas. A better operating model is for the designer to be part of the journey from the earliest point. PMs own the requirements and strategy, designer owns the interaction.
2 Likes
The reason you hire designers to design even if you can do it is the same reason you hire engineers even if you can code. They specialize and think about this more than you do and will surprise you if you let them.
Design will scale to fit the space you give it. It will push back on that space, part of it’s job is to challenge your assumptions, but it will largely operate in the space you make for it. When you hand design wireframes you give them very little space to use their skills to bring something more than making your wireframes “on-brand”. It’s like stubbing out all your engineers APIs and just asking them to fill in the code.
Use this principle to let design scale to what you need. If you need something fast, scope them to look at a small item. If you need ideation or if you have no idea how to solve a problem give them a lot of room and they’ll really impress you. For really big projects, brief them with a case study, give them your goals and metrics and watch a really good design team impress the hell out of you.
As with everything, there’s a balance. Spend all the design time on future thinking ideas and you ship nothing. Spend all the design time coloring in your wireframes and they all leave. Play it by ear.
1 Like
I’d maybe resort to sketching wireframes if my team was having an unusually hard time understanding what solutions to a problem I might consider acceptable.
Having it be a requirement for any UI work is incredibly unhealthy and disempowering to your designers. I’d push back on this hard, or just don’t do it, or do the minimum passable job and make sure your designers know that they can design it from scratch and your wireframe is just an example of a possible solution.
Taking on full wire framing is not generally PM territory. However, you may want to find time to speak to your manager about why this is an ask. Historical context is usually helpful when confronted with weird tasks or solutions in my experience. They could have taken a solution that solves the symptom vs the illness.
As another note, I’ve found building (typically awful) wire frame mock-ups in miro (figma, etc) to be really helpful when onboarding new design talent to a project or starting a new product from scratch. And on occasion design has needed/asked for more “feeding”; wire framing can be more useful than hours of meeting, if someone is not grokking it from text requirements and stories.
I have been doing a lot of UX design even though I do not identify as a designer at all. It is actually the most fun I have at work putting the UX together with designers.
I would say connecting UX to user stories have a lot of synergies, so it is quite a good way to structure smaller teams. It is all about what kind of qualities you and your designers have. I don’t think there is a general answer here.
It feels to me like what they really want, is for you to provide visual interface requirements.
For example, we need an affordance that when the user engages it, does blah. And there are these exception scenarios and when those are encountered the user should be told blah.
Sometimes I do these because it’s most efficient for gaining shared understanding of the requirements. Last one I did was for a dashboard. Rather then determining that there should be a radio button, or whatever, I made blank boxes and named then, then made a call out that explained the requirement for the box. Design took this and determined the actual interaction pattern and element that should be used, etc.
From a tool perspective, I used flowchart software. I created a big box that represented the screen, and then small boxes and labeled them. For example “Overall Metric Display” and then drew an arrow out and wrote out the requirement for the view and then various small logical flows that explained the logic, not interaction, for the various use cases.
This way, I am communicating what we are building and what things need to be communicated (all “what and why”) without providing any “how” in terms of design.
I prefer flowchart software or pen and paper for this over Balsamiq or design software because then I am not tempted to make design decisions.
I’d suggest once you’ve clearly defined the problem you’re solving, getting in front of a whiteboard and sketching out the basic flow or page elements with the designer. Try doing it together. Designers usually have great ideas when it comes to representing info and interactions. It’s strange that in your org the PM creates the wires in isolation.
Definitely not. But as others have mentioned, in the real world, all sorts of stuff happens. As an Business Analyst I have been in projects where I created the Low-level wireframe, after collecting/understand/soliciting the user requirements, but then I’d hand it off to the UX guys. Having said that, I’d definitely would not expect a PM to do it…
I don’t know your product or company. Note my advice is general. There is no rule to being a PM. IMO wireframes are pretty basic and will help you develop overlapping knowledge with UX designers. I’d be careful about doing high fidelity mocks. Quite possibly you’ll eat up a lot of time, and—others have said—alienate your designers. Oh, as for being bad at them. You’ll learn. Ask questions and learn as you go.
I’m a former product designer turned PM and I’d say it’s a 20-30%. I’m not qualified to make a recommendation as a junior PM, but perhaps I could give examples of what I’m doing to help you find answers.
- Generally, I’d always provide acceptance criteria, user stories, outlines of features and desired outcome (i.e. the PRD/spec) which is usually good enough.
- If I have a strong opinion on a design, I would usually submit a sketch to the design team and collaborate from there, be it through a workshop for iterations, or for them to take over entirely.
- If I’m looking to validate a solution or what I think would be a good design solution, I’d find the design team to validate my sketches/wireframes.
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.
Maybe they mean more like a user journey or a use case that uses a story board to explain what you are thinking?
Sometimes I find that when somebody says “wireframe” and we as product people think about a screen drawn in pencil on a napkin, what they really mean is a more generic set of boxes and lines that explain the steps that a user takes to go from point or state A to point or state B.
If they really mean wireframes, I am fine with a Product Manager doing one off wireframes (actual screen layout) when it is part of a discussion with the UX team, and you are working through a concept together.
I also don’t think that there should be concrete reinforced silos between product, design, and engineering. You are a team, building a product together, and that involves relying on your individual strengths and weaknesses.
When I find a design team that is offended that a PM worked through their idea visually via a wireframe, there is often a larger organizational problem going on. That said, having PM’s do wireframe work (essentially design work) as a default deliverable prior to you being able to engage the design team is odd.
1 Like
I don’t like answers here that deal in absolutes.
Your job as a PM is to build trust with your team and build with them. The best ideas should win and they can come from anywhere. You as a PM should be ready to be challenged by your marketing, engineering, design, and even sales teams.
On the other hand, your design team should not feel threatened by you drawing some mock-ups. Your mocks up should not signal “build this”. They should signal this is how I visualize my thinking and hopefully, this is helpful to you as a starting point.
Maybe you or your product leader need to sit down with the design leader and have a chat. How should both teams work and what should be the expectation?
All of this depends on the culture of a company but a product org should be balanced with equal respect for all departments. Nobody is above anyone else and experts (designers, engineers, marketers) are given breathing room to show their craft while being open to feedback from the person who is supposed to be the champion of the customer (PM).