The business: hey we need you to draw some wireframes for this engagement
Me: Do we have a scope for the problem? How are the user's existing tools failing them? Are we resourced to answer these questions?
The business: nah it's ok they can be low fidelity wireframes
Design artifacts are not the deliverable. They just document the design decisions, and design decisions must be rooted in user research.
If you can't draw a direct line from the artifact to how the decisions it documents will be informed, you won't produce anything of value.
Before someone sets pencil to paper, it's really easy to think you have something while remaining pleasantly vague. Only when you need to render the artifact do you realize that there's no there there. It's up to the designer to say "hang on, I can't do anything with this."
Product ownership is an interesting challenge - you want to limit WIP and avoid context switching, but you can't just laser focus on building and neglect caretaking.
This is why trying to develop many new things in parallel doesn't work, and why single threaded leadership is so effective. Without consciously attending to all the dimensions of the product, you'll build an unstable tower that is constantly collapsing.
This model also shows why focusing on outcomes is more important than outputs. The second approach looks tempting from a feature factory perspective, but if you have visibility into outcomes, the work in the first approach becomes just as meaningful.
One of the most important Enterprise design tools you can learn is PowerPoint
This is not (just) my usual spiel about most visual tools being merely documentation - if you don't know how to make your decks look good, it'll be rough to get your ideas across.
PowerPoint can do almost everything InDesign can do. Take advantage of it.
One (perhaps the only?) positive development on the Web since the glory days is that the "normal" size of text on the average website has gone up from minuscule to legible or even a little bigger than it needs to be.
That's not to say there weren't websites with big text in 2004, or websites with small text today. But our visual language for "this is what a website looks like" has evolved. What it means for a website to look "designed" vs "normal" (for lack of better terms) has changed.
Even pages intentionally aiming for an "undesigned" or brutalist feel tack towards larger, rather than smaller, text. bloomberg.com/features/compa…
Smaller teams move quicker, but having the correct team composition and mandate is much more important than size. Unless your team has decision authority, you will fall behind again while getting stakeholders caught up to your progress and insights.
Making polished presentation: 3 hours
Presenting findings to execs: 1 hour
Answering follow-up questions: 1 hour
Arguing with the legacy power centers: 8 hours
vs
Having an exec sit in on a user interview: 45 min
Listening to them having their mind blown in the debrief: 15 min
When your audience doesn't have the same context you do, it's much harder to explain what's going on and why the problem matters or the solution is correct. Narrowing that gap as much as possible will tighten your feedback loops more than anything else can